JPWO2018142587A1 - チケット管理システムおよびチケット管理方法 - Google Patents

Abstract

チケットの管理を効果的に行う。処理装置と、記憶装置と、入力および出力のためのインタフェースを備えるチケット管理システムである。このシステムでは、記憶装置は、チケット毎にユーザのいずれがチケットを所有したかを時系列に示すチケット所有者変更履歴を格納する。処理装置は、チケット所有者変更履歴を反映したポイントをユーザ毎に算出する。記憶装置は、ポイントをユーザと対応付けて記録する。処理装置は、インタフェースを介して受信する要求に対し、ポイントに基づいて、（１）特定の条件を満たすポイントに対応するユーザの、チケットの購入および移転の少なくとも一つの制限、および、（２）特定の条件を満たすポイントに対応するユーザが所有した、チケットの利用の制限、の少なくとも一つを行う。

Description

本発明は、チケットを管理するシステムに関し、特にチケット所有者変更履歴に基づくチケット管理システムに関する。

オンラインのチケット予約システムにより、ユーザは時間や場所を問わずチケット購入が可能となり、近年は電子チケットの利用機会も増加している。インターネットの普及により、チケットを大量に購入し、利益目的で転売する不正転売が容易になっている。不正転売目的でのチケット購入者に対する現行の対策の多くは、現地で本人認証を行うものであり、チケットが対象とするイベント当日の、多大なコストと時間を要しているのが現状である。

チケットの不当転売や偽造を防止する技術として、特開2006-201997号公報（特許文献1）には、認証コードを電子透かしとして電子チケットに埋め込むことにより、チケット購入者と利用者の同一性を確保し、不正転売を防止することが開示されている。

特開2006-201997号公報

特許文献1の方式は、購入者自身の顔写真に所定の認証コードを電子透かしとして埋め込んだ画像を有するチケットを発行し、チケットの利用時に、顔写真の照合および顔写真に埋め込まれた認証コードを読み出すことにより、当該チケットが真正のものであることを確認することができる。また、発券履歴記録部に記録されている発券履歴を参照することでチケットのキャンセルや再発行を容易に行うことが開示されている。

しかし、特許文献1では、発券履歴記録部において、チケット所有者変更履歴とチケット所有者（あるいは購入者）の生体情報を記録し、キャンセルした乙の情報を、キャンセル待ちの甲の情報に書き換えるため、すべての変更履歴を活用することは出来ない。

効果的な転売抑止のためには、購入時と当日の情報だけではなく、チケットがユーザに所有されている期間の情報も、有効化判断等のチケットの管理に利用することが有効である。

本発明の一側面は、処理装置と、記憶装置と、入力および出力のためのインタフェースを備えるチケット管理システムである。このシステムでは、記憶装置は、チケット毎にユーザのいずれがチケットを所有したかを時系列に示すチケット所有者変更履歴を格納する。処理装置は、チケット所有者変更履歴を反映したポイントをユーザ毎に算出する。記憶装置は、ポイントをユーザと対応付けて記録する。処理装置は、インタフェースを介して受信する要求に対し、ポイントに基づいて、（１）特定の条件を満たすポイントに対応するユーザの、チケットの購入および移転の少なくとも一つの制限、および、（２）特定の条件を満たすポイントに対応するユーザが所有した、チケットの利用の制限、の少なくとも一つを行う。

本発明の他の一側面は、処理装置と、記憶装置と、入力および出力のためのインタフェースを備えたサーバを用いたチケット管理方法である。この方法は、記憶装置が、チケット毎にユーザのいずれがチケットを所有したかを時系列に示すチケット所有者変更履歴を格納する第１のステップ、処理装置が、チケット所有者変更履歴を反映したポイントをユーザ毎に算出する第２のステップ、記憶装置が、ポイントをユーザと対応付けて記録する第３のステップ、インタフェースが、ユーザとチケットを特定してなされる所定の要求を受け付ける第４のステップ、処理装置が、第４のステップで特定されたユーザに対応するポイントを参照し、所定の要求を許可するかどうかを判定する第５のステップ、を実行する。

本発明によれば、チケットの管理を効果的に行うことができる。

チケット予約システム１０００の一例の構成ブロック図。 新規登録処理部１１２１が行う処理の一例のフロー図。 購入者情報テーブル１１４１の一例の表図。 チケット購入処理部１１２２が行う処理の一例のフロー図。 チケット情報テーブル１１４２の一例の表図。 チケット所有者変更履歴テーブル１１４３の一例の表図。 チケット所有者変更判断部１１２３が行う処理の一例のフロー図。 チケット有効化判断部１１２４が行う処理の一例のフロー図。 チケット所有者変更履歴ポイント（Ｐ）の（ｎＰ）への更新処理の一例のフロー図。 チケット所有者変更履歴ポイント加算の原理を示す概念図。 実施例１のポイント加算の計算経過を示す表図。 実施例２のチケット所有者変更履歴ポイント（ｎＰ）の計算処理の一例のフロー図。 実施例２のポイント加算の計算経過を示す表図。

以下、図面を参照して本発明の実施形態を説明する。本実施形態は本発明を実現するための一例にすぎず、本発明の技術的範囲を限定するものではない。

以下の実施例では、ユーザがチケットを所有している期間の所有者変更履歴を収集し、チケットの有効化判断に用いるための技術を説明する。特に、すべての所有者変更履歴をもとにした転売状況のポイント化により、チケットの有効化を判断するための技術的なロジックが開示される。

本実施例の代表的な構成例は、電子チケットを対象としたオンラインチケット予約システムにおいて、チケット所有者変更履歴に基づいてチケットの有効化判断を行うチケット予約サーバであって、ユーザの会員登録処理を行うための新規登録処理部と、ユーザのチケット購入処理を行うためのチケット購入処理部と、チケットの所有者が変更されたときに履歴を書き込むためのチケット所有者変更判断部と、チケットの有効化判断を最終的に実施するチケット有効化判断部と、を含むものである。

以下において、チケット予約サーバを転売抑止に向けて機能させるための手法を説明する。本実施例の対象は、例えばコンサートなどのイベントの電子チケットである。

＜１．システム構成＞
図１に本実施例のチケット予約システムの一例を示す。チケット予約システム１０００は、チケット予約サーバ１１００と、チケット購入者が用いる端末１２００と、これらの間で通信が可能なように接続する有線あるいは無線で構成されたネットワーク１３００で構成される。

チケット予約サーバ１１００は、処理装置であるＣＰＵ（Central Processing Unit）１１１０、半導体記憶装置等で構成されるメモリ１１２０、入力および出力のためのインタフェース１１３０、磁気ディスク装置等で構成される記憶装置１１４０を備える。メモリ１１２０と記憶装置１１４０は、物理的に同一の記憶装置の異なる領域を用いても良い。チケット予約サーバ１１００は、一般的なコンピュータ（サーバ）で構成することができる。図には示さないが、モニタ等の出力装置やキーボード等の入力装置等、サーバが当然備える入出力装置は、インタフェース１１３０経由で接続することができる。なお入力および出力のためのインタフェース１１３０は、入出力両機能を備えるもののみを意味するのではなく、入力機能のみを備えるインタフェース、出力機能のみを備えるインタフェース、さらには入出力の両方の機能を備えるインタフェースのいずれをも意味するものとする。

