(57)【要約】【課題】過去の試合に基づくユーザの不満を緩和する。【解決手段】  試合情報取得部（１４）は、過去の試合少なくとも１つ、の試合結果に関する試合情報Ｐを取得する。また、第１判定部（１５）は、過去の試合に関連する未実施の試合の観戦権をユーザが保有しているか否かを判定する。また、第２判定部（１６）は、ユーザが過去に購入した観戦権の履歴を表す履歴情報に基づいて、ユーザがお得意様ユーザであるか否かを判定する。アップグレード実行部１８は、未実施の試合の観戦権をユーザが保有していると判定され、且つ、ユーザがお得意様ユーザであると判定され、且つ、試合情報Ｐがアップグレード条件を満足する場合、ユーザが保有している未実施の試合の観戦権の内容を変更する。【選択図】図３
2014048784.tif 000002
【特許請求の範囲】
【請求項１】
過去の試合の状況または結果の少なくとも一方に関する情報を取得する試合情報取得手段と、
前記過去の試合に関連する未実施の試合を観戦する権利をユーザが保有しているか否かを判定する判定手段と、
前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得手段によって取得された前記情報が所定の条件を満足する場合に、前記ユーザが保有する前記権利の内容を変更する変更手段と、
を含むことを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記過去の試合は、観戦する権利が前記ユーザにより購入された試合であること、
を特徴とする情報処理装置。
【請求項３】
請求項１又は２に記載の情報処理装置において、
前記変更手段によって変更される前記権利の内容は、前記試合情報取得手段によって取得された前記情報に基づいて設定されること、
を特徴とする情報処理装置。
【請求項４】
請求項１又は２に記載の情報処理装置において、
前記所定の条件は、前記ユーザが保有する前記権利の内容に応じて設定されること、
を特徴とする情報処理装置。
【請求項５】
請求項１又は２に記載の情報処理装置において、
前記ユーザが過去に購入した、試合を観戦する権利の購入履歴に関する履歴情報に基づいて、前記ユーザが所定条件を満足するユーザであるか否かを判定するユーザ判定手段をさらに含み、
前記変更手段は、
前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得手段によって取得された前記情報が所定の条件を満足し、且つ、前記ユーザ判定手段によって前記ユーザが前記所定条件を満足するユーザであると判定された場合に、前記ユーザが保有する前記権利の内容を変更すること、
を特徴とする情報処理装置。
【請求項６】
請求項５に記載の情報処理装置において、
前記変更手段によって変更される前記権利の内容は、前記履歴情報に基づいて設定されること、
を特徴とする情報処理装置。
【請求項７】
請求項１乃至４のいずれかに記載の情報処理装置において、
前記ユーザの嗜好を示す嗜好データを記憶する嗜好データ記憶部をさらに備え、
前記変更手段は、前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定された場合に、前記試合情報取得手段によって取得された前記情報と、前記嗜好データ記憶部に記憶された前記ユーザの嗜好データとに基づき、前記ユーザが保有する前記権利の内容の変更要否を決定すること、
を特徴とする情報処理装置。
【請求項８】
過去の試合の状況または結果の少なくとも一方に関する情報を取得する試合情報取得ステップと、
前記過去の試合に関連する未実施の試合を観戦する権利をユーザが保有しているか否かを判定する判定ステップと、
前記判定ステップで前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得ステップで取得された前記情報が所定の条件を満足する場合に、前記ユーザが保有する前記権利の内容を変更する変更ステップと、
を含むことを特徴とする情報処理装置の制御方法。
【請求項９】
過去の試合の状況または結果の少なくとも一方に関する情報を取得する試合情報取得手段、
前記過去の試合に関連する未実施の試合を観戦する権利をユーザが保有しているか否かを判定する判定手段、
前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得手段によって取得された前記情報が所定の条件を満足する場合に、前記ユーザが保有する前記権利の内容を変更する変更手段、
としてコンピュータを機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理装置の制御方法、及びプログラムに関する。
【背景技術】
【０００２】
スポーツの試合の興行者やスタジアム、さらに試合を行うチーム等にとっては、観戦チケットが多数購入されること、あるいは観戦者がリピーターとなって繰り返し試合に足を運んでくれることが重要であり、種々の工夫が行われている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−５６１３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記特許文献１には、観戦チケットを完売する方法として、販売開始後の販売状況が思わしくない場合に、予め興行者のチケット販売サイトで会員登録してくれた会員に対して割引チケットの案内を行うシステムが示されている。但し、これは、観戦チケットを完売する方法に関するものであり、観戦者がリピーターとなってもらうことまでが考慮されたものではない。
【０００５】
一般に、スポーツの試合の興行者やスタジアム、さらに試合を行うスポーツチーム等の団体及びスポーツ選手等の個人等の試合実行主体は、試合によって、ユーザ（例えば、試合実行主体の支援者）を満足させることを望む。しかしながら、試合の内容によっては、却って、ユーザを不満にさせる場合がある。例えば、単純にユーザの贔屓チームが負けてしまったり、あるいは、仮に試合で勝利を収めたとしてもその試合の内容が凡戦である場合等である。ユーザを不満にさせてしまう。そして例えば、不満を感じているユーザから、試合実行主体又は試合実行主体の関係者（例えば、試合実行主体のオーナー又は試合実行主体とオーナーを同じくする他の試合実行主体など）を支援する意欲が奪われ、その結果、ユーザが試合観戦を行わなくなったり、ファンサービスの催し等への参加を見送るようになる可能性がある。このような傾向が継続すると、スポーツチームやそのオーナー、あるいはスタジアム運営側は円滑な経営を行なえなくなり、ユーザへのサービスも低下してしまい、さらにユーザが離れてしまうといった状況を招きかねない。
【０００６】
そこで、本発明の目的は、過去の試合の結果やその内容によってユーザが抱える可能性のある不満を未然に解消し、その結果、例えばユーザがリピーターとして継続的に試合観戦をしてくれるようなサービスを提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を実現するために、本発明は以下の構成をとる。なお、本発明の理解を容易にするため添付図面の参照符号を括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。
【０００８】
本発明に係る情報処理装置（２）は、過去の試合の状況または結果の少なくとも一方に関する情報を取得する試合情報取得手段（１２、１４）と、前記過去の試合に関連する未実施の試合を観戦する権利をユーザが保有しているか否かを判定する判定手段（１５）と、前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得手段によって取得された前記情報が所定の条件を満足する場合に、前記ユーザが保有する前記権利の内容を変更する変更手段（１８）と、を含むことを特徴とする。
【０００９】
本発明に係る情報処理装置（２）は、例えば、過去の試合の結果がユーザの満足できない内容であった場合（その試合でユーザのお気に入りチームが負けたり、その試合自体が凡戦で面白くなかった場合等）に、もし、そのユーザがその後に行われる試合の観戦権、例えば観戦チケットを購入済であれば、その観戦チケットの内容をグレードアップするのである（野球の場合であれば、外野席の観戦チケットを内野席の観戦チケットに変更する等）。この結果、ユーザは過去の試合の内容に対して抱えていた不満が解消されることになる。あるいは、不満が完全には解消されなくても、ユーザに対する謝意または陳謝の気持ちが込められたサービスを受けられたことで、ユーザは観戦した試合のチームあるいはスタジアム等に対して好感を持つことになるため、ユーザの今後の継続的な観戦への意欲喚起を図ることができる。
【００１０】
また、本発明に係る情報処理装置の制御方法は、過去の試合の状況または結果の少なくとも一方に関する情報を取得する試合情報取得ステップと、前記過去の試合に関連する未実施の試合を観戦する権利をユーザが保有しているか否かを判定する判定ステップと、前記判定ステップで前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得ステップで取得された前記情報が所定の条件を満足する場合に、前記ユーザが保有する前記権利の内容を変更する変更ステップと、を含むことを特徴とする。
【００１１】
また、本発明に係るプログラムは、過去の試合の状況または結果の少なくとも一方に関する情報を取得する試合情報取得手段（１２、１４）、前記過去の試合に関連する未実施の試合を観戦する権利をユーザが保有しているか否かを判定する判定手段（１５）、前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得手段によって取得された前記情報が所定の条件を満足する場合に、前記ユーザが保有する前記権利の内容を変更する変更手段（１８）、としてコンピュータを機能させることを特徴とする。
【００１２】
また、本発明に係るコンピュータ読み取り可能な情報記憶媒体は、上記プログラムが記憶されたコンピュータ読み取り可能な情報記憶媒体である。なお、上記制御方法、プログラム、及び情報記憶媒体、による作用及び効果は、上記情報処理装置について記載した内容と同じである。
【００１３】
本発明の一態様では、前記過去の試合は、観戦する権利が前記ユーザにより購入された試合であってよい。ユーザが既に行われた試合の結果を知る手段としては、ＴＶ観戦やネットワークで結果を知る場合もあるが、ユーザ自身がその試合の観戦チケットを購入した場合には、その分、その試合に対する思い入れが大きくなる。特に、ユーザ自身がスタジアム等に足を運んで試合を観戦した場合には、ユーザの抱える不満はＴＶ観戦等に比べてより大きなものとなる。従って、特にこの場合に本発明の効果は有用なものとなる。
【００１４】
また、本発明の一態様では、前記変更手段によって変更される前記権利の内容は、前記試合情報取得手段によって取得された前記情報に基づいて設定されてよい。ここで、前記試合情報取得手段によって取得された前記情報とは、例えば過去の試合の内容に関するものであり、過去の試合の内容によって観戦チケットグレードアップの度合いを変えるようにするのである。つまり、過去の試合の内容がユーザによって不満度の高いものであればあるほど、グレードアップの度合いも高くして、ユーザの不満を解消するようにする。
【００１５】
また、本発明の一態様では、前記所定の条件は、前記ユーザが保有する前記権利の内容に応じて設定されるものとしてよい。例えば、ユーザの購入済の観戦チケットのグレードが元々高い場合には、ユーザの購入済の観戦チケットのグレードが元々低い場合よりも、前記所定の条件を厳しくしてよい。即ち、ユーザの購入済の観戦チケットのグレードが元々低い場合には、過去の試合の内容が極端に悪い場合も少々悪い場合も、グレードアップする一方、ユーザの購入済の観戦チケットのグレードが元々高い場合には、過去の試合の内容が極端に悪い場合にのみ、グレードアップするのである。理由は、元々、グレードの高い観戦チケットを購入しているユーザは、それまでの試合の内容が多少悪くても観戦に行く可能性が高いのに対して、グレードが低い観戦チケットを購入しているユーザは、それまでの試合の内容が酷ければ観戦を止めてしまう可能性もあり得るからである。すなわち、興行側（運営側）としては、観戦チケット販売後であっても、観戦には確実に来てほしいため、観戦を止めてしまう可能性があるユーザ（即ち、低いグレードの観戦チケットを購入しているユーザ）の観戦チケットをグレードアップし易くして、観戦に誘導するのである。
【００１６】
また、本発明の一態様では、前記情報処理装置（２）は、前記ユーザが過去に購入した、試合を観戦する権利の購入履歴に関する履歴情報に基づいて、前記ユーザが所定条件を満足するユーザであるか否かを判定するユーザ判定手段（１６）をさらに含み、前記変更手段は、前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定され、且つ、前記試合情報取得手段によって取得された前記情報が所定の条件を満足し、且つ、前記ユーザ判定手段によって前記ユーザが前記所定条件を満足するユーザであると判定された場合に、前記ユーザが保有する前記権利の内容を変更してよい。
【００１７】
この構成によれば、購入済の観戦チケットのグレードアップは、ユーザが所定条件を満足する場合に限定される。所定条件とは、例えばユーザの観戦チケットの購入履歴に関するものであり、過去に何度も試合のチケットを購入してくれているというように、言わばユーザがお得意様であるか否かである。ユーザがお得意様である場合、試合への思い入れはより強い（例えば贔屓チームの熱烈なファンである）と考えられるため、試合の内容が思わしくなかったときの不満はより大きなものであることが想定される。従って、特にこの場合に本発明の効果は有用なものとなる。また、この構成によれば、ユーザは何度も観戦チケットを購入している者への特別のサービスが与えられているという認識を持つので、満足感を覚え、興行者やスタジアム等に好感を持つことになる。なお、所定条件は上記以外にも、ユーザが過去に同じ興行者あるいはスタジアムで何度も観戦チケットを購入してくれていることでもよい。同じ興行者である場合、試合や催し物は異なるものであってもよい。例えば、手元にあるのが野球観戦チケットである場合に、過去に購入したものがサッカーのチケットやコンサートのチケット等であってもよい。
【００１８】
また、本発明の一態様では、前記変更手段によって変更される前記権利の内容は、前記履歴情報に基づいて設定されてよい。この構成においては、ユーザの履歴情報に基づき、例えばユーザの過去の観戦チケットの購入枚数が多いほど、グレードアップのレベルを高くする。従って、多くの観戦チケットを購入しているユーザはより良い待遇を受けることができるので、高い満足感が得られる。
【００１９】
また、本発明の一態様では、前記ユーザの嗜好を示す嗜好データを記憶する嗜好データ記憶部（１７）をさらに備え、前記変更手段は、前記判定手段によって前記ユーザが前記未実施の試合を観戦する権利を保有していることが判定された場合に、前記試合情報取得手段によって取得された前記情報と、前記嗜好データ記憶部に記憶された前記ユーザの嗜好データとに基づき、前記ユーザが保有する前記権利の内容の変更要否を決定するようにしてもよい。
【００２０】
こうすれば、ユーザが過去の試合の内容に不満を感じているか否かを、ユーザの嗜好を考慮して判断できる。ここで、ユーザの嗜好とは、例えば試合の内容に対する嗜好であり、例えば、乱打戦を好む、あるいは投手戦を好むといったものが挙げられる。
【図面の簡単な説明】
【００２１】
【図１】観戦チケット販売サーバの構成を例示する図である。
【図２】価格表を例示する図である。
【図３】観戦チケット販売サーバにて実現される機能群を示す機能ブロック図である。
【図４】日程表を例示する図である。
【図５】チケット購入履歴を例示する図である。
【図６Ａ】アップグレード制御テーブルを例示する図である。
【図６Ｂ】アップグレード制御テーブルを例示する図である。
【図７】空き状況データを例示する図である。
【図８】制御部が実行する処理を例示するフロー図である。
【図９】制御部が実行する処理を例示するフロー図である。
【図１０】アップグレード情報を例示する図である。
【図１１】制御部が実行する処理を例示するフロー図である。
【図１２】テーブルを例示する図である。
【図１３】観戦チケット販売サーバにて実現される機能群を示す機能ブロック図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態の例について図面に基づき詳細に説明する。
【００２３】
［観戦チケット販売サーバ］
図１は、本発明の実施形態に係る情報処理装置たる観戦チケット販売サーバ２の構成を例示する図である。観戦チケット販売サーバ２は、プロ野球チーム「Ｗ」（以下、「Ｗチーム」と表記する）のオーナー企業あるいは観戦が行われるスタジアムまたは球場が所有するサーバコンピュータであり、制御部４、主記憶６、ハードディスク８、及びネットワークインタフェース１０を備えている。
【００２４】
制御部４は、マイクロプロセッサであり、主記憶６に記憶されるプログラムに従って各種情報処理を実行する。また、主記憶６は、ＲＡＭ及びＲＯＭであり、主記憶６には、上記プログラムの他、各種情報処理に必要なデータが格納される。上記プログラムは、ＤＶＤ（登録商標）−ＲＯＭなどの情報記憶媒体から読み出されて主記憶６に格納される。なお、上記プログラムは、ネットワークからダウンロードされて主記憶６に格納されてもよい。また、ハードディスク８には、各種データが記憶される。ハードディスク８に記憶される情報については後述する。また、ネットワークインタフェース１０は、観戦チケット販売サーバ２をネットワークに接続するためのインタフェースである。観戦チケット販売サーバ２は、ネットワークを介して、Ｗチームのファンクラブ会員たる複数のユーザ３それぞれのクライアント端末５、及び複数の券売機７とデータ授受可能となっている。
【００２５】
Ｗチームは、６つのプロ野球チームが所属するプロ野球リーグに所属しており、所定の日程で、他の５つのプロ野球チームとリーグ戦を行う。本実施形態の場合、観戦チケット販売サーバ２は、Ｗチームのホーム球場で行われる、Ｗチームの試合の観戦チケットを販売するために用いられる。具体的には、ユーザ３は、自分のクライアント端末５で観戦チケット販売サーバ２にアクセスした後、観戦を希望する試合と購入を希望する観戦チケットの種別とを指定し、注文確定操作を行う。注文確定操作が行われると、観戦チケット販売サーバ２により、固有の注文コードが電子メールでユーザ３に通知される。ユーザ３は、注文コードをコンビニエンスストア等の小売店舗に設置された券売機７に入力し代金を支払うことにより、券売機７から発券される観戦チケットを受け取る。ちなみに、観戦チケットは、試合を観戦する権利（以下、観戦権と表記する）を証する権利証書であり、観戦チケットを購入することは、観戦権を購入することを意味する。なお、観戦チケットは、紙の証書ではなく、携帯電話や携帯端末等に記憶される電子証書であってもよい。
【００２６】
なお、観戦チケットは、Ａチケットと、Ｂチケットと、Ｃチケットと、Ｄチケットと、Ｅチケットと、の５種類存在する。図２に、ハードディスク８に記憶される価格表を例示した。観戦チケットより証される観戦権の内容は、観戦チケットのチケット種別により異なる。すなわち、Ａチケットは、グラウンドのすぐ側にあるＡシートで試合観戦する観戦権を証する観戦チケットであり、最も高額な観戦チケットである。Ａチケットは、グレードが最も高い観戦チケットである。Ｂチケットは、Ａシートと比べグラウンドから離れた位置にあるＢシートで試合観戦する観戦権を証する観戦チケットであり、二番目に高額な観戦チケットである。Ｂチケットは、グレードが二番目に高い観戦チケットである。Ｃチケットは、Ｂシートと比べグラウンドから離れた位置にあるＣシートで試合観戦する観戦権を証する観戦チケットであり、三番目に高額な観戦チケットである。Ｃチケットは、グレードが三番目に高い観戦チケットである。Ｄチケットは、Ｃシートと比べグラウンドから離れた位置にあるＤシートで試合観戦する観戦権を証する観戦チケットであり、四番目に高額な観戦チケットである。Ｄチケットは、グレードが四番目に高い観戦チケットである。Ｅチケットは、Ｄシートと比べグラウンドから離れた位置にあるＥシートで試合観戦する観戦権を証する観戦チケットであり、最も低額な観戦チケットである。Ｅチケットは、グレードが最も低いチケットである。ユーザ３は、購入した観戦チケットのグレードが高いほどグラウンドから近い位置で試合観戦を楽しめる。
【００２７】
なお、本実施形態の場合、観戦チケット販売サーバ２は、Ｗチームとオーナー企業を同じくするサッカーチームＹが行う試合の観戦チケットの販売も行える。サッカーチームＹの試合の観戦チケットも複数種あり、それぞれグレードが異なる。
【００２８】
ところで、Ｗチームが行った試合の内容によっては、ユーザ３が不満を感じる場合がある。例えば、Ｗチームが試合でよい結果を残せていない場合、ユーザ３は不満を感じる。また、その結果、例えば不満を感じているユーザ３から、Ｗチーム又はＷチームのオーナー企業を支援する意欲が、奪われてしまう。例えば、ユーザ３から、Ｗチームの試合の観戦に訪れる意欲が奪われてしまう。
【００２９】
そこで、この観戦チケット販売サーバ２では、Ｗチームが試合でよい結果を残せていない場合に、Ｗチームが行った試合に基づくユーザ３の不満を緩和すべく、ユーザ３が保有している未実施のＷチームの試合の観戦チケット、がアップグレードされるようになっている。本実施形態の場合、Ｗチームが試合でよい結果を残せていない場合に、アップグレード案内用電子メールが、未実施の試合の観戦チケットを保有しているユーザ３に、送信されるようになっている。また、アップグレード案内用電子メールを受け取ったユーザ３が、アップグレード案内用電子メールに記載の手順を踏むことにより、ユーザが保有する観戦権がより高いグレードの観戦権にアップグレードされるようになっている。例えば下記の文面が、アップグレード案内用電子メールの文面である。
「ユーザＡ様
Ｗチームは日々努力しておりますが、６月３日の段階では、努力が結果に結びついていない状況です。
そこで、６月１７日は、より近くで選手達をご声援いただけるよう、ご希望であればお持ちのＥチケットをＢチケットにアップグレード致します。
アップグレードをご希望の場合、ユニークＩＤ「ＸＸＸ」を最寄りの券売機に入力して、アップグレード証明書をお受け取り下さい。
また、ご来場の際には、アップグレード証明書を、既にお持ちのＥチケットとともに、球場係員にご提示下さい。」
【００３０】
以下、Ｗチームの行った試合に基づくユーザ３の不満を緩和するための技術について説明する。
【００３１】
［機能ブロック］
図３は、制御部４が上記プログラムに従って動作することにより、観戦チケット販売サーバ２にて実現される機能群を示す機能ブロック図である。同図に示すように、観戦チケット販売サーバ２では、試合結果取得部１２と、試合情報取得部１４と、第１判定部１５と、第２判定部１６と、アップグレード実行部１８と、が実現される。これらは、制御部４を主として実現される。なお、試合情報取得部１４は、「試合情報取得手段」に相当する。また、第１判定部１５は、「判定手段」に相当する。また、第２判定部１６は、「ユーザ判定手段」に相当する。また、アップグレード実行部１８は、「変更手段」に相当する。
【００３２】
［試合結果取得部］
試合結果取得部１２は、過去の試合の少なくとも１つ、の試合結果を取得する。本実施形態の場合、ハードディスク８に、Ｗチームの試合日程を表す日程表が記憶される。ここでは、Ｗチームがホーム球場で行う試合の試合日程を表す日程表が記憶される。図４に日程表を例示した。日程表では、試合がその実施日により表され、試合ごとに、その試合におけるＷチームの対戦相手とその試合の試合結果が保持される。試合結果は、試合の最終結果を示すデータであり、ハイフン記号の左側はＷチームの得点を示し、ハイフン記号の右側は対戦相手の得点を示している。試合結果は、各チームの安打数、奪三振数、及び出塁数を示すデータも含む。未実施の試合の試合結果は、「ｎｕｌｌ」値となる。本実施形態の場合、試合結果取得部１２は、日程表から、過去の試合すなわち実施済みの試合少なくとも１つ、の試合結果を読み出す。ここでは、試合結果取得部１２は、過去の所定期間内に実施された試合複数の試合結果を読み出す（後記図８のＳ１０７及びＳ１０８参照）。なお、試合結果取得部１２は、過去の試合１つ、例えばＷチームが最後に行った試合、の試合結果だけを読み出してもよい。また、過去の所定期間を図８においては２週間としているが、より最近の試合結果や試合状況に基づく判断を行うために、１週間あるいは３日間としてもよい。さらに、過去の所定期間ではなく、遡る過去の試合数としてもよい。この場合、例えば、過去の１０試合、あるいは５試合、３試合等で判断してもよい。
【００３３】
なお、本実施形態の場合、「過去の試合」（以下、試合Ｙと表記する）は、「或るユーザ３（以下、注目ユーザと表記する）により観戦チケットが購入された実施済みの試合」である。すなわち、本実施形態では、各ユーザ３のチケット購入履歴（履歴情報）を保持する履歴データベースがハードディスク８に保持される。チケット購入履歴（後記図５参照）には、ユーザ３が購入した観戦チケット、すなわち観戦権の履歴が記録されている。また、本実施形態の場合、履歴データベースがハードディスク８に保持されるだけでなく、試合結果取得部１２が、注目ユーザのチケット購入履歴を参照して、例えば、過去の所定期間内に実施され、且つ、注目ユーザにより観戦チケットが購入された試合を試合Ｙとして特定し、特定した試合Ｙの試合結果を日程表から読み出す。
【００３４】
図５に、或るユーザ３のチケット購入履歴を例示した。同図に示すように、チケット購入履歴は、ユーザ３により観戦チケットが購入された試合を示す情報（すなわち、試合の実施日）を保持する。また、チケット購入履歴は、括弧内に記載されるように、ユーザ３により観戦チケットが購入された試合に関連付けて、ユーザ３により購入されたその試合の観戦チケットのチケット種別を示す情報も保持している。そのため、チケット購入履歴により、ユーザ３により購入された観戦チケットの履歴も示される。
【００３５】
［試合情報取得部］
試合情報取得部１４は、試合結果取得部１２により取得された少なくとも１つの試合Ｙの試合結果に基づいて、過去の試合に関する試合情報Ｐ（情報）を取得する（図８のＳ１０９及びＳ１１０参照）。試合情報Ｐは、上記少なくとも１つの試合ＹにおけるＷチームの成績を示す情報である。試合Ｙが複数ある場合、例えば、Ｗチームの勝率、Ｗチームの負け数、Ｗチームの連敗数、両チームの合計安打数が所定数（例えば２０本）以上の試合たる乱打戦の数、及び両チームの両投手の奪三振数がいずれも１０個以上の試合、あるいは両投手の奪三振数がいずれも８個以上で、且つ、両チームの出塁数がいずれも６個以下の試合たる投手戦の数などが試合情報Ｐとして用いられる。また、試合Ｙが１つである場合、例えば、Ｗチームの得点から対戦相手チームの得点を減算した差、及びＷチームの安打数などが試合情報Ｐとして用いられる。ここでは、試合Ｙが複数あるので、試合情報取得部１４は、Ｗチームの勝率を、試合情報Ｐとして算出する。
【００３６】
[第１判定部]
第１判定部１５は、注目ユーザが、上記過去の試合Ｙと関連する未実施の試合（以下、試合Ｘと表記する）の観戦権を保有しているか否かを判定する。本実施形態の場合、試合Ｘは、ホーム球場で今後行われるＷチームの試合であり、第１判定部１５は、注目ユーザのチケット購入履歴（図５参照）に基づいて、注目ユーザが試合Ｘの観戦権を保有しているか否かを判定する（図８のＳ１０４参照）。
【００３７】
[第２判定部]
第２判定部１６は、注目ユーザが、お得意様条件を満足するユーザ（以下、お得意様ユーザと表記する）であるか否かを、注目ユーザのチケット購入履歴に基づいて判定する（図８のＳ１０５及びＳ１０６参照）。本実施形態の場合、第２判定部１６は、注目ユーザのチケット購入履歴に基づいて、注目ユーザの評価を示す評価情報Ｃを生成する。ここで、評価情報Ｃは、例えば、注目ユーザにより観戦チケットが購入されている試合の数である。また、例えば、評価情報Ｃは、注目ユーザがここまで支払った観戦チケットの購入代金の総額である。そして、第２判定部１６は、評価情報Ｃの値が閾値ＴＨ以上であるか否かを判定する。評価情報Ｃの値が閾値ＴＨ以上である場合、注目ユーザはお得意様ユーザであると判定され、評価情報Ｃの値が閾値ＴＨ未満である場合、注目ユーザはお得意様ユーザでないと判定される。ここで、閾値ＴＨは所定期間内における値としてもよい。所定期間は、例えば６か月あるいは３カ月、１か月等、任意に設定することができる。この場合、例えば、過去６か月以内に５枚以上の観戦チケットを購入したユーザをお得意様ユーザと判断するというようにしてもよい。あるいは、過去３カ月以内に所定金額以上の支払いをしたユーザをお得意様ユーザと判断してもよい。
【００３８】
［アップグレード実行部］
アップグレード実行部１８は、第１判定部１５により注目ユーザが試合Ｘの観戦権を保有していると判定され、且つ、第２判定部１６により注目ユーザがお得意様ユーザであると判定され、且つ、上記少なくとも１つの試合Ｙの内容が注目ユーザに不満を感じさせ得ると推定される場合に、注目ユーザが保有している試合Ｘの観戦権の内容を変更すべく、注目ユーザが保有している観戦チケット（以下、観戦チケットＸ）のチケット種別を、よりグレードが高いチケット種別に変更する。こうして、アップグレード実行部１８は、注目ユーザが保有している試合Ｘの観戦権をアップグレードする。本実施形態では、アップグレード実行部１８は、上記少なくとも１つの試合Ｙの内容が注目ユーザに不満を感じさせ得るかを、試合情報Ｐが後述するアップグレード条件を満足するか否かを判定することによって推定する（図８のＳ１１１参照）。ここではＷチームの勝率が試合情報Ｐとして取得されるので、アップグレード条件は、上記少なくとも１つの試合ＹにおけるＷチームの勝率が５割未満である場合に満足する条件であり、試合情報Ｐがアップグレード条件を満足する場合に、試合Ｙの内容が注目ユーザに不満を感じさせ得ると推定される。
【００３９】
ところで、注目ユーザが感じる不満のレベルは、試合Ｙの内容によって変化する。例えば、注目ユーザが感じる不満のレベルは、Ｗチームの成績の悪さによって変化する。そのため、試合Ｙの内容を考慮せずに、観戦権のアップグレードを一定程度だけ行うようにすると、試合Ｙの内容によっては、注目ユーザの不満を十分に緩和することができない可能性がある。
【００４０】
そこで、本実施形態では、アップグレード実行部１８は、上記少なくとも１つの試合Ｙの内容を考慮し、注目ユーザが保有している試合Ｘの観戦権のアップグレードを制御するようにしている。すなわち、アップグレード実行部１８は、試合情報Ｐに基づいて、注目ユーザが保有している試合Ｘの観戦権の内容の変更を制御する。つまり、アップグレード部１８によって変更される上記観戦権の内容は、試合情報Ｐに基づいて設定される。こうすることで、アップグレード実行部１８は、上記少なくとも１つの試合Ｙに基づく注目ユーザの不満を確実に緩和する。
【００４１】
また、アップグレード条件は、注目ユーザが保有している試合Ｘの観戦権の内容によって変化するようにしてもよい。例えば、注目ユーザが保有している試合Ｘの観戦権のグレードが高い場合、上記少なくとも１つの試合Ｙの内容が極端に酷いものでない限り、試合Ｘの観戦を取りやめるほどの不満を注目ユーザが感じることはないと考えられる。従って、注目ユーザが保有している試合Ｘの観戦権のグレードが高い場合、上記少なくとも１つの試合Ｙの内容が極端に酷い場合のみ、アップグレードが有効になると考えられる。一方、注目ユーザが保有している試合Ｘの観戦権のグレードが低い場合、上記少なくとも１つの試合の内容が極端に酷いわけではない場合でも、試合Ｘの観戦を取りやめるほどの不満を注目ユーザが感じることになると考えられ、上記少なくとも１つの試合Ｙの内容が極端に酷いわけではない場合でも、アップグレードが有効になると考えられる。そのため、注目ユーザが保有している試合Ｘの観戦権の内容を考慮せずに、常に同じアップグレード条件を用いるようにすると、無駄にアップグレードが行われる場合がある。例えば、注目ユーザが保有している試合Ｘの観戦権のグレードが高い場合に、上記少なくとも１つの試合Ｙの内容が極端に酷いわけではないにも関わらず、アップグレードが行われてしまう。
【００４２】
そこで、本実施形態の場合、アップグレード部１８は、注目ユーザが保有している試合Ｘの観戦権の内容に基づいて、アップグレード条件を変化させる。こうすることにより、アップグレード実行部１８は、アップグレードが有効になる場合、すなわち、アップグレードが無駄にならない場合、にのみアップグレードを行う。
【００４３】
すなわち、本実施形態の場合、複数種のアップグレード条件それぞれと、観戦チケットＸのチケット種別に関するチケット条件（権利条件）と、アップグレード制御データと、を関連付けて保持するアップグレード制御テーブルがハードディスク８に記憶される。図６Ａにアップグレード制御テーブルを例示した。本実施形態の場合、試合情報ＰはＷチームの勝率なので、「Ｐ１」は「０．４」に設定され、「Ｐ２」は「０．５」に設定されている。また、本実施形態の場合、アップグレード制御テーブルがハードディスク８に保持されるだけでなく、アップグレード実行部１８が、注目ユーザのチケット購入履歴から観戦チケットＸのチケット種別を特定し、観戦チケットＸのチケット種別が満足するチケット条件に関連付けられたアップグレード条件を試合情報Ｐが満足するか否かを判定する。そして、アップグレード実行部１８は、試合情報Ｐが、観戦チケットＸのチケット種別が満足するチケット条件に関連づけられたアップグレード条件を満足する場合に、当該アップグレード条件に関連付けられたアップグレード制御データが示す変更先のチケット種別に、観戦チケットＸのチケット種別を変更することとなる。図６Ａに示すアップグレード制御テーブルでは、Ｗチームの勝率が極端に低く４割未満の場合、Ｃチケット、Ｄチケット、及びＥチケットがアップグレードの対象となり、Ｂチケットへとアップグレードされることとなる。また、Ｗチームの勝率が極端に低いわけではなく４割と５割との間の勝率である場合、Ｄチケット及びＥチケットのみがアップグレードの対象となり、Ｃチケットへとアップグレードされることとなる。なお、Ｗチームの勝率がそれほど低くなく５割以上の場合、どの観戦チケットもアップグレードの対象とはならない。
【００４４】
なお、本実施形態の場合、アップグレードは、下記のようにして行われる（図９のＳ１１３、Ｓ１１４、図１１のＳ２０３参照）。すなわち、本実施形態の場合、日程表に保持される試合ごとに、その試合における各座席の空き状況を示す空き状況データがハードディスク８に保持される。図７に、或る未実施の試合の空き状況データを例示した。各座席の空き状況には、その座席に割り当てられたユーザ３を示す情報が格納される。なお、誰も割り当てられていない座席、すなわち空席である座席、の空き状況には、その旨を示す情報「空き」が格納される。アップグレード実行部１８は、試合Ｘの空き状況データを参照して、注目ユーザが割り当てられている座席を特定し、特定した座席の空き状況を「空き」に設定する。また、アップグレード実行部１８は、試合Ｘの空き状況データを参照して、変更先のチケット種別に対応する座席のうちから空席である座席１つを選択し、選択した座席に、注目ユーザを割り当てる。このようにして、試合Ｘの空き状況データを更新することにより、アップグレード実行部１８は、アップグレードを行うこととなる。
【００４５】
ちなみに、試合情報Ｐが、例えば、Ｗチームの負け数である場合、アップグレード制御テーブルを、図６Ｂに示すように設定しておくと好適である。図６Ｂに示すアップグレード制御テーブルでは、Ｗチームの負け数が極端に多く６試合以上の場合、Ｃチケット、Ｄチケット、及びＥチケットがアップグレードの対象となり、Ｂチケットへとアップグレードされることとなる。また、Ｗチームの負け数が極端に多いわけではなく４〜５試合である場合、Ｄチケット及びＥチケットのみがアップグレードの対象となり、Ｃチケットへとアップグレードされることとなる。なお、Ｗチームの負け数が少なく３試合以下の場合、どの観戦チケットもアップグレードの対象とはならない。ここで、図６ＢのＰ１、Ｐ２の値は、試合情報Ｐの種類に応じて、具体的にはＷチームの連敗数、上述した乱打戦の数、又は、上述した投手戦の数等に応じて、適宜、設定するのが望ましい。
【００４６】
［処理］
図８及び図９は、制御部４が実行する処理を例示するフロー図である。本実施形態の場合、図９に示す処理は、Ｗチームの試合が実施されるごとに実行される。
【００４７】
まず、制御部４は、現在の日付を特定する（Ｓ１０１）。また、制御部４は、観戦チケット販売サーバ２に登録されているＷチームのファンクラブ会員をソートする（Ｓ１０２）。
【００４８】
そして、制御部４は、一人一人のファンクラブ会員を一番目のファンクラブ会員から順番にユーザ［ｉ］として選択し、選択したユーザ［ｉ］に関し、Ｓ１０３乃至Ｓ１１７に示す処理を実行する。なお、ユーザ［ｉ］が上述した「注目ユーザ」に相当する。
【００４９】
すなわち、制御部４は、ハードディスク８から、ユーザ［ｉ］のチケット購入履歴を読み出す（Ｓ１０３）。そして、制御部４（判定手段）は、ユーザ［ｉ］のチケット購入履歴に基づいて、２週間後にホーム球場で行われる試合（以下、試合Ｘと表記する）の観戦チケットをユーザ［ｉ］が購入済みであるか否か、すなわち、試合Ｘの観戦権をユーザ［ｉ］が保有しているか否かを判定する（Ｓ１０４）。なお、２週間後にホーム球場で試合が行われない場合、制御部４は処理を終了する。
【００５０】
試合Ｘの観戦チケットをユーザ［ｉ］が購入済みである場合（Ｓ１０４のＹＥＳ）、制御部４（ユーザ判定手段）は、ユーザ［ｉ］のチケット購入履歴に基づいて、ユーザ［ｉ］の評価を示す評価情報Ｃを生成する（Ｓ１０５）。ここでは、制御部４は、ユーザ［ｉ］により観戦チケットが購入されている試合の数を評価情報Ｃとして算出する。
【００５１】
そして、制御部４（ユーザ判定手段）は、ユーザ［ｉ］がお得意様ユーザであるか否かを判定する（Ｓ１０６）。すなわち、制御部４は、評価情報Ｃの値が閾値ＴＨ以上であるか否かを判定する。
【００５２】
ユーザ［ｉ］がお得意様ユーザである場合（Ｓ１０６のＹＥＳ）、制御部４（試合情報取得手段）は、ユーザ［ｉ］のチケット購入履歴を参照して、ユーザ［ｉ］により観戦チケットが購入された実施済みの試合であって、現在を遡る過去２週間に実施された試合（以下、試合Ｙと表記する）を特定する（Ｓ１０７）。そして、制御部４（試合情報取得手段）は、各試合Ｙの試合結果を日程表から読み出す（Ｓ１０８）。また、制御部４（試合情報取得手段）は、読み出した試合結果から、各試合ＹにおけるＷチームの勝敗を特定する（Ｓ１０９）。そして、制御部４（試合情報取得手段）は、試合ＹにおけるＷチームの勝率を試合情報Ｐとして算出する（Ｓ１１０）。そして、制御部４（変更手段）は、アップグレード制御テーブル（図６Ａ参照）に保持されるいずれかのアップグレード条件を、試合情報Ｐが満足するか否かを判定する（Ｓ１１１）。
【００５３】
試合情報Ｐがいずれかのアップグレード条件を満足する場合（Ｓ１１１のＹＥＳ）、制御部４（変更手段）は、ユーザ［ｉ］が保有している試合Ｘの観戦チケット（以下、観戦チケットＸと表記する）のチケット種別をユーザ［ｉ］のチケット購入履歴に基づいて特定し、特定した観戦チケットＸのチケット種別が、試合情報Ｐが満足するアップグレード条件に関連付けられたチケット条件を満足するか否かを判定する（Ｓ１１２）。
【００５４】
試合情報Ｐが満足するアップグレード条件に関連付けられたチケット条件を、観戦チケットＸのチケット種別が満足する場合（Ｓ１１２のＹＥＳ）、制御部４（変更手段）は、該アップグレード条件に関連付けられたアップグレード制御データを読み出す（Ｓ１１３）。また、制御部４（変更手段）は、読み出したアップグレード制御データが示す変更先のチケット種別に対応する座席のうちから空席である座席１つを、試合Ｘの空き状況データを参照して選択する（Ｓ１１４）。
【００５５】
そして、制御部４は、固有のユニークＩＤを発行し（Ｓ１１５）、発行したユニークＩＤをユーザ［ｉ］に通知する（Ｓ１１６）。具体的には、制御部４は、発行したユニークＩＤを通知する上記アップグレード案内用電子メールを、ユーザ［ｉ］のメールアドレス宛で送信する。そして、制御部４は、発行したユニークＩＤ、ユーザ［ｉ］を示す情報、Ｓ１１４で選択した座席を示す情報、及び、試合Ｘを示す情報を含むアップグレード情報を、ハードディスク８に保存する（Ｓ１１７）。図１０に、アップグレード情報を例示した。同図に示すように、アップグレード情報は、試合Ｘを示す情報をアップグレード対象試合として保持し、ユーザ［ｉ」を示す情報をアップグレード対象ユーザとして保持し、Ｓ１１４で選択された座席を示す情報を変更先シートとして保持している。アップグレード情報により、アップグレード対象試合たる試合、アップグレード対象ユーザたるユーザ３、及び変更先シートたる座席、が特定される。
【００５６】
なお、Ｓ１０４で否定的な判定結果が得られた場合（Ｓ１０４のＮＯ）、次のユーザ３を対象にＳ１０３以降の処理が実行される。これは、Ｓ１０６で否定的な判定結果が得られた場合（Ｓ１０６のＮＯ）、Ｓ１１１で否定的な判定結果が得られた場合（Ｓ１１１のＮＯ）、及びＳ１１２で否定的な判定結果が得られた場合（Ｓ１１２のＮＯ）も同様である。
【００５７】
アップグレード案内用電子メールを自身のクライアント端末５で確認したユーザ３は、観戦権のアップグレードのため、アップグレード案内用電子メールに記載のユニークＩＤを最寄りの券売機７に入力する。ユニークＩＤが券売機７に入力されると、該ユニークＩＤが券売機７から観戦チケット販売サーバ２へと送信され、該ユニークＩＤを受信した観戦チケット販売サーバ２において図１１のフロー図に例示する処理が実行される。
【００５８】
すなわち、制御部４は、受信したユニークＩＤを含むアップグレード情報（以下、アップグレード情報Ｘと表記する）をハードディスク８から読み出し（Ｓ２０１）、アップグレード情報Ｘを、該ユニークＩＤの送信元の券売機７に送信する（Ｓ２０２）。
【００５９】
そして、制御部４（変更手段）は、チケットのチケット種別をアップグレードすべく、アップグレード情報Ｘ中のアップグレード対象試合が表す試合、の空き状況データ（図７参照）を下記のようにして更新する（Ｓ２０３）。すなわち、制御部４は、この空き状況データを参照して、アップグレード情報Ｘ中のアップグレード対象ユーザが表すユーザ３、が割り当てられている座席を特定し、特定した座席の空き状況を「空き」に設定する。また、制御部４は、アップグレード情報Ｘ中の変更先シートが表す座席に、アップグレード情報Ｘ中のアップグレード対象ユーザが表すユーザ３を割り当てる。
【００６０】
そして、制御部４は、アップグレード情報Ｘを削除する（Ｓ２０４）。
【００６１】
なお、アップグレード情報Ｘを受信した券売機７では、アップグレード情報Ｘに基づき、上記アップグレード案内用電子メールの記載にあるアップグレード証明書が発行されることになる。
【００６２】
［まとめ］
以上のように、この観戦チケット販売サーバ２では、過去の試合の内容に応じて、ユーザ３が保有している未実施の試合の観戦権がアップグレードされる。そのため、過去の試合に基づくユーザ３の不満が緩和される。
【００６３】
また、観戦チケット販売サーバ２では、過去の試合の内容を考慮して、アップグレード後の観戦権の内容が制御される。そのため、ユーザ３の不満がより確実に緩和される。
【００６４】
また、観戦チケット販売サーバ２では、ユーザ３が保有している観戦権の内容に応じて、アップグレード条件が変化する。そのため、アップグレードが無駄に行われないように図ることもできる。
【００６５】
また、観戦チケット販売サーバ２では、おまけの観点から、アップグレードが、お得意様ユーザに対してのみ行われる。そのため、試合観戦をそれほど行っていないユーザ３に対して、試合観戦を行うこと（観戦チケットを購入すること）のインセンティブを提示することができ、チケット販売の促進を図ることもできる。
【００６６】
なお、本発明は、以上に説明した実施形態に限定されるものではない。
【００６７】
例えば、日程表（図４参照）に、Ｗチームの対戦相手と、試合の試合結果と、に加え、さらに試合の試合状況が保持されていてもよい。例えば、試合状況として、各回終了後におけるＷチーム及び対戦相手チームそれぞれの得点を示すデータが日程表に保持されていてもよい。また、試合状況が日程表に保持されるだけでなく、試合結果取得部１２が、上記少なくとも１つの試合Ｙの試合結果の代わりに、試合Ｙの試合状況を取得し、試合情報取得部１４が、取得された試合状況に基づいて上記試合情報Ｐを取得してもよい。例えば、試合情報取得部１４は、対戦相手チームが先制点をあげた試合Ｙの数を、上記試合情報Ｐとして取得してもよい。こうしても、過去の試合に基づくユーザ３の不満が緩和される。なお、試合情報取得部１４は、試合Ｙの試合結果と、試合Ｙの試合状況と、の両方に基づいて試合情報Ｐを取得してもよい。
【００６８】
また例えば、アップグレード実行部１８は、注目ユーザが保有している試合Ｘの観戦権のアップグレードを、試合情報Ｐではなく、注目ユーザのチケット購入履歴に基づいて制御してもよい。すなわち、アップグレード実行部１８は、注目ユーザが保有している試合Ｘの観戦権の内容の変更を、評価情報Ｃに基づいて制御してもよい。この場合、アップグレード制御テーブル（図６Ａ参照）からアップグレード制御データが削除されるとともに、評価情報Ｃに関する複数種の評価条件それぞれと、アップグレード量を示すアップグレード量データと、を対応付けてなるテーブルがハードディスク８に記憶される。図１２にテーブルを例示した。そして、第１判定部１５によって注目ユーザが試合Ｘの観戦権を保有していると判定され、且つ、第２判定部１６によって注目ユーザがお得意様ユーザであると判定され、且つ、試合情報Ｐが、観戦チケットＸのチケット種別が満足するチケット条件に関連づけられたアップグレード条件を満足する場合に、アップグレード実行部１８が、評価情報Ｃが満足する評価条件に関連づけられたアップグレード量データにより示されるアップグレード量だけ、注目ユーザが保有している試合Ｘの観戦権のグレードを上げればよい。こうすれば、アップグレード実行部１８によって変更される注目ユーザの試合Ｘの観戦権の内容が、注目ユーザのチケット購入履歴に基づいて設定される。そのため、試合観戦を行うことのインセンティブを効果的に提示することができ、チケット販売の促進をより一層図ることができる。
【００６９】
また例えば、以上では、アップグレード実行部１８により、アップグレードが無償で行われているが、アップグレードは有償で行われてもよい。すなわち、アップグレード実行部１８は、アップグレード後の観戦チケットＸの価格と、アップグレード前の観戦チケットＸの価格と、の差額から幾分割り引いた額のアップグレード代金の支払いを条件に、アップグレードを行ってもよい。この場合、図１１のＳ２０２のステップの後、アップグレード代金が支払われたことを示す情報を券売機７から受信した場合に、制御部４が、Ｓ２０３以降の処理と、券売機７へのアップグレード証明書の発行指示の送信と、を実行すればよい。こうしても、過去の試合に基づくユーザ３の不満が緩和される。なお、ここにおいて、アップグレード実行部１８は、上記差額からの割引額を、試合情報Ｐ又は評価情報Ｃに基づいて制御してもよい。例えば、試合情報Ｐ又は評価情報Ｃに関する条件に関連づけて割引率がハードディスク８に予め記憶されるとともに、制御部４が、試合情報Ｐ又は評価情報Ｃが満足する上記条件に関連付けられた割引率と上記差額とを乗算して、アップグレード代金を算出すればよい。
【００７０】
また、以上ではＷチームの勝率が試合情報Ｐとして取得されている例を示したが、試合の結果や内容に不満を感じる基準はユーザ３によって異なる。例えば、投手戦を好み乱打戦を嫌うユーザ３もいれば、逆に、乱打戦を好み投手戦を嫌うユーザ３もいる。そこで、試合情報取得部１４は、注目ユーザの嗜好に応じた情報を、試合情報Ｐとして取得するようにしてもよい。この構成の場合、図１３に示すように、ユーザ３の嗜好を示す嗜好データを記憶する嗜好データ記憶部１７がハードディスク８内に設けられ、この嗜好データ記憶部１７のデータに基づき、アップグレード実行部１８でアップグレードの要否が判断される。ここで、ユーザ３の嗜好データは、例えば以下の様にして嗜好データ記憶部１７に記憶される。まず、ユーザ３は予め、クライアント端末５を介して、所定のチームのファン倶楽部のサイトやスタジアムのユーザサービスのサイト等にアクセスし、自らの嗜好を入力する。嗜好を入力するタイミングは、サイトへの登録時や、その後で任意に行われるものとしてよい。
【００７１】
嗜好データの入力は以下のような構成とすることができる。即ち、ユーザは、サイトのユーザ情報入力画面等に予め設定されている試合のスタイルに関する好みの選択肢の中から、自分の嗜好に合ったものを選択する。具体的には、嗜好データには、「１」、「２」、及び「３」のうちユーザ３自身により選択された値が設定される。「１」はユーザ３がＷチームの勝ち試合を好むことを示し、「２」はユーザ３が投手戦を好む（すなわち、乱打戦を嫌う）ことを示し、「３」はユーザ３が乱打戦を好む（すなわち、投手戦を嫌う）ことを示す。ユーザが嗜好データを選択しない場合には、自動的に「１」が選択されるようにしてもよい。また、この場合、図６Ａに例示するアップグレード制御テーブルだけでなく、図６Ｂに例示するアップグレード制御テーブルもハードディスク８に記憶される。そして、試合情報取得部１４は、注目ユーザの嗜好データを読み出し、その嗜好データに対応する値に応じた情報を試合情報Ｐとして取得する。すなわち、嗜好データの値が「１」である場合、試合情報取得部１４は、Ｗチームの勝率を試合情報Ｐとして取得する。また、嗜好データの値が「２」である場合、投手戦を好むユーザは乱打戦を嫌うと考えられるので、試合情報取得部１４は、上述した乱打戦の数を試合情報Ｐとして取得する。そして、過去の所定期間の試合で乱打戦が多いと判断される場合には、ユーザの不満があると判断するのである。また、嗜好データの値が「３」である場合、乱戦戦を好むユーザは投手戦を嫌うと考えられるので、試合情報取得部１４は、上述した投手戦の数を試合情報Ｐとして取得する。そして、過去の所定期間の試合で投手戦が多いと判断される場合には、ユーザの不満があると判断するのである。
【００７２】
具体的には、アップグレード実行部１８が、嗜好データの値に対応するアップグレード制御テーブルを用いて、試合情報Ｐがアップグレード条件を満足するか否かを判定すればよい。すなわち、嗜好データの値が「１」である場合、図６Ａに例示するアップグレード制御テーブルを用い、嗜好データの値が「２」又は「３」である場合、図６Ｂに例示するアップグレード制御テーブルを用いればよい。なお、嗜好データの値が「２」である場合と嗜好データの値が「３」である場合とで、図６Ｂのアップグレード制御テーブルにおけるＰ１及びＰ２の値を適宜変化させてよいが、嗜好データの値が「２」である場合も嗜好データの値が「３」の場合も、Ｗチームの負け数を試合情報Ｐとして用いる場合と同じ値（すなわち、Ｐ１＝４、Ｐ２＝６）であるのが好適である。「Ｗチームの勝ち試合を好む人」にとっての負け試合一試合分の重みと、「乱打戦を嫌う人」にとっての乱打戦一試合分の重みと、「投手戦を嫌う人」にとっての投手戦一試合分の重みと、は同じであると考えられるからである。
【００７３】
また、例えば、過去の試合Ｙは、注目ユーザにより観戦権が購入された試合に限定されなくてもよい。
【００７４】
また、例えば、過去の試合Ｙは、Ｗチームのような団体以外の試合実行主体が行った試合であってもよい。例えば、過去の試合Ｙを行った試合実行主体は、一個人でもよい。
【００７５】
また、過去の試合Ｙは、野球の試合以外の試合であってもよい。これは、上記未実施の試合Ｘについて同様である。また、過去の試合Ｙは、仮想世界の試合（例えば、テレビゲームにおける試合）であってもよい。これも、上記未実施の試合Ｘについて同様である。
【００７６】
また、過去の試合Ｙに関連する未実施の試合たる試合Ｘは、上記実施形態で説明したように過去の試合Ｙと同じ試合実行主体（すなわち、Ｗチーム）が行う試合であってもよいし、過去の試合Ｙの試合実行主体と関連する主体が行う試合であってもよい。例えば、未実施の試合Ｘは、Ｗチームとオーナー企業を同じくする上記サッカーチームＹが行う試合であってもよい。この場合、サッカーチームＹが行う試合ごとに、その試合におけるサッカー場の各座席の空き状況を示す空き状況データ（以下、空き状況データＸと表記する）がハードディスク８に予め記憶されるとともに、アップグレード実行部１８が、試合Ｘの空き状況データＸを更新することにより注目ユーザが保有している試合Ｘの観戦権のアップグレードを行えばよい。なお、Ｓ１０４（図８参照）の判定、及び、Ｓ１１２における試合Ｘの観戦権の特定は、試合Ｘの空き状況データＸに基づいて行われればよい。
【符号の説明】
【００７７】
２  観戦チケット販売サーバ、３  ユーザ、４  制御部、５  クライアント端末、６  主記憶、７  券売機、８  ハードディスク８  ネットワークインタフェース、１２  試合結果取得部、１４  試合情報取得部、１５  第１判定部、１６  第２判定部、１７  嗜好データ記憶部、１８  アップグレード実行部。
【図１】
2014048784.tif 000003
【図２】
2014048784.tif 000004
【図３】
2014048784.tif 000005
【図４】
2014048784.tif 000006
【図５】
2014048784.tif 000007
【図６Ａ】
2014048784.tif 000008
【図６Ｂ】
2014048784.tif 000009
【図７】
2014048784.tif 000010
【図８】
2014048784.tif 000011
【図９】
2014048784.tif 000012
【図１０】
2014048784.tif 000013
【図１１】
2014048784.tif 000014
【図１２】
2014048784.tif 000015
【図１３】
2014048784.tif 000016