JP2021135768A - チケット販売方法、チケット販売プログラム、並びに情報処理装置 - Google Patents

Abstract

【課題】組織に属するユーザに対して、チケットの割引サービスを適切な方法で提供する。【解決手段】アドレス照合部は、端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得する。また、アドレス照合部は、ドメインＤＢを参照して、取得したメールアドレスのドメインがドメインＤＢに記憶されている組織ドメインのいずれかと一致するかを判定する。そして、メール送信部、割引コード照合部、及び機能開放部は、アドレス照合部の照合の結果、ドメインが一致していた場合にチケットの割引サービスのための機能を開放する処理を実行する。【選択図】図１３

Description

本発明は、チケット販売方法、チケット販売プログラム、並びに情報処理装置に関する。

企業等の組織がスポーツチームを運営したり、支援することは多く行われている。企業等は、福利厚生として、従業員に対して限定的に観戦チケットの割引サービスを提供することがある。

割引サービスを提供する方法としては、事前通知しておいたキーワード（割引コード）がチケット販売のウェブサイトにおいて入力された場合に割引サービスの機能を開放するという方法が知られている。キーワードは、例えば社内で配布するチラシに記載したり、各従業員のメールアドレスに対して一斉送信したりすることで、従業員に周知させることができる。

また、近年、スポーツチームなどの団体ごとに、当該団体のアプリがファン向けなどにリリースされている。そして、このアプリには、当該団体のチケット購入機能を有するものもある。

特開２００６−１３９４３１号公報 特開２００８−３１０４７３号公報

チケット購入機能を有するアプリやサイトは、不特定多数のユーザが利用可能であるため、割引などの特定のサービスを利用できる権限を有する第一のユーザも、当該権限を有しない第二のユーザも利用する。なお、第一のユーザは、例えば、団体を支援している会社の社員などである。

例えば、事前に配布されたキーワードを入力させる従来手法を適用し、チケット購入時に、特定のキーワードを入力したユーザに対してのみ、サービスを付与することが考えられる。しかし、キーワード自体が、チラシや社内への一斉送信により広く配布されているため、本来サービスを享受できないユーザが間接的にキーワードを入手できる可能性が高まることが考えられる。

そこで、チケット購入希望者でかつ権限を有するユーザに対してのみ、当該サービスを付与することを支援するための仕組みが望まれる。

そこで、１つの側面では、本発明は、チケット購入希望者が、特定のサービスを享受する権限を有するユーザであるかを判断して、権限を有する場合に当該サービスを享受するための機能を開放するチケット販売方法、チケット販売プログラム、並びに情報処理装置を提供することを目的とする。

一つの態様では、チケット販売方法は、端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得し、チケット購入における特定のサービスを受けることが可能な権利を有する組織を示す組織メールアドレスの組織ドメインを記憶するドメイン記憶部を参照して、取得した前記メールアドレスのドメインが前記ドメイン記憶部に記憶されている組織ドメインのいずれかと一致するかを判定し、前記判定の結果、一致する場合に前記特定のサービスのための機能を、前記メールアドレスに対応するユーザに対して開放する処理を実行する、処理をコンピュータが実行するチケット販売方法である。

チケット購入希望者が、特定のサービスを享受する権限を有するユーザであるかを判断して、権限を有する場合に当該サービスを享受するための機能を開放することができる。

第１の実施形態に係る情報処理システムの構成を概略的に示す図である。 図２（ａ）は、サーバのハードウェア構成を示す図であり、図２（ｂ）は、ユーザ端末のハードウェア構成を示す図である。 サーバ及びユーザ端末の機能ブロック図である。 図４（ａ）は、チケットＤＢの一例を示す図であり、図４（ｂ）は、購入済チケットＤＢの一例を示す図である。 図５（ａ）は、ドメインＤＢの一例を示す図であり、図５（ｂ）は、割引コードＤＢの一例を示す図である。 マイチケットＤＢの一例を示す図である。 情報処理システムにおけるサーバ及びユーザ端末の処理を示すフローチャート（その１）である。 図８（ａ）〜図８（ｄ）は、ユーザ端末の表示部に表示される画面の遷移を説明するための図（その１）である。 図９（ａ）〜図９（ｄ）は、ユーザ端末の表示部に表示される画面の遷移を説明するための図（その２）である。 情報処理システムにおけるサーバ及びユーザ端末の処理を示すフローチャート（その２）である。 図１１（ａ）〜図１１（ｄ）は、ユーザ端末の表示部に表示される画面の遷移を説明するための図（その３）である。 情報処理システムにおけるサーバ及びユーザ端末の処理を示すフローチャート（その３）である。 第１の実施形態の概要を示す図である。 変形例１について説明するための図である。 図１５（ａ）、図１５（ｂ）は、変形例２について説明するための図である。 図１６（ａ）〜図１６（ｃ）は、変形例３について説明するための図である。 図１７（ａ）〜図１７（ｃ）は、変形例４について説明するための図である。 図１８（ａ）は、第２の実施形態に係るユーザ端末のハードウェア構成を示す図であり、図１８（ｂ）は、第２の実施形態で用いるチケットＤＢの一例を示す図である。 第２の実施形態における、ユーザ端末とサーバの処理の一部を示すフローチャートである。 図２０（ａ）〜図２０（ｄ）は、第２の実施形態の画面の遷移を示す図である。 第２の実施形態の変形例を説明するための図である。

《第１の実施形態》
以下、第１の実施形態について、図１〜図１３に基づいて詳細に説明する。図１には、第１の実施形態に係る情報処理システム１００の構成が概略的に示されている。

本実施形態の情報処理システム１００は、情報処理装置としてのサーバ１０と、ユーザが利用する端末であるユーザ端末７０と、を備える。サーバ１０とユーザ端末７０とは、インターネットなどのネットワーク８０に接続されている。

サーバ１０は、チケットの販売に関する処理を実行する情報処理装置である。サーバ１０は、ユーザ端末７０と連携して、一般のユーザに対して正規料金でチケットを販売したり、特定のユーザに対して割引料金でチケットを販売する処理を実行する。

図２（ａ）には、サーバ１０のハードウェア構成が示されている。図２（ａ）に示すように、サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらサーバ１０の構成各部は、バス９８に接続されている。サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（チケット販売プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（チケット販売プログラムを含む）をＣＰＵ９０が実行することにより、図３に示す各部の機能が実現される。なお、図３の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。なお、図３の各部の詳細については後述する。

ユーザ端末７０は、スマートフォンやタブレット端末などの端末である。ユーザ端末７０には、企業のスポーツチームを応援するアプリ（応援アプリ）がインストールされているものとする。応援アプリは、サーバ１０と連携して、企業のスポーツチームの情報（選手の情報や試合日程の情報など）を配信するとともに、試合のチケットを販売したり、試合会場で利用するチケットを表示する機能を有している。

図２（ｂ）には、ユーザ端末７０のハードウェア構成が示されている。図２（ｂ）に示すように、ユーザ端末７０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、ネットワークインタフェース１９７、表示部１９３、入力部１９５及び可搬型記憶媒体用ドライブ１９９等を備えている。表示部１９３は液晶ディスプレイ等を含み、入力部１９５はタッチパネルや物理ボタン等を含む。これらユーザ端末７０の構成各部は、バス１９８に接続されている。ユーザ端末７０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラムをＣＰＵ１９０が実行することにより、図３に示す各部の機能が実現される。

図３には、サーバ１０とユーザ端末７０の機能ブロック図が示されている。

（サーバ１０の機能について）
サーバ１０においては、ＣＰＵ９０がプログラムを実行することにより、チケット販売処理部２０、アドレス照合部２２、メール送信部２４、割引コード照合部２６、及び機能開放部２８としての機能が実現されている。