本実施例では計算や制御等の機能は、記憶装置１１４０に格納されたプログラムがメモリ１１２０に転送され、ＣＰＵ１１１０によって実行されることで、定められた処理を他のハードウェアと協働して実現される。ＣＰＵ１１１０が実行するプログラム、その機能、あるいはその機能を実現する手段を、「機能」、「手段」、「部」、「ユニット」等と呼ぶ場合がある。もっとも、ソフトウェアを用いずに、ハードウェアで同等の機能を実現することも可能である。

ソフトウェアで実現する場合には、メモリ１１２０には、本実施例の各機能を実現するためのプログラムが格納される。新規登録処理部１１２１は、チケット予約システムのユーザを新たに登録処理する機能をもつ。チケット購入処理部１１２２は、チケットの購入を処理する機能をもつ。チケット所有者変更判断部１１２３は、チケットの所有者の変更を判断する機能をもつ。チケット有効化判断部１１２４は、チケットの有効無効を判断する機能をもつ。

記憶装置１１４０には、データベースとして、購入者情報テーブル１１４１、チケット情報テーブル１１４２、チケット所有者変更履歴テーブル１１４３等が格納される。

チケット購入者が用いる端末１２００は、各ユーザ個人の所有する携帯端末等でも良いし、チケット販売店等に設置されている共用の据え置き型の端末でも良い。本明細書では特に区別することなく、単に端末１２００と称する。

＜２．ユーザ新規登録処理＞
図２は、チケット予約システムにおいて、ユーザが新規登録する際の処理フローチャートである。ここでは、ユーザＡがチケット予約システム１０００に新規登録して会員となるときに、チケット予約サーバ１１００の新規登録処理部１１２１が行う処理を例として説明する。当該処理は、例えばユーザＡが端末１２００から送信する、登録申請コマンドの受信により開始する。

ユーザ情報受信処理Ｓ２０１では、チケット予約サーバ１１００は、ユーザＡの情報として、端末１２００から入力され、ネットワーク１３００経由で送信されるユーザ情報をインタフェース１１３０を介して受信する。

購入者情報テーブル更新処理Ｓ２０２では、新規登録処理部１１２１は、受信したユーザ情報として、例えばユーザＡの「氏名」、「住所」、「生年月日」、「電話番号」、「生体情報」等を、購入者情報テーブル１１４１に書き込み、新たなユーザとして登録する。なお、図中の実線の矢印を処理の流れを示すものとし、破線の矢印をデータの流れを示すものとする（以下同様）。

図３は、記憶装置１１４０に格納される購入者情報テーブル１１４１の一例である。各ユーザ毎に１組のデータセットが格納されている。各データセットは、例えばユーザの「氏名」３００１、「住所」３００２、「生年月日」３００３、「電話番号」３００４、「生体情報」３００５を含む。生体情報は例えばユーザの指紋や指静脈のパターンである。以上は例示であって、全ての情報が必須ではないし、他の情報が追加されても良い。

ユーザＩＤ、パスワード割り当て処理Ｓ２０３では、新規登録処理部１１２１は、購入者情報テーブル１１４１の「ユーザＩＤ」３００６と「パスワード」３００７に、ユーザＡの「生体情報」３００５と紐付く値を一意に割り振って書き込み、確定させた「ユーザＩＤ」３００６と「パスワード」３００７を、ユーザＡの端末１２００に送る。重要データの送受信には、既知の暗号化技術等を用いてもよい。

購入者情報テーブル１１４１には、ユーザ毎に他の項目として、チケット所有者変更履歴ポイント（Ｐ）３００８がある。チケット所有者変更履歴ポイント（Ｐ）３００８は、ユーザの新規登録時に初期値０に設定される。チケット所有者変更履歴ポイント（Ｐ）３００８は、各ユーザに対して、各ユーザが所有した過去のチケットの履歴を反映したポイントが付加される。当該ポイントは、当該ユーザに対する、チケットの購入の可否を判定するために用いられる。また、転売あるいは譲渡等（以下「移転」という）の可否を判定するために用いられる。チケット所有者変更履歴ポイント（Ｐ）３００８については、後に詳しく説明する。以上でユーザの新規登録処理は終了である。

＜３．チケット新規購入処理＞
図４により、ユーザがチケットを新規購入するときに、チケット予約サーバ１１００が行う処理について説明する。ここでは、図３の購入者情報テーブル１１４１に登録されているユーザＡが、チケット予約システム１０００にアクセスして、チケットを５枚購入しようとするときに、チケット予約サーバ１１００のチケット購入処理部１１２２が行う処理として説明する。

ログイン処理Ｓ４０１では、チケット予約サーバ１１００は、ユーザがログイン画面で入力した「生体情報」、「ユーザＩＤ」、「パスワード」を、端末１２００を介して受信する。購入者情報テーブル１１４１に書き込まれているユーザＡの、「生体情報」３００５、「ユーザＩＤ」３００６、「パスワード」３００７と照合し、正しい情報が入力された場合、チケット予約サーバ１１００はユーザをユーザＡとして識別し、ログインを許可する。

処理Ｓ４０２では、チケット予約サーバ１１００は、ユーザＡが購入を希望しているチケットの情報として、「公演名」「公演日」「枚数」等、対象チケットを特定するための情報を、端末１２００を介して受信する。なお、ユーザはチケットを特定する情報、例えば「公演名」と「枚数」だけ入力し、「公演日」その他の情報は、チケット予約サーバ１１００側で、チケットを特定する情報に紐づけられたデータから取得しても良い。

処理Ｓ４０３では、チケット購入処理部１１２２は、購入者情報テーブル１１４１を参照し、ユーザＡのチケット所有者変更履歴ポイント（Ｐ）３００８を読み出す。なお、ログインが特定のチケット購入に関するものであることがあらかじめわかっているような場合には、希望チケット情報受信処理Ｓ４０２をスキップして、チケット所有者変更履歴ポイント参照処理Ｓ４０３以降を実行しても良い。

処理Ｓ４０４では、ユーザＡのチケット所有者変更履歴ポイント（Ｐ）３００８が、所定の閾値Ｓ１以上かどうかを判定する。所定の閾値Ｓ１以上の場合には、購入を拒否する処理Ｓ４０５に進む。所定の閾値Ｓ１未満であれば、チケットを発券する処理Ｓ４０６以降に進む。

処理Ｓ４０５では、チケットを購入できない旨をユーザＡの端末１２００に送信して処理を終了する。

処理Ｓ４０６では、チケット購入処理部１１２２は、チケット情報テーブル１１４２の「チケットＩＤ」に、希望チケット情報受信処理Ｓ４０２で受信した「枚数」分のチケットに対応する一意の「チケットＩＤ」を登録する。

図５は、記憶装置１１４０に格納されるチケット情報テーブル１１４２の一例である。チケットＩＤ割り当て処理Ｓ４０６により、ユーザの希望するチケットの枚数分、一意に定められたチケットＩＤ５０１が新たに生成され、チケット情報テーブル１１４２に追加される。図５の例では、ユーザＡが購入した５枚のチケットに対応するＩＤである、「MNO1」、「MNO2」、「MNO3」、「MNO4」、「MNP1」のデータが生成されている。

処理Ｓ４０７では、チケット情報テーブル１１４２の各チケットＩＤ５０１に対応して、チケットに対応する「公演名」５０２、「公演日」５０３等の情報を書き込む。なお情報はこれに限るものではない。

処理Ｓ４０８では、チケット購入処理部１１２２はチケット所有者変更履歴テーブル１１４３の更新を行う。

図６は、記憶装置１１４０に格納されるチケット所有者変更履歴テーブル１１４３の一例である。チケット所有者変更履歴テーブル１１４３は、チケット毎に、そのチケットの所有者変更の履歴を保存している。

チケット購入処理部１１２２は、チケット所有者変更履歴テーブル１１４３の「チケットＩＤ」６０１に、購入されたチケットのＩＤとして、チケット情報テーブル１１４２の「チケットＩＤ」５０１とクロスリファレンス可能な「MNO1」、「MNO2」、「MNO3」、「MNO4」、「MNP1」を登録する。なお、チケット所有者変更履歴テーブル１１４３は、チケット情報テーブル１１４２と合体して一つのテーブルとしても良いのは勿論である。

今回の処理は、５枚のチケットの新規発行であるため、各チケットの所有者は１人目である。よって、上記５枚の「チケットＩＤ」５０１に対応する「チケット所有者変更履歴：１人目」６０２（１）としてユーザＡのユーザＩＤ「1111」を書き込み、「チケット購入時間」６０３（１）にチケットが購入された時間を書き込む。この処理により、５つのチケットについて、ユーザＡが最初の所有者として登録されたことになる。

処理Ｓ４０９では、ユーザＡの端末１２００に仮状態の電子チケットを送付する。電子チケットとしては、公知の例えば特許文献１に記載のようなものでよい。簡単な例としては、電子チケットはネットワークで送受信が可能な電子データの形態であり、例えばチケットＩＤと所有者のユーザＩＤのデータを含むＱＲコード（商標）である。使用時には、ＱＲコードを読み取り、生体認証情報を入力する。チケット予約サーバ１１００は、購入者情報テーブル１１４１とチケット所有者変更履歴テーブル１１４３の情報に基づいて、適正な所有者がチケットを所有していることを確認することができる。

後に説明するようにチケットはチケット予約サーバ１１００側で有効化することで使用可能になる。有効化しないか、あるいは無効化すると使用できなくなる。このため、チケット所有者変更履歴テーブル１１４３には、チケット毎に「チケット有効化／無効化フラグ」６０４の項目がある。これについては、後に詳説する。

＜４．チケット所有者変更処理＞
図７は、チケット所有者変更時のフローチャートである。図３の購入者情報テーブル１１４１に登録されているユーザＡ（ユーザＩＤ「1111」）からユーザＥ（ユーザＩＤ「1115」）に、チケットＩＤ「MNO1」の電子チケットが移転された場合を例に説明する。電子チケットの移転は、例えばチケットＩＤのデータが、ユーザＡからユーザＥに転送されることで行われる。

ここでは、電子チケットを譲り受けたユーザＥが、チケット予約システム１０００にアクセスしてチケットの所有者変更処理（移転処理）をしようとするときに、チケット予約サーバ１１００のチケット所有者変更判断部１１２３が行う処理として説明する。

ログイン処理Ｓ７０１では、チケット予約サーバ１１００は、ユーザＡがユーザＥにチケットを送った後、ユーザＥがログイン画面で入力した「生体情報」、「ユーザＩＤ」、「パスワード」、「チケットＩＤ」を、ユーザＥの端末１２００を介して受信する。基本的に図４のログイン処理Ｓ４０１と同様に、購入者情報テーブル１１４１を参照し、ユーザＥが会員登録されている場合はログインを許可する。会員登録されていない場合はユーザＥに会員登録画面を送り、入力された情報を購入者情報テーブル１１４１へ新規登録する。新規登録処理の手順は図２で説明したものと同様である。

処理Ｓ７０２では、チケット所有者変更判断部１１２３は、ユーザＥから入力された生体情報を、端末１２００を介して受信する。そして、チケット所有者変更判断部１１２３は、入力された生体情報をもとに、購入者情報テーブル１１４１からユーザＥの「チケット所有者変更履歴ポイント（Ｐ）」３００８を参照する。

処理Ｓ７０３では、チケット所有者変更履歴ポイント（Ｐ）が、所定の閾値Ｓ２以上であった場合、処理Ｓ７０４に進み、所定の閾値Ｓ２未満であった場合処理Ｓ７０５以降のチケット移転処理に進む。なお、閾値Ｓ２は、図４の閾値Ｓ１と同じであってもよい。

処理Ｓ７０４では、チケットを移転できない旨をユーザＥの端末１２００に送信して処理を終了する。

処理Ｓ７０５では、チケットの移転が許可された場合に、チケット所有者変更判断部１１２３は、ログイン処理Ｓ７０１で受信したユーザＥのユーザＩＤ「1115」とチケットＩＤ「MNO1」に基づいて、チケット所有者変更履歴テーブル１１４３の更新を行う。

なお、元の所有者ユーザＡとは異なるユーザＥが移転を受けたことを確認するために、チケット所有者変更履歴テーブル更新処理Ｓ７０５を行う前に確認処理を行っても良い。確認処理では、チケット所有者変更履歴テーブル１１４３の最終の所有者のユーザＩＤを参照し、購入者情報テーブル１１４１の当該ユーザの生体情報３００５を取得する。購入者情報テーブル１１４１の生体情報３００５と、ログイン処理Ｓ７０１で取得した「生体情報」とを比較し、同じであったら同一ユーザによる重複手続きであるとして処理を終了する。異なるものであった場合のみ、チケット移転があったものとしてチケット所有者変更履歴テーブル更新処理Ｓ７０５以降を行う。

図６を再度参照して、チケット所有者変更履歴テーブル更新処理Ｓ７０５を説明する。今回の処理は、受信したチケットＩＤに対応するチケットのユーザＡからの移転、すなわち１回目の移転であるため、チケットの所有者は２人目である。よって、チケットＩＤ「MNO1」の、「チケット所有者変更履歴：２人目」６０２（２）としてユーザＥのユーザＩＤ「1115」を書き込み、「チケット所有者変更時間：２人目」６０３（２）にチケットが移転された時間を書き込む。この処理により、チケットＩＤ「MNO1」について、ユーザＥが２番目の所有者としてチケット予約サーバ１１００に登録されたことになる。なお、「チケット所有者変更時間」としては、チケット所有者変更履歴テーブル１１４３が更新された時刻を用いてよい。

チケット移転処理Ｓ７０６では、チケット所有者変更履歴テーブル１１４３が更新された後、チケット予約サーバ１１００は、必要に応じてユーザＥの端末１２００に例えばＱＲコードにより仮状態の電子チケットを送付する。

図６では、２人目の所有者のデータまでしか示していないが、３人目以降の所有者についても、上記と同様の処理を行う。所有者のデータは、チケットＩＤ６０１毎に追加されていくことになる。以上のような処理により、チケット所有者変更履歴テーブル１１４３には、各チケットについての所有者の変遷が履歴として格納される。