チケット販売処理部２０は、チケット販売に関する処理を実行する。例えば、チケット販売処理部２０は、ユーザ端末７０からの要求に応じて、ユーザが購入可能なチケットの情報をチケットＤＢ４０から読み出してユーザ端末７０に送信する。また、チケット販売処理部２０は、ユーザが購入したチケットの情報を購入済チケットＤＢ４２に記憶したり、ユーザ端末７０に送信したりする。このとき、チケット販売処理部２０は、ユーザが「一般」である場合と、企業の「社員」である場合とに合わせて、ユーザ端末７０から購入できるチケット（一般販売価格のチケットや社員割引価格のチケット）の情報をユーザ端末７０に提供する。

ここで、チケットＤＢ４０は、販売中のチケットの情報を格納するデータベースであり、一例として、図４（ａ）に示すようなデータ構造を有する。具体的には、チケットＤＢ４０は、「チケットＩＤ」、「チケット名」、「開催日時」、「対象ドメイン」、「チケット価格」の各フィールドを有する。

「チケットＩＤ」のフィールドには、チケットの識別情報が格納される。「チケット名」のフィールドには、チケットの名称が格納される。チケットの名称には、試合の情報の他、割引の有無や優先エリアのチケットか否かの情報も含まれる。「開催日時」のフィールドには、試合の開催日時の情報が格納される。「対象ドメイン」のフィールドには、各チケットの販売対象のユーザを特定する情報として、メールアドレスのドメインのＩＤ（ドメインＩＤ）が格納されている。なお、対象ドメインが「一般」であれば、全ユーザを対象とするチケットを意味する。一方、対象ドメインが「Ｄ００１」であれば、ドメインＩＤ「Ｄ００１」に対応する組織ドメイン「xxxx.com」を含むメールアドレスを利用するユーザ（図５（ａ）参照）を対象とするチケットを意味している。「チケット価格」のフィールドには、各チケットの販売価格の情報が格納されている。なお、組織ドメインは、割引などの特定のサービスを利用可能な組織が、メールアドレスとして利用する情報である。例えば、特定の会社の従業員が、従業員限定のサービスを受けることができる場合、対応する会社の組織ドメインが登録される。

購入済チケットＤＢ４２は、どのユーザ端末７０にインストールされた応援アプリからチケットが購入されたかの情報や、購入されたチケットの情報を格納するデータベースである。購入済チケットＤＢ４２は、一例として図４（ｂ）に示すようなデータ構造を有する。具体的には、購入済チケットＤＢ４２は、「アプリＮｏ．」、「チケットＩＤ」、「購入日時」、「購入金額」、「券種」、「利用日」の各フィールドを有する。

「アプリＮｏ．」のフィールドには、チケットを購入したユーザ端末７０にインストールされている応援アプリの識別情報が格納される。アプリＮｏ．は、各ユーザ端末７０の応援アプリそれぞれに固有の識別情報である。なお、アプリＮｏ．に代えて、端末ＩＤなどの端末を一意に識別できる情報が格納されてもよい。「チケットＩＤ」のフィールドには、購入したチケットの識別情報が格納され、「購入日時」のフィールドには、チケットの購入日時の情報が格納され、「購入金額」のフィールドには、チケットの購入金額の情報が格納される。また、「券種」のフィールドには、大人、子供などの券種の情報が格納され、「利用日」のフィールドには、チケットを利用した年月日の情報が格納される。なお、「利用日」のフィールドが空である場合、未だチケットが利用されていないことを意味する。

図３に戻り、アドレス照合部２２は、ユーザ端末７０から、入力されたメールアドレスを受信し、受信したメールアドレスからドメインを抽出する。そして、アドレス照合部２２は、抽出したドメインがドメインＤＢ４４の「登録ドメイン」のフィールドに記憶されている組織ドメインの１つと一致（完全一致）しているかを照合する。なお、ドメインＤＢ４４には、ユーザ個人のアドレスは登録されておらず、組織で利用されている組織ドメインの情報が登録されている。

ここで、ドメインＤＢ４４は、割引などの特定のサービスを受けられる組織に所属する従業員が利用する組織ドメインの情報と、各組織ドメインを利用する従業員に対する割引サービスの情報と、を予め格納しておくデータベースである。特定のサービスを受けられる組織は、例えば、スポーツチームを運営する会社やスポンサーの会社などである。

ドメインＤＢ４４は、図５（ａ）に示すように、「ドメインＩＤ」、「登録ドメイン」、「認証有効期間」、「購入可能枚数」の各フィールドを有する。

「ドメインＩＤ」のフィールドには、組織ドメインの識別情報が格納されている。「登録ドメイン」のフィールドには、ドメインＩＤごとに、異なる組織ドメインが格納されている。「認証有効期間」のフィールドには、各組織ドメインに対して予め定められている認証の有効期間（ユーザに配布する割引コードの有効期間）が格納されている。「購入可能枚数」のフィールドには、各組織ドメインを利用するユーザが割引価格で購入可能な枚数の上限が格納されている。

図３に戻り、メール送信部２４は、アドレス照合部２２による照合の結果、受信したメールアドレスのドメインがドメインＤＢ４４に格納されている組織ドメインの１つと一致していた場合に、受信したメールアドレスに対してメールを送信する。このメールには、鍵情報としての割引コードが記載されている。なお、メールの詳細については、後述する。メール送信部２４は、メールに記載した割引コードを割引コードＤＢ４６に格納する。

ここで、割引コードＤＢ４６は、各ユーザ端末７０（アプリ）に対して配布した割引コードの情報等を格納するデータベースである。割引コードＤＢ４６は、図５（ｂ）に示すように、「アプリＮｏ．」、「ドメイン」、「割引コード」、「割引コード発行日時」の各フィールドを有する。

「アプリＮｏ．」のフィールドには、割引コードの配布先のメールアドレスをサーバ１０に送信したアプリの識別情報が格納される。「ドメイン」のフィールドには、割引コードの配布先のメールアドレスに含まれる組織ドメインの情報が格納される。「割引コード」のフィールドには、配布した割引コードが格納される。「割引コード発行日時」のフィールドには、割引コードを発行した（配布した）日時の情報が格納される。

図３に戻り、割引コード照合部２６は、ユーザ端末７０において入力された割引コードを、アプリＮｏ．とともに、ユーザ端末７０から取得する。また、割引コード照合部２６は、割引コードＤＢ４６を参照して、取得したアプリＮｏ．と割引コードの組み合わせが割引コードＤＢ４６に記憶されているか照合する。割引コード照合部２６は、照合結果を機能開放部２８に通知する。

機能開放部２８は、割引コード照合部２６による照合の結果、割引コードが正しい場合に、割引コードが入力されたユーザ端末７０における、割引価格でのチケット販売（割引サービス）の機能を開放する。

（ユーザ端末７０の機能について）
ユーザ端末７０においては、ＣＰＵ１９０がプログラムを実行することにより、一般用処理部５０、アドレス情報送信部５２、割引コード送信部５６、及び社員用処理部５８としての機能が実現されている。

一般用処理部５０は、ユーザ端末７０の表示部１９３上に、一般用のチケット購入画面を表示したり、当該画面内において入力された情報をサーバ１０のチケット販売処理部２０に送信したりする。また、一般用処理部５０は、ユーザが購入したチケットの情報をマイチケットＤＢ６０に格納する。ここで、マイチケットＤＢ６０は、購入済の未使用のチケットの情報を格納するデータベースであり、図６に示すようなデータ構造を有する。具体的には、マイチケットＤＢ６０には、図４（ｂ）の購入済チケットＤＢ４２のうち、「アプリＮｏ．」と「利用日」を除いた情報が格納されている。