＜５．チケット有効化判断処理＞
図８は、チケット予約システム１０００において、チケットの有効無効判定を行う処理のフローである。ここでは、チケット予約サーバ１１００のチケット有効化判断部１１２４が行う処理として説明する。

チケット有効化判断は、任意のタイミングで任意の回数行うことができる。しかし、効率を考えると、チケットの規定の有効期限の直前に１回行うことが望ましい。例えば、「チケットの対象となるイベントの開始日時の７２時間（３日）前」などのタイミングである。処理はチケット毎に、当該タイミングになったことを条件に開始するが、一般的に、一つのイベントに対して多数のチケットが発行され、それらのチケットは同一の有効期限を持っているので、チケット有効化判断は、ある時点において複数の対象チケットに対して纏めて行われる処理と考えてよい。すなわち、予め定められた時間情報に対応付けられた複数の対象チケットに対するバッチ処理である。対象チケットの抽出は、チケット情報テーブル１１４２を、公演名５０２と公演日５０３のand条件で絞り込み検索することで可能となる。以下の実施例では、このような処理を前提として説明する。

処理Ｓ８０１では、チケット有効化判断部１１２４は、対象チケットに関連したユーザごとの、チケット所有者更新履歴ポイント（Ｐ）の新チケット所有者更新履歴ポイント（ｎＰ）への更新処理を行う。ここで（Ｐ）と（ｎＰ）は同じパラメータであるが、更新前後を区別するために、異なる記号を用いている。対象チケットは複数あり、関連したユーザも複数いるので、これらの情報に基づいて、（Ｐ）を（ｎＰ）に更新する。

図９は処理Ｓ８０１の詳細を示すフロー図である。このフローはその時点に処理される複数の対象チケットのそれぞれについて行われる。

処理Ｓ９０１では、チケット有効化判断部１１２４は、チケット所有者変更履歴テーブル１１４３を参照して、対象チケットが経由した各ユーザを特定する。

処理Ｓ９０２では、チケット有効化判断部１１２４は、購入者情報テーブル１１４１を参照して、特定された各所有者について、チケット所有者変更履歴ポイント（Ｐ）３００８を呼び出す。

処理Ｓ９０３では、対象チケットが経由した各所有者ごとに、加算ポイント（ＡＰ）を算出する。

図１０に、加算ポイント（ＡＰ）の算出ルールの一例の概念を示す。図１０では対象チケットが、チケットの購入者であるユーザＷ１００１、中間所有者であるユーザＸ１００２、中間所有者であるユーザＹ１００３、チケットの最終利用者であるユーザＺ１００４の４人を経由した例を示している。ここでは、算出ルールは以下の２つのルールに基づくものとした。

ルール１：最終ユーザ（チケット利用者）以外は、「そのユーザを起点としたときに、その後Ｎ人の人を経由した場合は、Ｎポイントを付与する」というルールに基づき、加算ポイント（ＡＰ）が決定する。すなわち、対象ユーザには、そのユーザ以降、1人経由するごとに1ポイントが加算される。

ルール２：最終利用者は、最初の購入者と同じポイント数とする。

このルールに基づくと、ユーザＷはルール１により、その後ユーザＸ，Ｙ，Ｚの３人経由しているため、加算ポイント（ＡＰ）は３となる。ユーザＸはルール１により、その後ユーザＹ，Ｚの２人経由しているため、加算ポイント（ＡＰ）は２となる。ユーザＹはルール１により、その後ユーザＺの１人経由しているため、加算ポイント（ＡＰ）は１となる。またユーザＺはルール２により、ユーザＷと同じく加算ポイント（ＡＰ）は３となる。

ルール１によれば、移転回数の多いチケットに多く関与したユーザの加算ポイント（ＡＰ）が大きくなる。通常自分で購入したチケットを自分で使用すれば、加算ポイント（ＡＰ）は０である。しかし、転売目的で大量にチケットを購入した者（１次転売者）が、他の者（２次転売者）に小分けして転売し、２次転売者が最終ユーザに売るような場合を考えると、大量のチケットに関与し、各チケットが転売されている１次転売者の加算ポイント（ＡＰ）は非常に大きくなる。また、ルール２によると、転売されたチケットを使用する者も加算ポイントが大きくなる。なお、ここでは、単純に一人経由すると１ポイント加算するルールとしたが、経由する回数に重み付けをしてもよい。たとえば、２回目の移転に２ポイント、３回目の移転に３ポイントのごとくである。

図９に戻って、処理Ｓ９０４では、処理Ｓ９０２で呼び出した各ユーザのチケット所有者変更履歴ポイント（Ｐ）３００８と、各ユーザについて算出した加算ポイント（ＡＰ）を加算し、各ユーザの新しいチケット所有者変更履歴ポイント（ｎＰ）を計算する。計算したチケット所有者変更履歴ポイント（ｎＰ）により、チケット有効化判断部１１２４は、購入者情報テーブル１１４１のチケット所有者変更履歴ポイント（Ｐ）３００８を、過去データ（Ｐ）から新データ（ｎＰ）に更新する。

以上の処理を対象チケット分実行し、処理Ｓ８０２に進む。

図８に戻り、処理Ｓ８０２では、対象チケットが経由した各ユーザの所有者変更履歴ポイント（ｎＰ）に基づいて、チケットを有効にするか無効にするかを判定する。この処理も対象チケット分繰り返し行う。

判定の一つの例では、所有者変更履歴ポイント（ｎＰ）が閾値Ｓ３未満のユーザのみを経由しているか、（ｎＰ）が閾値Ｓ３以上のユーザを1人でも経由したかで判断する。Ｓ３はＳ１，Ｓ２と同じでも良いし、別のものにしても良い。

処理Ｓ８０３では、（ｎＰ）が閾値Ｓ３以上のユーザを1人でも経由した場合に、対象チケットを無効化する。

処理Ｓ８０４では、（ｎＰ）が閾値Ｓ３以上のユーザを1人も経由しなかった場合に、対象チケットを有効化する。

処理Ｓ８０５では、処理Ｓ８０３と処理Ｓ８０４の結果に基づいて、チケット有効化／無効化フラグ６０４を、チケット所有者変更履歴テーブル１１４３に記録する。チケット予約サーバ１１００は、チケットが無効になった場合には、適切なタイミングでユーザの端末１２００に、チケットが無効化されたことを通知することが望ましい。

［事例１：ユーザＡからユーザＥ，Ｆ，Ｇ，Ｈ，Ｉへの移転］
以上説明した実施例１を用いて、図３の購入者情報テーブル１１４１に登録されたユーザＡが、新規購入した５枚のチケットを移転する場合の例を説明する。本事例では、ユーザＡが購入した2016年1月1日が利用日となっている対象チケットに対し、チケット予約サーバ１１００が機能を有効に作用させる例を示す。本事例では、閾値Ｓ１とＳ２とＳ３を３０とし、チケット有効化判断を行う一定の時間帯を、チケット利用日当日である2016年1月1日の0時とする。ユーザＡ、ユーザＥ、ユーザＦ、ユーザＧ、ユーザＨ、ユーザＩは、図に示したチケット以外のチケット購入、チケット所有者変更には、関わっていないものとする。