アドレス情報送信部５２は、ユーザ端末７０においてユーザが入力したメールアドレスをサーバ１０のアドレス照合部２２に送信する。

割引コード送信部５６は、ユーザ端末７０において入力された割引コードを、サーバ１０の割引コード照合部２６に送信する。

社員用処理部５８は、サーバ１０の機能開放部２８が割引サービスの機能を開放した場合に、ユーザ端末７０の表示部１９３上に社員用のチケット購入画面を表示する。また、社員用処理部５８は、表示した画面内に入力された情報をサーバ１０のチケット販売処理部２０に送信する。また、社員用処理部５８は、ユーザが購入したチケットの情報をマイチケットＤＢ６０に格納する。なお、社員用処理部５８はサーバ１０の機能開放部２８が割引サービスの機能を開放していなければ、一切機能しないようになっている。

（情報処理システム１００における処理について）
次に、情報処理システム１００におけるサーバ１０及びユーザ端末７０の処理について、図７、図１０、図１２のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。なお、ユーザ端末７０の処理は、ユーザがユーザ端末７０において応援アプリを立ち上げた段階（図８（ａ）参照）から開始される処理である。図８（ａ）の応援アプリの画面には、「ホーム」、「試合日程」、「選手情報」などのボタンのほか、「限定メニュー」ボタンも設けられている。ユーザが、「試合日程」や「選手情報」のボタンを押した場合には、スポーツチームの各種情報をユーザに提供するための処理が実行される。また、ユーザが「限定メニュー」ボタンを押した場合、スポーツチームを運営する会社の社員限定のサービスをユーザに提供するための処理が実行される。

図７の処理では、まず、ステップＳ１２において、ユーザ端末７０の一般用処理部５０が、ユーザ端末７０の表示部１９３上の「限定メニュー」ボタンが押されるまで待機する。ユーザによって「限定メニュー」ボタンが押されると、一般用処理部５０は、ステップＳ１４に移行する。なお、図７においては示されていないが、ユーザが「限定メニュー」以外のボタンを押した場合には、一般用処理部５０が、押したボタンに対応する処理を実行する。ステップＳ１２の判断が肯定された場合には、一般用処理部５０が、アドレス情報送信部５２に対してその旨を通知する。

ステップＳ１４に移行すると、アドレス情報送信部５２は、ユーザ端末７０の表示部１９３上にメールアドレス入力画面を表示する。具体的には、図８（ｂ）に示すような画面を表示する。アドレス情報送信部５２は、メールアドレス入力画面にて、「従業員限定のサービスの利用を希望する場合には、会社のアドレスを入力してください」というメッセージを併せて提示しても良い。

次いで、ステップＳ１６では、アドレス情報送信部５２が、メールアドレス入力画面において送信ボタンが押されるまで待機する。ユーザは、自己の会社用のメールアドレス（例えば、taroh@xxxx.com）を入力して、送信ボタンを押す。このように、ユーザによって送信ボタンが押された段階で、ステップＳ１８に移行する。

ステップＳ１８に移行すると、アドレス情報送信部５２が、応援アプリの識別情報（アプリＮｏ．）、社員割引でのチケット購入希望の情報とともに、メールアドレスをサーバ１０のアドレス照合部２２に送信する。

一方、サーバ１０では、アドレス照合部２２が、ステップＳ１１０において、ユーザ端末７０から情報を受信するまで待機している。ユーザ端末７０側でステップＳ１８が実行され、ユーザ端末７０から情報を受信すると、アドレス照合部２２は、ステップＳ１１２に移行する。

ステップＳ１１２に移行すると、アドレス照合部２２は、受信したメールアドレスのドメイン（例えば、taroh@xxxx.com）を照合する。具体的には、アドレス照合部２２は、ドメインＤＢ４４を参照して、メールアドレスに含まれるドメイン（xxxx.com）がドメインＤＢ４４に登録されている組織ドメインの１つと完全一致するか否かを判断する。

次いで、ステップＳ１１４では、アドレス照合部２２が、判定結果をユーザ端末７０の一般用処理部５０に送信する。

次いで、ステップＳ１１６では、アドレス照合部２２が、受信したメールアドレスに含まれるドメイン（xxxx.com）が登録済みドメイン（登録済みの組織ドメイン）か否かを判断し、このステップＳ１１６の判断が肯定された場合には、ステップＳ１１８に移行する。ステップＳ１１８では、メール送信部２４が、受信したメールアドレス（taroh@xxxx.com）に対して、割引コードが記載されたメールを送信する。ユーザは、ユーザ端末７０のメールアプリを利用して、メールを受信する。なお、ユーザは、別の端末（会社内で利用している端末等）を用いてメールを受信してもよい。図９（ａ）には、割引コードが記載されたメールの一例が示されている。なお、メール送信部２４は、割引コードをランダムに生成するものとする。また、メール送信部２４は、ドメインＤＢ４４を参照して、組織ドメインに対応する認証有効期間を読み出し、「有効期限」の年月日の情報をメールに表示する。「有効期限」の年月日は、割引コードの発行日に、読み出した認証有効期間を加算した年月日である。そして、メール送信部２４は、メールで送信した割引コードを、アプリＮｏ．、ドメイン、割引コード発行日時と対応付けて、割引コードＤＢ４６（図５（ｂ））に格納する。なお、割引コード照合部２６は、割引コードＤＢ４６に格納されている各割引コードの情報を、認証有効期間（ドメインＤＢ４４参照）を超えたときに消去するようにする。例えば、割引コードＤＢ４６の割引コード「ｖ３ＶｈｘｕＦ８」については、２０１９年１０月１０日から３０日を超えた場合に消去されるため、以降は使用ができなくなる。

これに対し、ユーザ端末７０では、図７のステップＳ１８の後、ステップＳ２０において、一般用処理部５０が、アドレス照合部２２による判定結果を受信するまで待機している。すなわち、サーバ１０においてステップＳ１１４の処理が実行されたタイミングで、ステップＳ２２に移行する。

ステップＳ２２に移行すると、一般用処理部５０が、判定結果に応じた画面を表示する。具体的には、一般用処理部５０は、照合の結果、メールアドレスのドメインが登録済みドメイン（登録済みの組織ドメイン）であった場合（照合ＯＫの場合）には、図８（ｃ）に示すような割引コード入力画面を表示する。図８（ｃ）の画面は、ユーザが割引コードを入力するための画面である。一方、メールアドレスのドメインが未登録のドメイン（未登録の組織ドメインや、フリーメールアドレスなどで用いられる一般ドメイン）であった場合（照合ＮＧの場合）には、図８（ｄ）に示すようなエラー画面を表示する。図８（ｄ）の画面は、社員割引のサービスを利用できない旨を通知する画面である。一般用処理部５０は、この画面を表示した後、「ＴＯＰページへ」のボタンがユーザによって押された段階で、表示をＴＯＰページに変更し、図７、図１０、図１２の全処理を終了する。

ステップＳ２２の処理の後は、図１０のステップＳ３０に移行する。ステップＳ３０では、割引コード送信部５６が、図８（ｃ）の画面において割引コードが入力され、「次へ」ボタンが押されるまで待機する。ユーザが割引コードを入力し、「次へ」ボタンを押すと、割引コード送信部５６は、ステップＳ３２に移行し、割引コードをサーバ１０の割引コード照合部２６に送信する。このとき、割引コード送信部５６は、割引コード照合部２６に対して、アプリＮｏ．も送信するものとする。