事例１は、最初の所有者ユーザＡが所持しているチケット全5枚を所有者変更したために、ポイント加算が行われ、その結果ユーザＡの合計ポイントが一定数を超えて全てのチケットが無効化されるパターンである。

［事例１−１：チケットの新規購入時］
まず、ユーザＡがチケットを５枚購入する際には、図４のフローに基づいて、購入者情報テーブル１１４１に記録された、ユーザＡのチケット所有者変更履歴ポイント（Ｐ）がチェックされ、購入可否が判断される。図３の購入者情報テーブル１１４１の例では、ユーザＡのポイント（Ｐ）は２７であり、Ｓ１＝３０未満なので、処理Ｓ４０４の判断で購入は許可され、チケット情報テーブル１１４２とチケット所有者変更履歴テーブル１１４３に当該５枚のチケットのデータが登録される。

［事例１−２：チケットの移転時］
図６のチケット所有者変更履歴テーブル１１４３に示すように、ユーザＡ（ユーザＩＤ「1111」）が一人目の所有者となっているチケットは、チケットＩＤ「MNO1」、「MNO2」、「MNO3」、「MNO4」、「MNP1」である。以下、チケット所有者変更判断部１１２３の働きについて説明する。

ユーザＡが、上記のチケット有効化判断前に、チケットＩＤ「MNO1」のチケットをユーザＥ（ユーザＩＤ「1115」）に移転する場合、図７のフローの処理Ｓ７０２，Ｓ７０３に従い、チケット所有者変更判断部１１２３は、図３の購入者情報テーブル１１４１を参照し、移転を受けるユーザのチケット所有者変更履歴ポイント（Ｐ）３００８をチェックする。ユーザＥのチケット所有者変更履歴ポイント（Ｐ）は４であり、Ｓ２＝３０未満なので、移転は許可される。

同様に、「MNO2」のチケットについては、ユーザＦ（ユーザＩＤ「1116」）の（Ｐ）は7であるため、ユーザＡからユーザＦへのチケット所有者変更は許可される。同様に、「MNO3」のチケットについては、ユーザＧ（ユーザＩＤ「1117」）の（Ｐ）は２であるため、ユーザＡからユーザＧへのチケット所有者変更は許可される。同様に、「MNO4」のチケットは、ポイント（Ｐ）が１のユーザＨ（ユーザＩＤ「1118」）へのチケット所有者変更が許可され、「MNP1」のチケットについても、ポイント（Ｐ）が６のユーザＩ（ユーザＩＤ「1119」）へのチケット所有者変更が許可される。

許可されたチケット「MNO1」、「MNO2」、「MNO3」、「MNO4」、「MNP1」の新しい所有者であるユーザＥ，Ｆ，Ｇ，Ｈ，ＩのユーザＩＤ「1115」、「1116」、「1117」、「1118」、「1119」は、図６のチケット所有者変更履歴テーブル１１４３に「チケット所有者変更履歴：2人目」６０２（２）として、「チケット所有者変更時間：2人目」６０３（２）と共に登録される。

［事例１−３：チケットの有効化判断時］
以下では、以上の処理の後に行われる、チケット有効化判断時の処理の例について説明する。チケット予約サーバ１１００のチケット有効化判断部１１２４は、チケット情報テーブルの「公演日」に基づき、チケット利用日である2016年1月1日の0時を迎えたチケットの「チケットID」をチケット所有者変更履歴テーブル１１４３から参照する。ユーザＡの購入チケットのうち、対象となる時間帯を迎えたチケットの「チケットＩＤ」は、「MNO1」、「MNO2」、「MNO3」、「MNO4」、「MNP1」である。チケット予約サーバ１１００は、対象チケットを外部に送ることができないようロックする。

図９のフローに基づいて、チケット予約サーバ１１００は、処理Ｓ９０１でチケット所有者変更履歴テーブル１１４３から、チケットＩＤ「MNO1」に対応する「チケット所有者変更履歴：2人目」を参照し、「MNO1」がユーザＥに所有者変更され、現所有者がユーザＥであると判断する。

同様にして、チケット予約サーバ１１００は、「MNO2」のチケットについては、ユーザＦに所有者変更されていると判断し、「MNO3」のチケットについては、ユーザＧに所有者変更されていると判断し、「MNO4」のチケットについては、ユーザＨに所有者変更されていると判断し、「MNP1」のチケットについては、ユーザＩに所有者変更されていると判断する。

次に、チケット予約サーバ１１００は、チケット「MNO1」、「MNO2」、「MNO3」、「MNO4」、「MNP1」について、図１０に説明したアルゴリズムに基づいて、各ユーザの加算ポイント（ＡＰ）を算出する。最終利用者は、1人目のチケット所有者である購入者と対象チケットについて同じポイントを付与する。

図１１には、加算ポイント（ＡＰ）算出のための算出テーブル１１０００の例を示す。このテーブルは実施例の処理内容を説明するために示したものであり、実際のシステムとしてはあえてテーブル化する必要は無い。

図６のチケット所有者変更履歴テーブル１１４３に基づく対象チケットの所有者変更履歴から、氏名１１０１で示すユーザＡには５枚のチケットが各１回移転されたことにより5ポイントが加算ポイント（ＡＰ）とされる。ユーザＡからチケットの移転を受けたユーザは、移転を受けたチケットについてユーザＡと同じ加算ポイントになるため、ユーザＥには1ポイント、ユーザＦには1ポイント、ユーザＧには1ポイント、ユーザＨには1ポイント、ユーザＩには1ポイントが加算ポイント（ＡＰ）１１０３とされる。

図９の処理Ｓ９０４により、加算ポイント（ＡＰ）１１０３は、各ユーザのチケット所有者変更履歴ポイント（Ｐ）に加算され、新しいチケット所有者変更履歴ポイント（ｎＰ）１１０４が算出される。図１１に示すように、新しいチケット所有者変更履歴ポイント（ｎＰ）１１０４は、ユーザＡは32ポイント、ユーザＥは5ポイント、ユーザＦは8ポイント、ユーザＧは3ポイント、ユーザＨは2ポイント、ユーザＩは7ポイントと算出される。新しいチケット所有者変更履歴ポイント（ｎＰ）１１０４は、図３の購入者情報テーブル１１４１の各ユーザのチケット所有者変更履歴ポイント（Ｐ）３００８に、上書きされることになる。

図８の処理Ｓ８０２では、チケット予約サーバ１１００は、新しいチケット所有者変更履歴ポイント（ｎＰ）が閾値Ｓ３＝３０以上のユーザの有無を判定する。該当するユーザが一人でもいた場合には、処理Ｓ８０３でチケットは無効化される。なお、以上の例では、購入者情報テーブル１１４１のチケット所有者変更履歴ポイント（Ｐ）を更新してから、チケットの有効化および無効化をしているが、図１１に示したような暫定的なテーブルを用いて、有効化および無効化判断の後に、購入者情報テーブル１１４１のチケット所有者変更履歴ポイント（Ｐ）を更新してもよい。

この例では、ユーザＡのポイントが３２であり３０以上であるため、ユーザＡを経由している「MNO1」、「MNO2」、「MNO3」、「MNO4」、「MNP1」をすべて無効化し、図６のチケット所有者変更履歴テーブル１１４３の「チケット有効化／無効化フラグ」６０４に無効化と書き込む。

以上の説明からわかるように、本実施例では、転売されるチケットに多く関与し、不正な転売者である可能性の高いユーザＡを判別すると、ユーザＡが関与したチケットは全て無効となる。このため、転売者から購入した者のチケットも使えなくなるため、不正な転売を抑止する効果が期待できる。

また、実施例１における、他のユーザＢ，Ｃ，Ｄ，Ｊ，Ｋ，Ｌの加算ポイント（ＡＰ）と新しいチケット所有者変更履歴ポイント（ｎＰ）も図１１の算出テーブル１１０００に示すとおりである。

［事例１−４：その後のチケット新規購入、移転時］
その後、各ユーザが新規にチケットを購入する場合には、「事例１−３」の結果により、ユーザＡのチケット所有者の変更履歴ポイント（Ｐ）は３２になり、Ｓ1＝Ｓ２＝３０以上となっているため、図４、図７のフローに従い、新規購入、移転も禁止されることになる。一方、転売を受けたユーザＥ、ユーザＦ、ユーザＧ、ユーザＨ、ユーザＩについては、図１１のとおり、新しいチケット所有者変更履歴ポイント（ｎＰ）は３０未満のため、ユーザＡから移転を受けたチケットは使えないものの、新規購入や正当な移転は可能となっている。

［事例２：ユーザＣからユーザＫ，Ｌへの移転］
事例２では、図３の購入者情報テーブル１１４１中に示されるユーザＣ（ユーザＩＤ「1113」）が、購入したチケット（チケットＩＤ「MNO5」「MNO6」）をユーザＫ（ユーザＩＤ「1121）とユーザＬ（ユーザＩＤ「1122」）に移転する例を説明する。

本実例では、ユーザＣが購入した2016年1月1日が利用日となっている対象チケットに対し、チケット予約サーバが機能を有効に作用させる例を示す。本実施例では、一定数Ｓ１，Ｓ２，Ｓ３を３０とし、チケット有効化判断を行う一定の時間帯を、チケット利用日当日である2016年1月1日の0時とする。ユーザＣ、ユーザＫ、ユーザＬは、本事例で対象となるチケット以外のチケット購入、チケット所有者変更には、関わっていないものとする。

本事例では、ユーザＣは、チケット「MNO5」と「MNO6」の２枚を購入し、友人と２人でコンサートへ行く予定であった。しかし、２人とも都合が悪くなったため、ユーザＣは、一枚をユーザＫに、他の一枚をユーザＬに移転する例を考える。以下では、チケット予約サーバ１１００のチケット有効化判断部１１２４が行う処理として説明する。

事例２は、最初の所有者ユーザＣが所持しているチケット2枚をユーザＫとユーザＬに1枚ずつ所有者変更したために、ポイント加算が行われ、その結果ユーザＬの合計ポイントが一定数を超えて、ユーザＬが受け取ったチケットのみが無効化されるパターンである。

［事例２−１：チケットの新規購入時］
ユーザＣの新規チケット購入時には、図４で説明した処理に従い、チケット予約サーバ１１００は、図３の購入者情報テーブル１１４１からユーザＣの「チケット所有者変更履歴ポイント（Ｐ）」３００８を参照し、ポイント（Ｐ）が１５で３０未満であるため、ユーザＣのチケット購入を許可する。購入されたチケットは、チケット情報テーブル１１４２とチケット所有者変更履歴テーブル１１４３に、新規データ（チケットＩＤ「MNO5」「MNO6」）として追加される。

［事例２−２：チケットの移転時］
ユーザＣ（ユーザＩＤ「1113」）は、この２枚のチケット「MNO5」「MNO6」のうち、「MNO5」のチケットを友人であるユーザＫ（ユーザＩＤ「1121」）に移転し、もう一枚のチケットを、転売の常習者であるユーザＬ（ユーザＩＤ「1122」）に移転している。

ユーザＣからユーザＫとユーザＬへの移転時には、図７のフローに基づいて、ユーザＫとユーザＬの「チケット所有者変更履歴ポイント（Ｐ）」３００８を参照する。図３の購入者情報テーブル１１４１の例では、ポイント（Ｐ）はそれぞれ、２と２９であり、いずれもＳ２＝３０未満のため、移転は許可される。その結果、処理Ｓ７０５により、ユーザＫとユーザＬは２人目の所有者として、チケット所有者変更履歴テーブル１１４３に記録される。

［２−３：チケットの有効化判断時］
図８と図９のフローに基づいて、チケットの有効化判断が行われる。処理Ｓ９０１により、「MNO5」のチケットはユーザＫに移転されており、「MNO6」のチケットはユーザＬに移転されていることがわかる。そこで、図１０のアルゴリズムによれば、図１１のようにユーザＫとユーザＬは各１ずつ加算ポイント（ＡＰ）が加算される。ユーザＣは加算ポイント（ＡＰ）が２加算される。

その結果、図１１に示すように、ユーザＫの新しいチケット所有者変更履歴ポイント（ｎＰ）は３となり、通常から転売を行っているユーザＬは３０となる。そのため、図８の処理Ｓ８０２では、（ｎＰ）がＳ３＝３０以上であるユーザＬを経由したチケット「MNO6」は処理Ｓ８０３で無効となり、図６のチケット所有者変更履歴テーブル１１４３において、チケット「MNO6」のチケット有効化／無効化フラグ６０４は「無効化」にセットされる。一方、ユーザＫを経由したチケット「MNO5」のチケット有効化／無効化フラグ６０４は「有効化」にセットされる。

以上の事例により、実施例１ではチケットの移転元（ユーザＣ）が適正な移転を行っていても、チケットの移転先のユーザ（ユーザＬ）が不適正な転売を行っている場合には、不適正な転売を行っているユーザを経由したチケットを無効化することができることがわかる。また、適正なユーザ（ユーザＫ）が移転を受けた場合には、チケットは有効化される。

［事例２−４：その後のチケット新規購入、移転時］
ユーザＬについては、購入者情報テーブル１１４１のチケット所有者変更履歴ポイント（Ｐ）が３０以上になったため、ユーザＡと同様に、チケットの新規購入や移転ができなくなる。ユーザＣ，Ｋについては、チケット所有者変更履歴ポイント（Ｐ）が３０未満なので、特段の制限は無い。

［事例３：移転が無い場合］
事例３は、最初の所有者ユーザＤが所持しているチケット2枚を誰にも所有者変更しなかったために、問題なく全てのチケットが有効化されるパターンである。

ユーザＤ（ユーザＩＤ「1114」）については、図６のチケット所有者変更履歴テーブル１１４３に示すようにチケットＩＤ「MNP2」「MNQ3」の２つを購入しているが、だれにも移転していない。この場合には、図８〜図１０のフローにより、チケット所有者変更履歴ポイント（Ｐ）には変化が無い。