一方、サーバ１０の割引コード照合部２６は、図７のステップＳ１１８の後、図１０のステップＳ１３０において、割引コードを受信するまで待機している。割引コード照合部２６は、割引コードを受信すると、ステップＳ１３２に移行し、受信した割引コードが正しいか否かを判断する。この場合、割引コード照合部２６は、受信したアプリＮｏ．と割引コードの組み合わせが、割引コードＤＢ４６に格納されているか否かを判断する。このステップＳ１３２の判断が否定された場合には、ステップＳ１３４に移行し、割引コード照合部２６が機能開放部２８にその旨を通知し、機能開放部２８が、ユーザ端末７０の社員用処理部５８に対してエラーを通知する。一方、ステップＳ１３２の判断が肯定された場合には、ステップＳ１３６に移行し、割引コード照合部２６が機能開放部２８にその旨を通知し、機能開放部２８が、社員用処理部５８に対して機能開放を通知する。ステップＳ１３４又はステップＳ１３６の後は、図１２の処理に移行する。

これに対し、ユーザ端末７０では、ステップＳ３４において、社員用処理部５８が、機能開放の通知を受けたか否かを判断する。このステップＳ３４の判断が否定された場合、すなわちサーバ１０においてステップＳ１３４の処理が実行された場合には、ステップＳ３６に移行し、社員用処理部５８が、エラー画面（図９（ｃ）参照）を表示する。そして、ユーザが図９（ｃ）の画面において「一般用チケット一覧へ」ボタンを押すと、一般用処理部５０が、一般用チケット購入画面（図１１（ａ）参照）を表示する。この場合、一般用処理部５０は、サーバ１０のチケット販売処理部２０と通信して、図１１（ａ）の画面に表示可能なチケットの情報を取得する。なお、チケット販売処理部２０は、チケットＤＢ４０を参照して、対象ドメインが「一般」であるチケットの情報を取得する。

一方、ステップＳ３４の判断が肯定された場合、すなわちサーバ１０においてステップＳ１３６の処理が実行された場合には、ステップＳ３８に移行し、社員用処理部５８は、機能開放メッセージの画面（図９（ｄ）参照）を表示する。そして、ユーザによって図９（ｄ）の画面上の「社内向けチケット一覧へ」ボタンが押された段階で、社員用処理部５８は、社員割引チケット購入画面（図１１（ｂ）参照）を表示する。この場合、社員用処理部５８は、サーバ１０のチケット販売処理部２０と通信して、図１１（ｂ）の画面に表示可能なチケットの情報を取得する。なお、チケット販売処理部２０は、チケットＤＢ４０を参照して、入力されたメールアドレスに含まれるドメインに対応するチケットの情報を取得する。例えば、入力されたメールアドレスに含まれるドメインが「xxxx.com」である場合には、ドメインＤＢ４４（図５（ａ））より、ドメインＩＤ＝Ｄ００１である。したがって、チケット販売処理部２０は、チケットＤＢ４０から、「対象ドメイン」のフィールドに「Ｄ００１」が含まれるチケットの情報を取得する。なお、チケット販売処理部２０は、対象ドメインが「一般」であるチケットの情報も併せて取得してもよい。この場合、図１１（ｂ）の画面内に一般のチケットの情報も表示されることになる。

なお、図１１（ａ）の画面が表示された場合には、一般用処理部５０が以降の処理を実行し、図１１（ｂ）の画面が表示された場合には、社員用処理部５８が以降の処理を実行するようになっている。

次いで、図１２のステップＳ５０に移行すると、一般用処理部５０又は社員用処理部５８が、図１１（ａ）又は図１１（ｂ）の画面において、「購入」ボタンが押されたか否かを判断する。このステップＳ５０の判断が否定された場合には、ステップＳ６２に移行し、一般用処理部５０又は社員用処理部５８は、図１１（ａ）又は図１１（ｂ）の画面において、「マイチケット」ボタンが押されたか否かを判断する。このステップＳ６２の判断が否定された場合には、ステップＳ５０に戻り、肯定された場合には、ステップＳ６４に移行する。すなわち、ユーザが図１１（ａ）又は図１１（ｂ）の画面において、「購入」ボタンを押した場合には、ステップＳ５２〜Ｓ６０の処理が実行され、「マイチケット」ボタンを押した場合には、ステップＳ６４〜Ｓ６８の処理が実行される。

「購入」ボタンが押され、ステップＳ５２に移行すると、一般用処理部５０又は社員用処理部５８は、販売チケット情報の画面を表示する。この場合、一般用処理部５０又は社員用処理部５８は、「購入」ボタンが押されたチケットについての販売チケット情報の画面を表示する。例えば、ユーザが図１１（ｂ）の「購入」ボタンＢ１を押した場合には、図１１（ｃ）に示すような販売チケット情報の画面が表示される。この画面の「上限３枚まで」の表示は、チケット販売処理部２０が、ドメインＤＢ４４から取得した購入可能枚数であるものとする。なお、一般用チケットの場合には、予め定められている上限を表示するものとする。

次いで、ステップＳ５４では、一般用処理部５０又は社員用処理部５８が、販売チケット情報の画面（図１１（ｃ））において、「購入」ボタンが押されるまで待機する。ユーザが、図１１（ｃ）の画面において「購入」ボタンを押すと、ステップＳ５６に移行する。ステップＳ５６では、一般用処理部５０又は社員用処理部５８が、販売チケット情報の画面に入力された情報をサーバ１０のチケット販売処理部２０に送信する。図１１（ｃ）の例では、大人１枚の購入希望の情報がチケット販売処理部２０に送信されることになる。

一方、サーバ１０では、ステップＳ１５０において、チケット販売処理部２０が、情報を受信するまで待機している。したがって、ユーザ端末７０においてステップＳ５６の処理が実行されると、チケット販売処理部２０は、ステップＳ１５２に移行する。ステップＳ１５２に移行すると、チケット販売処理部２０は、購入済チケット情報をユーザ端末７０の一般用処理部５０又は社員用処理部５８に送信するとともに、購入済チケットＤＢ４２に格納する。この場合、チケット販売処理部２０は、購入済チケットＤＢ４２に、ユーザ端末７０のアプリＮｏ．、購入されたチケットのチケットＩＤ、購入日時、購入金額、券種の情報を格納する。なお、ステップＳ１５２では、チケット販売処理部２０は、クレジットカード情報等を用いた決済処理も行う。

これに対し、ユーザ端末７０では、ステップＳ５８において、一般用処理部５０又は社員用処理部５８が、購入済チケット情報を受信するまで待機している。したがって、サーバ１０においてステップＳ１５２の処理が実行されると、ステップＳ６０に移行し、一般用処理部５０又は社員用処理部５８は、マイチケットＤＢ６０に購入済チケット情報を格納する。具体的には、一般用処理部５０又は社員用処理部５８は、図６のマイチケットＤＢ６０に、購入済のチケットのチケットＩＤ、購入日時、購入金額、券種の情報を格納する。その後は、ステップＳ６２に移行する。