実施例１では、チケットの移転が行われた場合には、チケットが経由したユーザには原則加算ポイント（ＡＰ）が付与される。しかし、移転には当然正当な理由がある場合もある。これらにも加算ポイント（ＡＰ）が付与されると、加算ポイントは蓄積されるため、配慮が望ましい場合がある。

実施例２でのチケットの有効無効判定を行う処理は、基本的に実施例１の図８と図９の処理フローを踏襲する。ただし、ユーザごとの加算ポイント（ＡＰ）を算出する処理Ｓ９０３に機能を追加する。よって、以下では実施例１と異なる追加機能部分のみを説明することにする。

図１２は、実施例２の処理Ｓ９０３の処理の詳細を示すフローである。ここでは、説明上、１つのチケットに対する処理として説明する。対象チケットが複数ある場合は、チケット毎に処理を繰り返して（ＡＰ）を算出し、あるユーザに関連するチケットが複数有る場合には、複数のチケットの（ＡＰ）の合計を処理Ｓ９０４で（Ｐ）に加算する。

処理Ｓ１２０１では、チケット有効化判断部１１２４が、チケット所有者変更履歴テーブル１１４３を参照して、対象のチケットに２人目の所有者がいるかどうかをチェックする。２人目の所有者がいなければ、処理Ｓ１２０２で移転なしと判定し、そのチケットに関しては、図１０で説明したルールの原則どおり加算ポイント（ＡＰ）の加算は無い。

処理Ｓ１２０３では、チケット有効化判断部１１２４が、チケット所有者変更履歴テーブル１１４３を参照して、対象チケットが同一のユーザによって購入された複数のチケットのうちの１枚かどうかを判定する。このとき、複数のチケットの種類や購入時間帯に条件をつけても良い。複数購入のうちの一枚で無い場合は、すなわち、一枚購入した際の当該一枚である場合には、処理Ｓ１２０６で、図１０で説明したルールに基づいて加算ポイント（ＡＰ）を算出する。

処理Ｓ１２０４では、チケット有効化判断部１１２４が、チケット所有者変更履歴テーブル１１４３を参照して、１人目の所有者が複数購入したうちの一枚が、まだ１人目の所有者に所有されているかどうかを判定する。チケットが１人目の所有者に一枚も残っていない場合には、処理Ｓ１２０６で、図１０で説明したルールに基づいて加算ポイント（ＡＰ）を算出する。

処理Ｓ１２０５では、チケット有効化判断部１１２４が、チケット所有者変更履歴テーブル１１４３を参照して、１人目の所有者が所有している以外のチケットが、２回以上移転されているかを判定する。２回以上移転されているチケットが一枚でもある場合には、処理Ｓ１２０６で、図１０で説明したルールに基づいて加算ポイント（ＡＰ）を算出する。

２回以上移転されているチケットが無い場合には、処理Ｓ１２０２で加算ポイント（ＡＰ）の加算は無い。

上記の処理によると、例えば同行者のために複数枚チケットを購入し、自分のチケットだけ手元に残し、残りを同行者に移転し、自分と同行者でチケットを使用するようなケースでは、加算ポイント（ＡＰ）が加算されない。一方、不正転売者が転売用に多数チケットを購入し、自分の転売用に一部を残し、残りを他の転売者に移転するようなケースでは、加算ポイントを加算できるようにしている。

図１０や図１２のアルゴリズムは判断手法の一例であるが、本実施例のようにチケット毎に記録された移転の履歴を利用し、種々の条件を組み合わせると、不適切な移転を行っているユーザを絞り込むことが可能となる。

［事例４：実施例２のユーザＢとユーザＪの例］
事例４では、図３の購入者情報テーブル１１４１中に示されるユーザＢ（ユーザＩＤ「1112」）が、購入したチケット（チケットＩＤ「MNQ1」「MNQ2」）のうち一枚を、ユーザＪ（ユーザＩＤ「1120」）に移転する例を説明する。

本実施例では、ユーザＢが購入した2016年1月1日が利用日となっている対象チケットに対し、チケット予約サーバが機能を有効に作用させる例を示す。本実施例では、一定数Ｓ１，Ｓ２，Ｓ３を３０とし、チケット有効化判断を行う一定の時間帯を、チケット利用日当日である2016年1月1日の0時とする。ユーザＢ、ユーザＪは、本事例で対象となるチケット以外のチケット購入、チケット所有者変更には、関わっていないものとする。

本事例では、ユーザＢは、チケットＩＤ「MNQ1」を自分で使用し、チケットＩＤ「MNQ2」をユーザＪに移転する例を考える。コンサートに一緒に行く家族や友人の分を同時に購入し、自分のチケット以外を同行者に移転するような場合である。

上記のような場合は、正統なチケット移転の典型的なパターンである。実施例１では、図１１に示したように、ユーザＢとユーザＪにも加算ポイント（ＡＰ）が加算されてしまう。したがって、このような場合、チケットの有効無効判定を行う処理では、チケット所有者変更履歴ポイント（Ｐ）が増加しないような例外処理を行うことが好ましい。以下では、チケット予約サーバ１１００のチケット有効化判断部１１２４が行う処理として説明する。

事例４は、最初の所有者ユーザＢが所持しているチケット全2枚のうち1枚をユーザＪに所有者変更したが、そのチケットは複数回所有者変更されていないため、ポイント加算なしに全てのチケットが有効化されるパターンである。

［事例４−１：チケットの新規購入時］
ユーザＢの新規チケット購入時には、図４で説明した処理に従い、チケット予約サーバ１１００は、図３の購入者情報テーブル１１４１からユーザＢの「チケット所有者変更履歴ポイント（Ｐ）」３００８を参照し、ポイント（Ｐ）が5であるため、ユーザＢのチケット購入を許可する。購入されたチケットは、チケット情報テーブル１１４２とチケット所有者変更履歴テーブル１１４３に新規データ（チケットＩＤ「MNQ1」「MNQ2」）として追加される。

［事例４−２：チケットの移転時］
ユーザＢ（ユーザＩＤ「1112」）は、この２枚のチケット「MNQ1」「MNQ2」のうち、「MNQ1」のチケットを手元に残し、「MNQ2」のチケットをユーザＪ（ユーザＩＤ「1120」）に移転する。ユーザＢとユーザＪはこのチケットで一緒にコンサートに行く予定である。

移転の判定時においては、図７のフローに基づく判定により、ユーザＪのチケット所有者変更履歴ポイント（Ｐ）が参照され、図３に見られるようにユーザＪの（Ｐ）は１２であり３０未満なので、移転は許可され、チケット所有者変更履歴テーブル１１４３が更新される。

［４−３：チケットの有効化判断時］
チケットの有効化判定時においては、図１２のフローに基づく判定により、図６のチケット所有者変更履歴テーブル１１４３を参照すれば、「MNQ1」のチケットは２人目の所有者がいないので、処理Ｓ１２０２により加算ポイント（ＡＰ）の加算は無い。

「MNQ2」のチケットは、ユーザＪに移転されているが、処理Ｓ１２０３の判定で複数購入のうちの１枚であることがわかり、処理Ｓ１２０４で判定で他の１枚がユーザＢの手元に残っていることがわかり、処理Ｓ１２０５の判定で１回しか移転されていないことがわかるので、加算ポイント（ＡＰ）の加算は無い。