ステップＳ６２では、一般用処理部５０又は社員用処理部５８が、「マイチケット」ボタンが押されたか否かを判断する。このステップＳ６２の判断が肯定されると、ステップＳ６４に移行し、一般用処理部５０又は社員用処理部５８は、購入済チケット一覧画面（図１１（ｄ））を表示する。この場合、一般用処理部５０又は社員用処理部５８は、サーバ１０との通信が可能であれば、チケット販売処理部２０を介して、購入済チケットＤＢ４２から、自己のアプリＮｏ．に対応する購入済のチケットの情報を取得し、購入済チケット一覧画面を表示する。一方、サーバ１０との通信ができない状況である場合には、一般用処理部５０又は社員用処理部５８は、マイチケットＤＢ６０から、購入済のチケットの情報を取得し、購入済チケット一覧画面（図１１（ｄ））を表示する。なお、サーバ１０との通信ができない状況としては、例えば、試合会場近くにいるため、観客が多数存在し、電波状況が悪い場合などが想定される。本実施形態では、購入済のチケットをユーザ端末７０とサーバ１０の両方において管理している。したがって、多数の観客が試合会場近くに集まっており、ユーザ端末７０の電波状況が悪い場合にも、購入済チケット一覧画面を表示し、購入済のチケットを利用することができるようになっている。また、ユーザは、チケットを購入したユーザ端末７０以外からもチケットを利用することができる。

次いで、ステップＳ６６では、一般用処理部５０又は社員用処理部５８が、「使う」ボタンが押されるまで待機する。ユーザが図１１（ｄ）の画面において「使う」ボタンを押すと、ステップＳ６８に移行し、一般用処理部５０又は社員用処理部５８は、チケット画面を表示する。チケット画面は、チケットの詳細内容や、二次元コード等が表示された画面であるものとする。ユーザは、このチケット画面を試合会場において提示することにより、試合会場に入場することができる。なお、ユーザがチケットを利用した場合には、購入済チケットＤＢ４２やマイチケットＤＢ６０の「利用日」のフィールドに利用した年月日の情報が格納される。なお、ユーザがチケットを利用した場合には、当該チケットに関する情報を購入済チケットＤＢ４２やマイチケットＤＢ６０から削除するようにしてもよい。

以上により、図７、図１０、図１２の全処理が終了する。なお、図７、図１０、図１２の処理が行われている間にユーザがアプリの使用をやめる操作を行う場合もある。このような操作が行われた場合には、上述した処理が適宜終了するようになっている。

図１３には、本第１の実施形態の概要が示されている。本第１の実施形態においては、図１３に示すように、社員が利用するユーザ端末７０から送信したメールアドレスのドメインが、登録済みの組織ドメインである場合に、サーバ１０は、そのメールアドレスに認証コードを送信する。そして、ユーザ端末７０から送信した認証コードがサーバ１０から送信した認証コードと一致すれば、社員用処理部５８の機能（割引サービスのための機能）を開放する。これにより、社員は、社員割引のサービスを利用できるようになっている。一方、一般のユーザ端末７０との間では、上記処理が行われないため、社員用処理部５８の機能は開放されない。したがって、一般のユーザは、社員割引のサービスを利用できないようになっている。

以上説明した本第１の実施形態では、アドレス照合部２２を含んで、ユーザ端末７０に入力されたメールアドレスを取得する取得部、及び取得したメールアドレスのドメインをドメインＤＢ４４を用いて照合する照合部、としての機能が実現されている。また、メール送信部２４、割引コード照合部２６、機能開放部２８を含んで、チケットの割引サービスのための機能を開放する処理を実行する実行部としての機能が実現されている。

以上、詳細に説明したように、本第１の実施形態によると、アドレス照合部２２は、ユーザ端末７０から、チケット購入希望の情報とともに、入力されたメールアドレスを取得する（Ｓ１１０：肯定）。ドメインＤＢ４４には、スポーツチームの運営を行う会社の社員であること（チケット購入時に割引サービスを受けることが可能な権利を有する組織に属していること）を示すメールアドレスのドメイン（組織ドメイン）が記憶されている。また、アドレス照合部２２は、ドメインＤＢ４４を参照して、取得したメールアドレスのドメインがドメインＤＢ４４に記憶されている組織ドメインのいずれかと一致するかを判定する。そして、メール送信部２４、割引コード照合部２６、及び機能開放部２８は、アドレス照合部２２の照合の結果、ドメインが一致していた場合にチケットの割引サービスのための機能を開放する処理を実行する（Ｓ１１８、Ｓ１３０、Ｓ１３２、Ｓ１３６）。すなわち、サーバ１０は、ユーザが入力したメールアドレスのドメインに基づいて、チケット購入時に割引サービスを受けることが可能な権利を有するか否かを判定し、権利を有するユーザに対して割引サービスを提供するための機能を開放する。したがって、ドメインを使って認証したアドレスに対してのみ、特定のサービスの利用を開放することができる。また、ユーザは、特別な社内手続きを経ずに、社員割引のチケットを購入することができる。さらに、本実施形態では、入力されたアドレスは、所定のタイミングで削除される。例えば、メール送信部２４が、割引コードなど特定のサービスを受けるために必要な鍵情報を、認証されたアドレスに送信したのち、アドレスは削除される。これにより、サーバ１０は個人情報を保持することがないため、メールアドレスなどの個人情報が流出するリスクが低減される。

また、本第１の実施形態では、メール送信部２４が、ユーザ端末７０から取得したメールアドレスに対して、割引サービスを受けるために必要な割引コード（鍵情報）を送信する。そして、ユーザ端末７０から送信された割引コードを取得した場合に、機能開放部２８は、ユーザ端末７０に社員割引チケットの一覧画面を表示させる。これにより、本第１の実施形態では、チラシで割引コードを配布したり、社員のメールアドレスに割引コードを記載したメールを一斉送信したりする場合のように、購入希望があるかどうかもわからない人に割引コードを配布することがない。すなわち、購入希望者であり、かつ割引サービスを受ける権限を有する人に限定して、割引コードを配布することができる。したがって、本来割引サービスを享受できない人が間接的にキーワードを入手できる可能性を低減することができる。また、本第１の実施形態では、社員以外の人が社員に成りすまして、社員のメールアドレスをメールアドレス入力画面に入力したとしても、割引コードは社員のメールアドレスに届くため、割引サービスを受けられないようになっている。

また、本第１の実施形態では、割引コードには、有効期限が設定されている（ドメインＤＢ４４の認証有効期間参照）。そして、割引コード照合部２６及び機能開放部２８は、有効期限が切れていない割引コードをユーザ端末７０から取得した場合に、社員割引チケットの一覧画面を表示する。これにより、社員の種別等に応じて、割引コードを使える時期を適切に定めることができる。例えば、正規社員であれば、有効期限を長めにし、派遣社員などであれば、有効期限を短めに設定することができる。

また、本第１の実施形態では、割引サービスの内容を、組織ドメインごとに設定できる（図４（ａ）のチケットＤＢ４０参照）。これにより、社員の種別、会社への貢献度等に応じて、割引内容を適切に設定することができる。

なお、上記第１の実施形態では、ユーザ端末７０から取得したメールアドレスのドメインが、登録済みの組織ドメインと一致していた場合に、ユーザ端末７０とサーバ１０との間で割引コードをやり取りし、その結果に基づいて、機能開放部２８が、ユーザ端末７０の社員用処理部５８の機能を開放することとした。しかしながら、これに限らず、例えば、ユーザ端末７０から取得したメールアドレスのドメインが、登録済みの組織ドメインと一致していた場合に、機能開放部２８が、ユーザ端末７０の社員用処理部５８の機能を開放することとしてもよい。この場合、割引コードのやり取りが無くなるので、ユーザの手間を軽減することができる。

（変形例１）
なお、上記第１の実施形態においては、ドメインＩＤごとに、社員割引の内容を異ならせてもよい。例えば、図１４に示すように、ドメインＤＢ４４において、各ドメインＩＤに対して、購入可能なチケット（当日から何日後までのチケットを購入可能か）や、割引率（１００％の場合は、通常の社員割引、２００％の場合には、通常の２倍の割引率）を紐づける。

例えば期間従業員については、購入可能なチケットの範囲を狭くし、正社員については、購入可能なチケットの範囲を広くするなどすることができる。これにより、チケットを使用するときに社員の資格を失っている（退職している、雇用契約が切れている）ような状況が発生する可能性を低くすることができる。また、会社への貢献度に合わせて割引率を設定することができる。

（変形例２）
なお、上記第１の実施形態では、ユーザにメールアドレスを入力させる際に、併せて所属する部門名を入力させてもよい。例えば、アドレス情報送信部５２は、図８（ｂ）の画面に代えて、図１５（ａ）に示すような画面を表示部１９３上に表示する。この場合、図１５（ｂ）に示すように、ドメインＤＢ４４において、組織ドメインと部門名との組み合わせごとに、ドメインＩＤを割り当てることができる。また、チケットＤＢ４０において、各ドメインＩＤ（組織ドメインと部門名との組み合わせ）に対して、割引するチケットを割り当てるようにすればよい。このようにすることで、会社の部門ごとに割引サービスを異ならせることができる。

（変形例３）
なお、上記第１の実施形態においては、図１６（ａ）に示すように、割引コードＤＢ４６に、「割引機能開放開始日」と、「割引機能開放終了日」のフィールドを設けてもよい。「割引機能開放開始日」のフィールドには、機能開放部２８が、図１０のステップＳ１３６において割引サービスの機能開放をユーザ端末７０に通知した年月日の情報が格納される。また、「割引機能開放終了日」のフィールドには、割引機能開放開始日から組織ドメインごとに予め定められている機能開放継続期間後の年月日の情報が格納される。なお、以下においては、「割引機能開放開始日」から「割引機能開放終了日」までの期間を、機能開放期間と呼ぶものとする。

本例では、機能開放部２８は、図７のステップＳ１１０の前に、図１６（ｂ）の処理を実行する。具体的には、機能開放部２８は、ユーザ端末７０から「限定メニュー」ボタンが押されたとき（図７のステップＳ１２：肯定の場合）に、ユーザ端末７０からアプリＮｏ．を取得する（Ｓ２０２）。そして、取得したアプリＮｏ．が、割引コードＤＢ４６に格納されており、かつ、アプリＮｏ．を取得したタイミングが、機能開放期間に含まれるかを確認する（Ｓ２０４、Ｓ２０６）。そして、ステップＳ２０４、Ｓ２０６の判断が肯定された場合には、ユーザにメールアドレスを要求することなく、機能開放をユーザ端末７０の社員用処理部５８に通知し（Ｓ２０８）、その後は、図１２のステップＳ１５０に移行する。なお、ステップＳ２０４、Ｓ２０６のいずれかの判断が否定された場合には、図７のステップＳ１１０に移行する。このとき、ユーザ端末７０では、図１６（ｃ）に示すような画面を表示部１９３に表示し、画面内の「メールアドレス入力へ」ボタンが押された場合に、図８（ｂ）の画面を表示するようにすればよい。

このようにすることで、ユーザは、「限定メニュー」ボタンを押すたびにメールアドレスや、割引コードを入力する必要がなくなるため、ユーザの利便性を向上することができる。

（変形例４）
なお、上記変形例３では、アプリＮｏ．が登録されていない場合、及び機能開放期間外になった場合には、ユーザに対してメールアドレスを入力又は再入力させる場合について説明したが、これに限られるものではない。例えば、図１７（ａ）に示すように、アプリＮｏ．が登録されていない場合（ステップＳ２０４：否定の場合）には、ユーザに対してメールアドレスを入力させ（図７のＳ１１０）、機能開放期間外になった場合（ステップＳ２０６：否定の場合）には、ステップＳ２１０に移行するようにしてもよい。

ステップＳ２１０では、機能開放部２８は、図１７（ｂ）に示すような期限切れ画面を一般用処理部５０に送信する。この場合、一般用処理部５０は、ユーザ端末７０の表示部１９３上に図１７（ｂ）の画面を表示する。図１７（ｂ）の画面には、「メールアドレス入力へ」のボタンと、「購入済チケットの追加」のボタンが設けられている。ユーザが「メールアドレス入力へ」のボタンを押すと、一般用処理部５０は、その旨をチケット販売処理部２０に通知する。この場合、サーバ１０は、図７のステップＳ１１０に移行する。

一方、ユーザが「購入済チケットの追加」のボタンを押した場合には、ユーザ端末７０の一般用処理部５０は、その旨を機能開放部２８に通知する。ここで、ユーザは、すでに購入したチケットの枚数を増やしたいときに、「購入済チケットの追加」のボタンを押す。機能開放部２８は、「購入済チケットの追加」のボタンが押された旨の通知を受信すると、ステップＳ２１２の判断（試合開始前の購入済チケットの追加か否かの判断）が肯定され、ステップＳ２１４に移行する。

ステップＳ２１４に移行すると、機能開放部２８は、社員用処理部５８に対して追加購入限定の機能開放を通知する。社員用処理部５８は、この通知を受け取ると、ユーザがすでに購入したチケットの追加購入の画面（図１７（ｃ）参照）を表示部１９３上に表示する。その後は、上記第１の実施形態と同様の処理（図１２の処理）が実行される。

本変形例４によれば、割引コードの期限が切れている場合であっても、ユーザが購入済のチケットを追加購入するのであれば、割引コードの照合処理を省略することとしている。これにより、チケットを前回購入したときに割引コードの照合をすでに行っており、再度の照合が不要な場合に、割引コードの照合処理を省略するため、ユーザの入力の手間を省くことができる。

《第２の実施形態》
次に、第２の実施形態について、図１８〜図２０に基づいて説明する。図１８（ａ）には、第２の実施形態に係るユーザ端末７０のハードウェア構成が示されている。本第２の実施形態においては、ユーザ端末７０が、図１８（ａ）に示すように、位置検出装置１８９を備えている。位置検出装置１８９は、例えばＧＰＳ（Global Positioning System）やビーコンなどである。

図１８（ｂ）には、本第２の実施形態のチケットＤＢ４０が示されている。本第２の実施形態においては、チケットＩＤに対応付けて、「開催場所」のフィールドに、試合会場の位置（緯度、経度）が格納されている。

図１９には、第２の実施形態における、ユーザ端末７０とサーバ１０の処理の一部がフローチャートにて示されている。図１９の処理は、第１の実施形態で説明したステップＳ６２の判断が肯定された後（図１１（ａ）や図１１（ｂ）の画面において「マイチケット」ボタンが押された後）に、実行される処理である。

図１９の処理では、まず、ステップＳ６３Ａにおいて、一般用処理部５０又は社員用処理部５８が、位置検出装置１８９において検出されるユーザ端末７０の現在位置をサーバ１０のチケット販売処理部２０に送信する。

これに対し、サーバ１０では、チケット販売処理部２０が、ユーザ端末７０の現在の位置を受信するまで待機しているので（Ｓ１６０）、受信すると、ユーザ端末７０の現在の位置が、ユーザが購入したチケットそれぞれの利用可能エリア内かを確認する。この場合、チケット販売処理部２０は、購入済チケットＤＢ４２からユーザが購入したチケットのチケットＩＤを取得する。そして、チケット販売処理部２０は、チケットＤＢ４０（図１８（ｂ））を参照して、取得したチケットＩＤに対応する開催場所から所定範囲内にユーザ端末７０が存在しているかを確認する。そして、チケット販売処理部２０は、確認結果を一般用処理部５０又は社員用処理部５８に通知する。