図１３には、実施例２における加算ポイント（ＡＰ）算出のための算出テーブル１１０００（２）の例を示す。図８、図９、図１２の処理により、チケット予約サーバ１１００は、図中矢印で示したように、ユーザＢ、ユーザＪには新規に加算ポイント（ＡＰ）を加算せず、新しいチケット所有者変更履歴ポイント（ｎＰ）１１０４は変化しない。すなわち、チケット予約サーバ１１００は、購入者情報テーブル１１４１のユーザＢ、ユーザＪの「チケット所有者変更履歴ポイント（Ｐ）」３００８をそのままとする。

チケットの有効化判断は、図８の処理Ｓ８０２に基づき、ユーザＢ、ユーザＪのチケット所有者変更履歴ポイント（ｎＰ）を確認する。これらは、図１３に示すとおりそれぞれ５と１２で、Ｓ３＝３０未満のため、MNQ1、MNQ2をすべて有効化し、チケット所有者変更履歴テーブルの「チケット有効化／無効化フラグ」に有効化と書き込む。

［事例４−４：その後のチケット新規購入、移転時］
以上の事例４の説明からわかるように、特定の場合には、チケットの履歴を考慮して、加算ポイント（ＡＰ）の加算を行わないように構成することができる。このため、ユーザＢ、ユーザＪは、その後のチケット新規購入、移転時に、ポイント（Ｐ）の増加による不利益を受けない。

以上の実施例では、チケット所有者変更履歴ポイント（Ｐ）が閾値Ｓ１、Ｓ２、Ｓ３を超えた場合には、購入や移転を禁止することにしたが、その代わりに警報を発する等の他の処理を行っても良い。

以上説明した実施例によれば、チケット購入時からチケット有効化時までの間、チケット所有者の変更履歴を、チケット所有者の生体情報と紐づけて、チケット所有者変更履歴ポイント（Ｐ）として管理しており、チケット有効化時に、ポイント（Ｐ）が所定の値より小さければ有効化し、ポイント（Ｐ）が所定の値より大きければ有効化しない。ポイント（Ｐ）は、一般に変更履歴が多いほど大きくなる。また、ポイント（Ｐ）は例えば生体情報によりユーザと紐づいているので、あるイベントに対するチケットのみならず、他の公演にもユーザ毎に引き継がれる。常習的に転売を繰り返している生体情報を持つユーザは、他のイベントでも「ポイント（Ｐ）が高い」ユーザとして管理されるので、不正な転売を繰り返す程、他のイベントにおいてチケットの有効化がされにくくなる。つまり、有効化されないチケットを転売あるいは使用することになるので、結果として不正な転売抑止につながる効果がある。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。

電子計算機を用いた電子チケットの管理システム等に利用が可能である。

Claims (10)

1. 処理装置と、記憶装置と、入力および出力のためのインタフェースを備え、
   前記記憶装置は、チケット毎にユーザのいずれがチケットを所有したかを時系列に示すチケット所有者変更履歴を格納し、
   前記処理装置は、前記チケット所有者変更履歴を反映したポイントを前記ユーザ毎に算出し、
   前記記憶装置は、前記ポイントを前記ユーザと対応付けて記録し、
   前記処理装置は、前記インタフェースを介して受信する要求に対し、前記ポイントに基づいて、
   （１）特定の条件を満たす前記ポイントに対応する前記ユーザの、前記チケットの購入および移転の少なくとも一つの制限、および、
   （２）特定の条件を満たす前記ポイントに対応する前記ユーザが所有した、前記チケットの利用の制限、
   の少なくとも一つを行う、チケット管理システム。
2. 前記処理装置は、前記チケット所有者変更履歴を反映したポイントを前記ユーザ毎に算出する際に、前記チケット毎に、
   「最終ユーザ以外は、そのユーザを起点としたときに、その後Ｎ人の人を経由した場合は、Ｎポイントを付与する」、および、「最終ユーザは最初のユーザと同じポイントを付与する」というアルゴリズムに基づいて算出を行う、
   請求項1記載のチケット管理システム。
3. 処理装置と、記憶装置と、入力および出力のためのインタフェースを備えたサーバを用いたチケット管理方法であって、
   前記記憶装置が、チケット毎にユーザのいずれがチケットを所有したかを時系列に示すチケット所有者変更履歴を格納する第１のステップ、
   前記処理装置が、前記チケット所有者変更履歴を反映したポイントを前記ユーザ毎に算出する第２のステップ、
   前記記憶装置が、前記ポイントを前記ユーザと対応付けて記録する第３のステップ、
   前記インタフェースが、前記ユーザと前記チケットを特定してなされる所定の要求を受け付ける第４のステップ、
   前記処理装置が、第４のステップで特定された前記ユーザに対応する前記ポイントを参照し、前記所定の要求を許可するかどうかを判定する第５のステップ、
   を実行する、チケット管理方法。
4. 前記第２のステップにおいて、前記チケット毎に、
   「あるユーザに対しては、そのユーザを起点としたときに、その後Ｎ人の人を経由した場合は、Ｎポイントを付与する」というアルゴリズムに基づいて前記ポイントの算出を行う、
   請求項３記載のチケット管理方法。
5. 前記第２のステップにおいて、前記チケット毎に、
   「ただし、最終ユーザは最初のユーザと同じポイントを付与する」という例外アルゴリズムを追加して算出を行う、
   請求項４記載のチケット管理方法。
6. 前記第２のステップにおいて、前記チケット毎に、
   「ただし、当該チケットが同一ユーザに購入された複数枚のうち1枚であり、かつ、前記複数枚のうちの少なくとも1枚が前記同一ユーザの所有として残っており、かつ、前記複数枚のうちの1枚でも複数回移転されていない場合には、付与するポイントをゼロにする」という例外アルゴリズムを追加して算出を行う、
   請求項５記載のチケット管理方法。
7. 前記第２のステップは、
   予め定められた時間情報に対応付けられた複数の前記チケットに関してバッチ処理で行われる、
   請求項３記載のチケット管理方法。
8. 前記第４のステップは、
   所定の前記ユーザによる所定の前記チケットの購入要求の受付であり、
   前記第５のステップは、
   所定の前記ユーザに対応する前記ポイントを参照し、当該ポイントが閾値Ｓ１以上のとき、前記購入要求を拒否する、
   請求項３記載のチケット管理方法。
9. 前記第４のステップは、
   所定の前記ユーザによる所定の前記チケットの移転要求の受付であり、
   前記第５のステップは、
   所定の前記ユーザに対応する前記ポイントを参照し、当該ポイントが閾値Ｓ２以上のとき、前記移転要求を拒否する、
   請求項３記載のチケット管理方法。
10. 前記第４のステップは、
    所定の前記ユーザによる所定の前記チケットの使用あるいは有効化の受付であり、
    前記第５のステップは、
    前記チケットを所有した全てのユーザに対応する前記ポイントを参照し、当該ポイントの少なくとも一つが閾値Ｓ３以上のとき、前記使用あるいは有効化を拒否する、
    請求項３記載のチケット管理方法。

Images