一方、ユーザ端末７０の一般用処理部５０又は社員用処理部５８は、ステップＳ６３Ａを実行した後、サーバ１０から通知があるまで待機している（Ｓ６３Ｂ）。したがって、サーバ１０においてステップＳ１６２の処理が実行されると、一般用処理部５０又は社員用処理部５８は、ステップＳ６４に移行し、購入済チケット一覧画面を表示する。このとき、例えば、ユーザが購入しているチケットが１枚であり、そのチケットの利用可能エリアにユーザが入っていない場合には、購入済チケット一覧画面において、図２０（ａ）に示すように「使用不可」を表示する。一方、ユーザが購入しているチケットの利用可能エリアにユーザが入っている場合には、購入済チケット一覧画面において、図２０（ｂ）に示すような「使う」ボタンを表示する。

次いで、ステップＳ６６では、一般用処理部５０又は社員用処理部５８が、「使う」ボタンが押されるまで待機する。ユーザが図２０（ｂ）の画面において「使う」ボタンを押すと、ステップＳ６８に移行し、一般用処理部５０又は社員用処理部５８は、チケット画面を表示する。チケット画面は、例えば、図２０（ｃ）に示すように、二次元コード等が表示された画面であるものとする。ユーザは、このチケット画面を試合会場において提示することにより、試合会場に入場することができる。なお、ユーザがチケットを利用した場合には、図２０（ｄ）に示すように、チケットに「使用日時」が表示されるようにしてもよい。

以上により、図１９の全処理が終了する。なお、図１９の処理が行われている間にユーザがアプリの使用をやめる操作を行う場合もある。このような操作が行われた場合には、処理が適宜終了するようになっている。

その他の処理については、第１の実施形態と同様である。

これまでの説明から明らかなように、本第２の実施形態では、チケット販売処理部２０を含んで、ユーザ端末の位置情報を取得する位置情報取得部、及び取得した位置情報に基づいてチケットの利用を可能にする処理部、としての機能が実現されている。

以上、詳細に説明したように、本第２の実施形態によると、チケット販売処理部２０は、ユーザ端末７０の現在位置を取得する（Ｓ１６０：肯定）。また、チケット販売処理部２０は、購入済チケットＤＢ４２やチケットＤＢ４０を参照して、ユーザ端末７０の現在位置が、購入済みのチケットの試合の開催場所の近傍であるかを判断し、ユーザ端末７０に判断結果を通知する（Ｓ１６２）。そして、ユーザ端末７０は、試合の開催場所の近傍にユーザ端末７０が存在する場合には、そのチケットを利用可能に表示し（図２０（ｂ））、試合の開催場所の近傍にユーザ端末７０が存在していない場合には、チケットを利用できない状態で表示する（図２０（ａ））。これにより、チケットを適切なタイミングで利用可能に表示することができる。

（変形例）
なお、上記第２の実施形態においては、図２０（ｂ）の画面において「使う」ボタンが押された場合に、ユーザに対して再度割引コードを入力させてもよい。具体的には、図２１に示すように、「使う」ボタンが押された場合（ステップＳ６６：肯定の場合）に、ユーザ端末７０の一般用処理部５０は、「使う」ボタンが押されたチケットが社員割引のチケットか否かを判断する（ステップＳ６７Ａ）。このステップＳ６７Ａの判断が否定された場合には、一般用処理部５０は、ステップＳ６７Ｂにおいて、チケット画面（図２０（ｃ）のような画面）を表示し、図２１の全処理を終了する。一方、ステップＳ６７の判断が肯定された場合には、ステップＳ６７Ｃに移行し、割引コード送信部５６が、割引コード入力画面（図８（ｃ）参照）を表示する。そして、割引コード送信部５６は、割引コードが入力されるまで待機し（ステップＳ６７Ｄ）、割引コードが入力されると、サーバ１０の割引コード照合部２６に割引コードを送信する（ステップＳ６７Ｅ）。

これに対し、サーバ１０においては、割引コード照合部２６が、割引コードを受信するまで待機しているので（ステップＳ１６４）、ユーザ端末７０においてステップＳ６７Ｅが実行されると、ステップＳ１６６に移行する。そして、ステップＳ１６６では、割引コード照合部２６が、受信した割引コードを照合して、照合結果を機能開放部２８が社員用処理部５８に通知する。

一方、ユーザ端末７０側では、ステップＳ６７Ｅの後、社員用処理部５８は、照合結果を受信するまで待機しているので（ステップＳ６７Ｆ）、サーバ１０においてステップＳ１６６の処理が実行されると、ステップＳ６７Ｇに移行する。

ステップＳ６７Ｇに移行すると、社員用処理部５８は、受信した照合結果に応じて、エラー画面（図９（ｃ）のような画面）又はチケット画面（図２０（ｃ）のような画面）を表示する。その後は、図２１の全処理を終了する。

このように、図２０（ｂ）の画面において「使う」ボタンが押された場合に、ユーザに対して再度割引コードを入力させることで、チケットを利用する際にも、ユーザの正当性を確認することができる。

なお、本変形例においては、ステップＳ６７Ｃの前に、ユーザに対してメールアドレスを入力させ、メールアドレスのドメインが登録済みの組織ドメインと一致している場合に、割引コードを再度発行するようにしてもよい。

また、本変形例においては、ユーザ端末７０の現在位置が、チケットの利用可能エリアに入った段階で、メール送信部２４から新たに割引コードを送信してもよい。

なお、上記各実施形態及び変形例では、チケットの払い戻しの際に、社員であるか否かを判別するために、メールアドレスのドメインの照合や、配布した割引コードの照合を行うこととしてもよい。

なお、上記各実施形態及び変形例では、ユーザが入力したメールアドレスが登録済みの組織ドメインと一致する場合に、入力されたメールアドレスに対応するユーザに対してチケットの割引サービスの機能を開放する場合について説明したが、これに限られるものではない。すなわち、入力されたメールアドレスに対応するユーザに対して割引サービス以外のチケット購入における特定のサービスの機能を開放することとしてもよい。

なお、上記各実施形態及び変形例では、スポーツの観戦チケットを例に説明したが、これに限らず、スポーツ以外のチケットの販売において、上記各実施形態及び変形例で説明した情報処理システム１００を用いることとしてもよい。

なお、上記各実施形態及び変形例では、チケット購入機能を有するアプリにおいて上記処理が行われる場合について説明したが、これに限らず、ブラウザ上で実行されるチケット購入機能を有するウェブサイトにおいて上記処理が行われることとしてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の第１、第２の実施形態及び変形例の説明に関して、更に以下の付記を開示する。
（付記１） 端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得し、
チケット購入における特定のサービスを受けることが可能な権利を有する組織を示す組織メールアドレスの組織ドメインを記憶するドメイン記憶部を参照して、取得した前記メールアドレスのドメインが前記ドメイン記憶部に記憶されている組織ドメインのいずれかと一致するかを判定し、
前記判定の結果、一致する場合に前記特定のサービスのための機能を、前記メールアドレスに対応するユーザに対して開放する処理を実行する、
処理をコンピュータが実行することを特徴とするチケット販売方法。
（付記２） 前記機能を開放する処理は、
取得した前記メールアドレスに対して、前記特定のサービスを受けるために必要な鍵情報を送信する処理と、
前記端末から、送信した前記鍵情報を取得した場合に、前記端末における前記特定のサービスのための機能を開放する処理と、を含む、ことを特徴とする付記１に記載のチケット販売方法。
（付記３） 前記鍵情報には、有効期限が設定されており、
前記端末から取得した鍵情報が前記有効期限内である場合に、前記端末における前記特定のサービスのための機能を開放する、ことを特徴とする付記２に記載のチケット販売方法。
（付記４） 前記特定のサービスは、前記組織ドメインごとに設定可能である、ことを特徴とする付記１〜３のいずれかに記載のチケット販売方法。
（付記５） 前記取得する処理では、前記組織内における前記ユーザの所属に関する情報を更に取得し、
前記特定のサービスは、前記組織ドメイン及び前記所属ごとに設定可能である、ことを特徴とする付記１〜４のいずれかに記載のチケット販売方法。
（付記６） 前記機能を開放する処理が実行された後、予め定めた所定期間は、前記機能を開放し続けることを特徴とする付記１〜５のいずれかに記載のチケット販売方法。
（付記７） 前記所定期間を過ぎた場合でも、購入済みのチケットの追加購入に対する特定のサービスの機能を継続して開放する、ことを特徴とする付記６に記載のチケット販売方法。
（付記８） ユーザが利用する端末の位置情報を取得し、
前記チケットの利用位置の情報を記憶する利用位置記憶部を参照して、取得した位置情報が、前記端末において購入されたチケットの利用位置の近傍である場合に、前記チケットの利用を可能にする、処理を前記コンピュータが更に実行する付記１〜７のいずれかに記載のチケット販売方法。
（付記９） 端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得し、
チケット購入における特定のサービスを受けることが可能な権利を有する組織を示す組織メールアドレスの組織ドメインを記憶するドメイン記憶部を参照して、取得した前記メールアドレスのドメインが前記ドメイン記憶部に記憶されている組織ドメインのいずれかと一致するかを判定し、
前記判定の結果、一致する場合に前記特定のサービスのための機能を、前記メールアドレスに対応するユーザに対して開放する処理を実行する、
処理をコンピュータに実行させるためのチケット販売プログラム。
（付記１０） 端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得する取得部と、
チケット購入における特定のサービスを受けることが可能な権利を有する組織を示す組織メールアドレスの組織ドメインを記憶するドメイン記憶部を参照して、取得した前記メールアドレスのドメインが前記ドメイン記憶部に記憶されている組織ドメインのいずれかと一致するかを判定する判定部と、
一致する場合に前記特定のサービスのための機能を、前記メールアドレスに対応するユーザに対して開放する処理を実行する実行部と、
を備える情報処理装置。
（付記１１） 前記実行部は、
取得した前記メールアドレスに対して、前記特定のサービスを受けるために必要な鍵情報を送信し、
前記端末から、送信した前記鍵情報を取得した場合に、前記端末における前記特定のサービスのための機能を開放する、ことを特徴とする付記１０に記載の情報処理装置。
（付記１２） 前記鍵情報には、有効期限が設定されており、
前記端末から取得した鍵情報が前記有効期限内である場合に、前記端末における前記特定のサービスのための機能を開放する、ことを特徴とする付記１１に記載の情報処理装置。
（付記１３） 前記特定のサービスは、前記組織ドメインごとに設定可能である、ことを特徴とする付記１０〜１２のいずれかに記載の情報処理装置。
（付記１４） 前記取得部は、前記組織内における前記ユーザの所属に関する情報を更に取得し、
前記特定のサービスは、前記組織ドメイン及び前記所属ごとに設定可能であることを特徴とする付記１０〜１３のいずれかに記載の情報処理装置。
（付記１５） 前記実行部は、前記機能を開放する処理を実行した後、予め定めた所定期間は、前記機能を開放し続けることを特徴とする付記１０〜１４のいずれかに記載の情報処理装置。
（付記１６） 前記実行部は、前記所定期間を過ぎた場合でも、購入済みのチケットの追加購入に対する特定のサービスの機能を継続して開放する、ことを特徴とする付記１５に記載の情報処理装置。
（付記１７） ユーザが利用する端末の位置情報を取得する位置情報取得部と、
前記チケットの利用位置の情報を記憶する利用位置記憶部を参照して、取得した位置情報が、前記端末において購入されたチケットの利用位置の近傍である場合に、前記チケットの利用を可能にする処理部と、を備える付記１０〜１６のいずれかに記載の情報処理装置。

１０ サーバ（情報処理装置）
７０ ユーザ端末（端末）
２０ チケット販売処理部（位置情報取得部、処理部）
２２ アドレス照合部（取得部、判定部）
２４ メール送信部（実行部の一部）
２６ 割引コード照合部（実行部の一部）
２８ 機能開放部（実行部の一部）

Claims (10)

1. 端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得し、
   チケット購入における特定のサービスを受けることが可能な権利を有する組織を示す組織メールアドレスの組織ドメインを記憶するドメイン記憶部を参照して、取得した前記メールアドレスのドメインが前記ドメイン記憶部に記憶されている組織ドメインのいずれかと一致するかを判定し、
   前記判定の結果、一致する場合に前記特定のサービスのための機能を、前記メールアドレスに対応するユーザに対して開放する処理を実行する、
   処理をコンピュータが実行することを特徴とするチケット販売方法。
2. 前記機能を開放する処理は、
   取得した前記メールアドレスに対して、前記特定のサービスを受けるために必要な鍵情報を送信する処理と、
   前記端末から、送信した前記鍵情報を取得した場合に、前記端末における前記特定のサービスのための機能を開放する処理と、を含む、ことを特徴とする請求項１に記載のチケット販売方法。
3. 前記鍵情報には、有効期限が設定されており、
   前記端末から取得した鍵情報が前記有効期限内である場合に、前記端末における前記特定のサービスのための機能を開放する、ことを特徴とする請求項２に記載のチケット販売方法。
4. 前記特定のサービスは、前記組織ドメインごとに設定可能である、ことを特徴とする請求項１〜３のいずれか一項に記載のチケット販売方法。
5. 前記取得する処理では、前記組織内における前記ユーザの所属に関する情報を更に取得し、
   前記特定のサービスは、前記組織ドメイン及び前記所属ごとに設定可能である、ことを特徴とする請求項１〜４のいずれか一項に記載のチケット販売方法。
6. 前記機能を開放する処理が実行された後、予め定めた所定期間は、前記機能を開放し続けることを特徴とする請求項１〜５のいずれか一項に記載のチケット販売方法。
7. 前記所定期間を過ぎた場合でも、購入済みのチケットの追加購入に対する特定のサービスの機能を継続して開放する、ことを特徴とする請求項６に記載のチケット販売方法。
8. ユーザが利用する端末の位置情報を取得し、
   前記チケットの利用位置の情報を記憶する利用位置記憶部を参照して、取得した位置情報が、前記端末において購入されたチケットの利用位置の近傍である場合に、前記チケットの利用を可能にする、処理を前記コンピュータが更に実行する請求項１〜７のいずれか一項に記載のチケット販売方法。
9. 端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得し、
   チケット購入における特定のサービスを受けることが可能な権利を有する組織を示す組織メールアドレスの組織ドメインを記憶するドメイン記憶部を参照して、取得した前記メールアドレスのドメインが前記ドメイン記憶部に記憶されている組織ドメインのいずれかと一致するかを判定し、
   前記判定の結果、一致する場合に前記特定のサービスのための機能を、前記メールアドレスに対応するユーザに対して開放する処理を実行する、
   処理をコンピュータに実行させるためのチケット販売プログラム。
10. 端末から、チケットの購入希望の情報とともに、入力されたメールアドレスを取得する取得部と、
    チケット購入における特定のサービスを受けることが可能な権利を有する組織を示す組織メールアドレスの組織ドメインを記憶するドメイン記憶部を参照して、取得した前記メールアドレスのドメインが前記ドメイン記憶部に記憶されている組織ドメインのいずれかと一致するかを判定する判定部と、
    一致する場合に前記特定のサービスのための機能を、前記メールアドレスに対応するユーザに対して開放する処理を実行する実行部と、
    を備える情報処理装置。
    

Images