ホーム > 特許ランキング > ｐｌａｙｇｒｏｕｎｄ株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024099408
(43)【公開日】2024-07-25
(54)【発明の名称】プログラム、方法、およびシステム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20240718BHJP
G06Q 10/02 20120101ALI20240718BHJP
【ＦＩ】
G06Q50/10
G06Q10/02
【審査請求】未請求
【請求項の数】9
【出願形態】ＯＬ
(21)【出願番号】P 2023003332
(22)【出願日】2023-01-12
(71)【出願人】
【識別番号】517201127
【氏名又は名称】ｐｌａｙｇｒｏｕｎｄ株式会社
(74)【代理人】
【識別番号】110002815
【氏名又は名称】ＩＰＴｅｃｈ弁理士法人
(72)【発明者】
【氏名】伊藤 圭史
【テーマコード（参考）】
5L010
5L049
5L050
【Ｆターム（参考）】
5L010AA03
5L049AA03
5L049CC11
5L050CC11
(57)【要約】 （修正有）
【課題】イベント内での追加体験においてユーザの利便性を向上するプログラム、方法、およびシステムを提供する。
【解決手段】プロセッサを備えて電子チケットを管理するシステムの処理に用いられるプログラムであって、プログラムは、プロセッサに、ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップと、主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定するステップと、特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定するステップと、を実行させる。
【選択図】図１０
【解決手段】プロセッサを備えて電子チケットを管理するシステムの処理に用いられるプログラムであって、プログラムは、プロセッサに、ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップと、主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定するステップと、特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定するステップと、を実行させる。
【選択図】図１０
【特許請求の範囲】
【請求項1】
プロセッサを備え、チケットを管理するシステムの処理に用いられるプログラムであって、
前記プログラムは、前記プロセッサに、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップと、
前記主体情報に紐づけられた前記ユーザが保有するチケットの権限を特定可能な権限情報を特定するステップと、
特定した前記権限情報が、前記所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、前記ユーザからの所定の要求についての承認の可否を判定するステップと、を実行させるプログラム。
前記プログラムは、前記プロセッサに、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップと、
前記主体情報に紐づけられた前記ユーザが保有するチケットの権限を特定可能な権限情報を特定するステップと、
特定した前記権限情報が、前記所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、前記ユーザからの所定の要求についての承認の可否を判定するステップと、を実行させるプログラム。
【請求項2】
前記主体情報を取得するステップでは、
前記ユーザを識別可能な生体情報を取得するステップと、
取得した前記生体情報を用いて、ユーザデータベースを参照して、当該生体情報に対応するユーザのユーザＩＤを特定するステップと、を実行させる請求項１に記載のプログラム。
前記ユーザを識別可能な生体情報を取得するステップと、
取得した前記生体情報を用いて、ユーザデータベースを参照して、当該生体情報に対応するユーザのユーザＩＤを特定するステップと、を実行させる請求項１に記載のプログラム。
【請求項3】
前記主体情報は、前記ユーザのユーザＩＤおよびイベントを識別するイベントＩＤにより作成された当該イベントにおいて共通する当該ユーザ固有のイベント別ユーザＩＤを含み、
前記主体情報を取得するステップでは、前記イベント別ユーザＩＤが記録された二次元コードを撮影することで、前記イベント別ユーザＩＤを取得する、請求項１に記載のプログラム。
前記主体情報を取得するステップでは、前記イベント別ユーザＩＤが記録された二次元コードを撮影することで、前記イベント別ユーザＩＤを取得する、請求項１に記載のプログラム。
【請求項4】
前記権限情報は、チケットを識別するチケットＩＤであり、
前記権限情報を特定するステップでは、取得した前記主体情報と紐づけられた前記チケットのチケットＩＤを特定する、請求項１に記載のプログラム。
前記権限情報を特定するステップでは、取得した前記主体情報と紐づけられた前記チケットのチケットＩＤを特定する、請求項１に記載のプログラム。
【請求項5】
前記権限情報は、チケットの権限について識別可能に設定された権限ＩＤであり、
前記権限情報を特定するステップでは、取得した前記主体情報と紐づけられた前記チケットのチケットＩＤを特定するステップと、
特定した前記チケットＩＤと紐づけられた前記権限ＩＤを特定するステップと、を実行させる、請求項１に記載のプログラム。
前記権限情報を特定するステップでは、取得した前記主体情報と紐づけられた前記チケットのチケットＩＤを特定するステップと、
特定した前記チケットＩＤと紐づけられた前記権限ＩＤを特定するステップと、を実行させる、請求項１に記載のプログラム。
【請求項6】
前記承認の可否を判定するステップでは、
前記チケットの利用条件を参照して、要求の可否を判定する、請求項１に記載のプログラム。
前記チケットの利用条件を参照して、要求の可否を判定する、請求項１に記載のプログラム。
【請求項7】
前記権限情報を特定するステップに先立って、
前記ユーザを識別可能な生体情報を取得したうえで、予め登録されているユーザ情報を参照して、ユーザの本人確認を行うステップを実行させる、請求項１に記載のプログラム。
前記ユーザを識別可能な生体情報を取得したうえで、予め登録されているユーザ情報を参照して、ユーザの本人確認を行うステップを実行させる、請求項１に記載のプログラム。
【請求項8】
プロセッサを備え、チケットを管理するシステムの処理に用いられる方法であって、
前記方法は、前記プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップと、
前記主体情報に紐づけられた前記ユーザが保有するチケットの権限を特定可能な権限情報を特定するステップと、
特定した前記権限情報が、前記所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、前記ユーザからの所定の要求についての承認の可否を判定するステップと、を実行する方法。
前記方法は、前記プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップと、
前記主体情報に紐づけられた前記ユーザが保有するチケットの権限を特定可能な権限情報を特定するステップと、
特定した前記権限情報が、前記所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、前記ユーザからの所定の要求についての承認の可否を判定するステップと、を実行する方法。
【請求項9】
プロセッサを備え、チケットを管理するシステムであって、
前記システムは、前記プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得する手段と、
前記主体情報に紐づけられた前記ユーザが保有するチケットの権限を特定可能な権限情報を特定する手段と、
特定した前記権限情報が、前記所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、前記ユーザからの所定の要求についての承認の可否を判定する手段と、を備えるシステム。
前記システムは、前記プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得する手段と、
前記主体情報に紐づけられた前記ユーザが保有するチケットの権限を特定可能な権限情報を特定する手段と、
特定した前記権限情報が、前記所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、前記ユーザからの所定の要求についての承認の可否を判定する手段と、を備えるシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、プログラム、方法、およびシステムに関する。
【背景技術】
【0002】
従来から、各種のチケットを発券して管理するシステムが知られている。
特許文献１には、イベントのチケットが電子チケットとして発券され、チケット情報を含む二次元コードがユーザ端末に表示されるシステムが開示されている。
このようなシステムでは、会場への入場に用いられる入場チケットの他に、例えば、イベント会場内のクロークの利用、サブイベントへの参加、ファストパス、特別施設の利用、又は特別エリアへの入場など、会場内で提供される付帯的なサービス（追加体験）ごとに、個別のチケットが発券されることがあった。
特許文献１には、イベントのチケットが電子チケットとして発券され、チケット情報を含む二次元コードがユーザ端末に表示されるシステムが開示されている。
このようなシステムでは、会場への入場に用いられる入場チケットの他に、例えば、イベント会場内のクロークの利用、サブイベントへの参加、ファストパス、特別施設の利用、又は特別エリアへの入場など、会場内で提供される付帯的なサービス（追加体験）ごとに、個別のチケットが発券されることがあった。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１４－０３８４７５号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら従来のシステムでは、例えば、テーマパークの会場内において、追加でアトラクションの優先利用に関するチケットを購入すると、その都度、当該チケットに対応する電子チケットを発券し、ユーザが受領しなければならなかった。
この場合には、スタッフからの検札の要求に応じて、ユーザが保有する複数の電子チケットのうち、提示が要求された電子チケットを端末に表示させる必要があり、ユーザの利便性の点で改善の余地があった。
この場合には、スタッフからの検札の要求に応じて、ユーザが保有する複数の電子チケットのうち、提示が要求された電子チケットを端末に表示させる必要があり、ユーザの利便性の点で改善の余地があった。
【0005】
本開示の目的は、イベント内での追加体験においてユーザの利便性を向上することができるシステムを提供することにある。
【課題を解決するための手段】
【0006】
本開示の一態様に係るプログラムは、プロセッサを備え、電子チケットを管理するシステムの処理に用いられるプログラムであって、プログラムは、プロセッサに、ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップと、主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定するステップと、特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定するステップと、を実行させる。
【発明の効果】
【0007】
本開示によれば、イベント内での追加体験においてユーザの利便性を向上することができる。
【図面の簡単な説明】
【0008】
【図1】本実施形態に係るチケット管理システムの全体構成を示す図である。
【図5】本実施形態に係るユーザデータベースのデータ構造の一例を示す図である。
【図6】本実施形態に係るイベントデータベースのデータ構造の一例を示す図である。
【図7】本実施形態に係るチケットデータベースのデータ構造の一例を示す図である。
【図8】本実施形態に係る権限データベースのデータ構造の一例を示す図である。
【図9】本実施形態に係る保有データベースのデータ構造の一例を示す図である。
【図10】本実施形態における処理全体の流れを説明する図である。
【図11】本実施形態の承認対象情報を説明する図である。
【図12】本実施形態に係るシステム１のユーザ登録処理を示すフローである。
【図13】本実施形態に係るシステム１のチケット販売処理を示すフローである。
【図14】本実施形態に係るシステム１の検札処理を示すフローである。
【図15】変形例１における処理全体の流れを説明する図である。
【図16】変形例２における処理全体の流れを説明する図である。
【図17】変形例３における処理全体の流れを説明する図である。
【図18】変形例４における処理全体の流れを説明する図である。
【図19】変形例５における処理全体の流れを説明する図である。
【図20】変形例６における検札装置３０が保有する承認対象情報を説明する図である。
【発明を実施するための形態】
【0009】
以下、本発明の一実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。
【0010】
（１）チケット管理システム１の全体構成
本実施形態に係るチケット管理システム１（以下、単にシステム１という）の全体構成について説明する。システム１は、チケットの使用を管理するシステムである。
システム１が管理するチケットは、電子媒体であるか紙媒体であるかを問わず、例えば以下のチケットが含まれる。
・各種のイベントに参加するための入場チケット
・商品又は役務の引換券（使用回数が設定された回数券を含む）
・デジタルコンテンツの提供（ダウンロードおよびストリーミング配信を含む）を受けるためのチケット
・特定のＷｅｂサイトへのアクセスに要求されるチケット
・店舗等において各種のサービスの提供を受けるためのチケット（各種クーポン等を含む）
・鉄道や航空機等の交通機関を利用するためのチケット
・テーマパークや美術館などの各種施設を利用するためチケット
・各種施設やイベント会場内の特定エリアに入場するためのチケット
・企画に参加するためのチケット（ファン投票権等）
・オンラインイベントを視聴するためのチケット
また、チケットとしてはこれらに限られず、商品又は役務の提供を受ける権限を有するその他の様々な証票が含まれ得る。
本実施形態に係るチケット管理システム１（以下、単にシステム１という）の全体構成について説明する。システム１は、チケットの使用を管理するシステムである。
システム１が管理するチケットは、電子媒体であるか紙媒体であるかを問わず、例えば以下のチケットが含まれる。
・各種のイベントに参加するための入場チケット
・商品又は役務の引換券（使用回数が設定された回数券を含む）
・デジタルコンテンツの提供（ダウンロードおよびストリーミング配信を含む）を受けるためのチケット
・特定のＷｅｂサイトへのアクセスに要求されるチケット
・店舗等において各種のサービスの提供を受けるためのチケット（各種クーポン等を含む）
・鉄道や航空機等の交通機関を利用するためのチケット
・テーマパークや美術館などの各種施設を利用するためチケット
・各種施設やイベント会場内の特定エリアに入場するためのチケット
・企画に参加するためのチケット（ファン投票権等）
・オンラインイベントを視聴するためのチケット
また、チケットとしてはこれらに限られず、商品又は役務の提供を受ける権限を有するその他の様々な証票が含まれ得る。
【0011】
ここで、システム１が適用されるイベントの内容は、例えば以下が含まれる。
・コンサート、ライブなどの音楽イベント
・球技、水泳、格闘技などのスポーツイベント（プロリーグ、アマチュア競技会を含む）
・現実のイベント会場で行われるゲーム大会
・舞台演劇、漫才、落語、その他の芸能を含む演芸イベント
・見本市、物産展、フリーマーケットなどの展示会
・万博、地方博覧会などの博覧会
・美術展、博物展などの展覧会
・公営賭博
・地域での祭り、記念行事のような自治体主催のイベント
・学園祭、サークルや団体の発表会
・アミューズメントパーク、及び、施設内で行われる各種のイベント
・デパート又は公共エリアにおいて期間限定で開催される催事
なお、イベントの内容としては、上記に限定されない。またイベントは、定期的に継続して行われてもよいし、不定期で行われてもよいし、常に開催されていてもよい。
・コンサート、ライブなどの音楽イベント
・球技、水泳、格闘技などのスポーツイベント（プロリーグ、アマチュア競技会を含む）
・現実のイベント会場で行われるゲーム大会
・舞台演劇、漫才、落語、その他の芸能を含む演芸イベント
・見本市、物産展、フリーマーケットなどの展示会
・万博、地方博覧会などの博覧会
・美術展、博物展などの展覧会
・公営賭博
・地域での祭り、記念行事のような自治体主催のイベント
・学園祭、サークルや団体の発表会
・アミューズメントパーク、及び、施設内で行われる各種のイベント
・デパート又は公共エリアにおいて期間限定で開催される催事
なお、イベントの内容としては、上記に限定されない。またイベントは、定期的に継続して行われてもよいし、不定期で行われてもよいし、常に開催されていてもよい。
【0012】
図１は、本実施形態に係るシステム１の全体構成を示すブロック図である。
図１に示すように、システム１は、ユーザ端末１０と、チケット管理サーバ２０と、検札装置３０と、を備える。
ユーザ端末１０、チケット管理サーバ２０、および検札装置３０は、ネットワーク（例えば、インターネットまたはイントラネット）ＮＷを介して接続されている。
図１に示すように、システム１は、ユーザ端末１０と、チケット管理サーバ２０と、検札装置３０と、を備える。
ユーザ端末１０、チケット管理サーバ２０、および検札装置３０は、ネットワーク（例えば、インターネットまたはイントラネット）ＮＷを介して接続されている。
【0013】
ユーザ端末１０は、情報処理装置である。ユーザ端末１０は、チケット管理サーバ２０に対して各種のイベントに関するチケット情報を要求するように構成される。ユーザ端末１０は、チケット購入端末と言い換えることもできる。
【0014】
以降の説明において、情報処理装置は、例えば、スマートフォン、タブレット端末、パーソナルコンピュータ、サーバコンピュータ（例えば、Ｗｅｂサーバ、アプリケーションサーバ、データベースサーバ、またはそれらの組み合わせ）、ウェアラブルデバイス（例えば、スマートウォッチ、またはスマートグラス）、などの種々のコンピュータを含み得る。本実施形態では、ユーザ端末１０は、ネットワークＮＷに接続可能なモバイルコンピュータであるスマートフォンを例に挙げて説明する。
【0015】
ここで、チケット情報とは、各種興行等への参加の証票となるチケットに関する情報である。具体的には、チケット情報は、チケットを識別する情報、チケットが証明する権限に関する情報（例えば、チケットの対象となる興行に関する情報）、チケットの購入者の氏名、特徴量（例えば、顔の特徴量）に関する情報、チケットの購入者に関する情報（例えばユーザＩＤ）、もしくはそれらの組み合わせ、またはそれらを符号化したコード情報（例えば、ＱＲコード（登録商標）、または他の１次元もしくは２次元コード）を含み得る。
【0016】
チケットは、ユーザが保持するユーザ端末１０に表示されたチケット情報の画像（つまり電子チケット）であってもよい。或いは、チケットは、チケット情報が印刷された紙またはその他の媒体であってもよい。
【0017】
チケット管理サーバ２０は、情報処理装置である。チケット管理サーバ２０は、ユーザ端末１０からの要求に応じて、発券（つまりチケット情報の販売）を行うように構成される。また、チケット管理サーバ２０は、発行したチケット情報を管理するように構成される。
【0018】
検札装置３０は、例えば、各種のイベント会場の検札所に配置される情報処理装置である。検札所は、イベント会場とその外部空間との境界に相当する。検札装置３０は、イベント会場に対して入場しようとする人物（以降、「来場者」とする）によって提示された主体情報を参照し、来場者の入場の可否を判定するように構成される。
【0019】
ここでユーザの主体情報とは、ユーザを識別可能な情報であって、例えば、以下のいずれにより構成される。
・ユーザＩＤ：ユーザごとに固有値となる識別情報
・イベント別ユーザＩＤ：イベントごとに固有値となるユーザの識別情報。ユーザＩＤとイベントＩＤにより定義される。特定のユーザが特定のイベントの複数の検札シーンにおいて共通して利用可能な識別情報
・ユーザの生体情報：顔画像の特徴量などのユーザを識別可能な情報
・アカウント情報：ユーザによって入力されたユーザＩＤおよびログインパスワード
・ユーザＩＤ：ユーザごとに固有値となる識別情報
・イベント別ユーザＩＤ：イベントごとに固有値となるユーザの識別情報。ユーザＩＤとイベントＩＤにより定義される。特定のユーザが特定のイベントの複数の検札シーンにおいて共通して利用可能な識別情報
・ユーザの生体情報：顔画像の特徴量などのユーザを識別可能な情報
・アカウント情報：ユーザによって入力されたユーザＩＤおよびログインパスワード
【0020】
また、検札装置３０が使用される場所としては、興行会場（例えば、コンサート会場、観劇会場、試合会場、展覧会場、店舗またはそれらの組み合わせ）、公共交通機関、オフィス、店舗、販売ブース、テーマパーク、その他の施設であり得る。
すなわち、検札装置３０は、使用されるそれぞれの場面において、ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得することで、当該要求の承認の可否を判定する。
すなわち、検札装置３０は、使用されるそれぞれの場面において、ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得することで、当該要求の承認の可否を判定する。
【0021】
また検札装置３０は、例えば、興行がサーバ空間において公開されるオンラインイベントである場合には、当該イベントへのアクセスを管理する情報処理装置である。検札装置３０は、オンラインイベントにアクセスをして当該イベントに相当するコンテンツを視聴する人物（以降、「視聴者」とする）によって入力された主体情報を参照し、視聴者の視聴の可否を判定するように構成される。この場合には、ユーザがオンラインイベントを視聴する視聴端末（ユーザ端末１０を含む）が、検札装置３０としての機能を発揮する。また、ユーザがオンラインイベントを視聴するために、視聴端末にアカウント情報を入力することで、検札装置３０による主体情報の取得が行われる。
【0022】
（１－１）ユーザ端末１０の構成
ユーザ端末１０の構成について説明する。図２は、本実施形態のチケット購入端末の構成を示すブロック図である。
ユーザ端末１０の構成について説明する。図２は、本実施形態のチケット購入端末の構成を示すブロック図である。
【0023】
図２に示すように、ユーザ端末１０は、記憶装置１１と、プロセッサ１２と、入出力インタフェース１３と、通信インタフェース１４と、を備える。ユーザ端末１０は、入力デバイス１５および出力デバイス１６の少なくとも１つと接続可能である。
【0024】
記憶装置１１は、プログラムおよびデータを記憶するように構成される。記憶装置１１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。
【0025】
プログラムは、例えば、以下のプログラムを含む。
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、ウェブブラウザ）のプログラム
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、ウェブブラウザ）のプログラム
【0026】
データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）
【0027】
プロセッサ１２は、記憶装置１１に記憶されたプログラムを起動することによって、ユーザ端末１０の機能を実現するように構成される。プロセッサ１２は、コンピュータの一例である。
【0028】
入出力インタフェース１３は、入力デバイス１５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス１６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。
【0029】
入力デバイス１５は、例えば、キーボード、ポインティングデバイス、タッチパネル、物理ボタン、センサ（例えば、カメラ、バイタルセンサ、またはそれらの組み合わせ）、または、それらの組合せである。
【0030】
出力デバイス１６は、例えば、ディスプレイ、スピーカ、印刷装置、またはそれらの組み合わせである。
【0031】
通信インタフェース１４は、ユーザ端末１０と外部装置（例えば、チケット管理サーバ２０、検札装置３０、および権利端末４０の少なくとも１つ）との間の通信を制御するように構成される。
【0032】
（１－２）チケット管理サーバ２０の構成
チケット管理サーバ２０の構成について説明する。図３は、本実施形態のチケット管理サーバ２０の構成を示すブロック図である。
チケット管理サーバ２０の構成について説明する。図３は、本実施形態のチケット管理サーバ２０の構成を示すブロック図である。
【0033】
図３に示すように、チケット管理サーバ２０は、記憶装置２１と、プロセッサ２２と、入出力インタフェース２３と、通信インタフェース２４とを備える。チケット管理サーバ２０は、入力デバイス２５および出力デバイス２６の少なくとも１つと接続可能である。
【0034】
記憶装置２１は、プログラムおよびデータを記憶するように構成される。記憶装置２１は、例えば、ＲＯＭ、ＲＡＭ、および、ストレージ（例えば、フラッシュメモリまたはハードディスク）の組合せである。
【0035】
プログラムは、例えば、以下のプログラムを含む。
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム
【0036】
データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理の実行結果
・情報処理において参照されるデータベース
・情報処理の実行結果
【0037】
プロセッサ２２は、記憶装置２１に記憶されたプログラムを起動することによって、チケット管理サーバ２０の機能を実現するように構成される。プロセッサ２２は、コンピュータの一例である。
【0038】
入出力インタフェース２３は、入力デバイス２５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス２６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。
【0039】
入力デバイス２５は、例えば、キーボード、ポインティングデバイス、タッチパネル、センサ、または、それらの組合せである。
【0040】
出力デバイス２６は、例えば、ディスプレイ、スピーカ、またはそれらの組み合わせである。
【0041】
通信インタフェース２４は、チケット管理サーバ２０と外部装置（例えば、ユーザ端末１０、および検札装置３０の少なくとも１つ）との間の通信を制御するように構成される。
【0042】
（１－３）検札装置３０の構成
検札装置３０の構成について説明する。図４は、本実施形態の検札装置３０の構成を示すブロック図である。
検札装置３０の構成について説明する。図４は、本実施形態の検札装置３０の構成を示すブロック図である。
【0043】
図４に示すように、検札装置３０は、記憶装置３１と、プロセッサ３２と、入出力インタフェース３３と、通信インタフェース３４とを備える。検札装置３０は、入力デバイス３５および出力デバイス３６の少なくとも１つと接続可能である。
【0044】
記憶装置３１は、プログラムおよびデータを記憶するように構成される。記憶装置３１は、例えば、ＲＯＭ、ＲＡＭ、および、ストレージの組合せである。
【0045】
プログラムは、例えば、以下のプログラムを含む。
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム
【0046】
データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ
【0047】
プロセッサ３２は、記憶装置３１に記憶されたプログラムを起動することによって、検札装置３０の機能を実現するように構成される。プロセッサ３２は、コンピュータの一例である。
【0048】
入出力インタフェース３３は、入力デバイス３５から信号（例えば、ユーザの指示、センシング信号、またはそれらの組み合わせ）を取得し、かつ、出力デバイス３６に信号（例えば、画像信号、音声信号、またはそれらの組み合わせ）を出力するように構成される。
【0049】
入力デバイス３５は、例えば、キーボード、ポインティングデバイス、タッチパネル、センサ（例えば、カメラ、バイタルセンサ、またはそれらの組み合わせ）、または、それらの組合せである。図４に示すように、入力デバイス３５としては、例えば可視光カメラ３５２が含まれる。
【0050】
入力デバイス４５は、単独で、またはプロセッサ４２との協働により、ユーザの生体情報の取得手段を実現する。
生体情報の取得手段は、ユーザからの特典付与の要求時に、来場者によるチケットの提示時に、来場者の入場可否の判定に必要な情報（以下、「認証情報」とする）を読み取る。認証情報は、例えば、以下の少なくとも１つを含む。
・来場者の生体情報（例えば、顔の特徴量/声紋/掌紋などの生体情報）に関する情報
生体情報の取得手段は、ユーザからの特典付与の要求時に、来場者によるチケットの提示時に、来場者の入場可否の判定に必要な情報（以下、「認証情報」とする）を読み取る。認証情報は、例えば、以下の少なくとも１つを含む。
・来場者の生体情報（例えば、顔の特徴量/声紋/掌紋などの生体情報）に関する情報
【0051】
生体情報の取得手段は、可視光カメラ３５２と、当該可視光カメラ３５２によって撮影された画像を解析してユーザの生体情報を抽出する。
例えば、生体情報の取得手段は、可視光カメラ３５２と、当該可視光カメラ３５２によって撮影された画像を解析して来場者の顔の画像を抽出する。そして、生体情報の取得手段は、当該来場者の顔の画像から特徴量を計算するアプリケーションとの組み合わせにより、来場者の顔の特徴量に関する情報を取得できる。
例えば、生体情報の取得手段は、可視光カメラ３５２と、当該可視光カメラ３５２によって撮影された画像を解析して来場者の顔の画像を抽出する。そして、生体情報の取得手段は、当該来場者の顔の画像から特徴量を計算するアプリケーションとの組み合わせにより、来場者の顔の特徴量に関する情報を取得できる。
【0052】
出力デバイス３６は、例えば、ディスプレイ、スピーカ、警報装置、電動式のゲート、またはそれらの組み合わせである。
【0053】
通信インタフェース３４は、検札装置３０と外部装置（例えば、ユーザ端末１０、およびチケット管理サーバ２０の少なくとも１つ）との間の通信を制御するように構成される。
【0054】
（２）データ構造
本実施形態で用いられるデータの構造について説明する。まず、チケット管理サーバ２０の記憶装置２１に記憶されるデータベースについて説明する。チケット管理サーバ２０は、以下のデータベースを記憶している。
・ユーザデータベース（以下、ユーザＤＢという）
・イベントデータベース（以下、イベントＤＢという）
・チケットデータベース（以下、チケットＤＢという）
・権限データベース（以下、権限ＤＢという）
・保有データベース（以下、保有ＤＢという）
本実施形態で用いられるデータの構造について説明する。まず、チケット管理サーバ２０の記憶装置２１に記憶されるデータベースについて説明する。チケット管理サーバ２０は、以下のデータベースを記憶している。
・ユーザデータベース（以下、ユーザＤＢという）
・イベントデータベース（以下、イベントＤＢという）
・チケットデータベース（以下、チケットＤＢという）
・権限データベース（以下、権限ＤＢという）
・保有データベース（以下、保有ＤＢという）
【0055】
【0056】
図５に示すように、ユーザＤＢは、「ユーザＩＤ」フィールドと、「ログインＰＡＳＳ」フィールドと、「ユーザ氏名」フィールドと、「性別」フィールドと、「年齢」フィールドと、「居住地」フィールドと、「連絡先」フィールドと、「生体情報」フィールドと、「ワクチン接種情報」フィールドと、「ＢＡＮ適用フラグ」フィールドと、を含む。
【0057】
「ユーザＩＤ」フィールドには、ユーザごとに固有値となる識別情報が格納される。ユーザＩＤは、チケット管理サーバ２０が提供するチケット管理プラットフォームにおいて、ユーザを識別する情報である。
【0058】
「ログインＰＡＳＳ」フィールドには、ユーザＩＤに対応するユーザが、チケット管理サーバ２０が提供するチケット管理プラットフォームにログインをする際に入力が要求されるログインパスワードに関する情報が格納される。
【0059】
「ユーザ氏名」フィールドには、ユーザＩＤに対応するユーザの氏名が格納される。
【0060】
「性別」フィールドには、ユーザＩＤに対応するユーザの性別が格納される。
【0061】
「年齢」フィールドには、ユーザＩＤに対応するユーザの年齢が格納される。
【0062】
「居住地」フィールドには、ユーザＩＤに対応するユーザの居住地の情報が格納される。
【0063】
「連絡先」フィールドには、ユーザＩＤに対応するユーザの連絡先を示す情報が格納される。連絡先情報としては、例えば、メールアドレス、電話番号、ＳＮＳ（Social Networking Service）もしくは他のメッセージング可能なアプリケーションのアカウント情報、またはそれらの組み合わせである。連絡先情報は、ここで挙げた例に限られず、ユーザ端末１０を介して来場者にリアルタイムに通知を送信するために利用可能な任意の種別の情報を含むことができる。
【0064】
「生体情報」フィールドには、ユーザＩＤに対応するユーザの生体情報に基づいて生成されたユーザの個体ごとに固有となる情報（例えば、顔画像の特徴量）が格納される。顔画像の特徴量は、ユーザの顔を撮影した画像から抽出される。
【0065】
「ワクチン接種情報」フィールドには、ユーザＩＤに対応するユーザ行政機関から接種が推奨されている所定のワクチンの接種履歴に関する情報が格納されている。
【0066】
「ＢＡＮ適用フラグ」フィールドには、ユーザＩＤに対応するユーザについて、過去の不正行為などにより、システム１が適用されるイベントへの参加が禁止されている場合に、その旨を示す情報が記録されている。
【0067】
なお、図５に示すユーザＤＢの構造はあくまで例示であり、その他の情報を格納してもよい。また、ユーザＤＢは、前述した各フィールドのうちのいずれかを含まなくてもよい。
ユーザＤＢに格納されるその他のユーザの属性を示す情報としては、例えば、以下が挙げられる。
・生年月日
・職業
・国籍
・家族構成
・使用言語
・ペットの有無
・趣味、嗜好に関する情報
・ファンクラブ会員に該当するかどうか
・過去のイベント参加の実績に関する情報
・その他のユーザごとの属性情報
ユーザＤＢに格納されるその他のユーザの属性を示す情報としては、例えば、以下が挙げられる。
・生年月日
・職業
・国籍
・家族構成
・使用言語
・ペットの有無
・趣味、嗜好に関する情報
・ファンクラブ会員に該当するかどうか
・過去のイベント参加の実績に関する情報
・その他のユーザごとの属性情報
【0068】
（２－２）イベントＤＢ
イベントＤＢの構成例について説明する。図６は、チケット管理サーバ２０が記憶するイベントＤＢのデータ構造の一例を示す図である。イベントＤＢには、チケットにより参加が許可されるイベントに関する情報が格納される。
イベントＤＢの構成例について説明する。図６は、チケット管理サーバ２０が記憶するイベントＤＢのデータ構造の一例を示す図である。イベントＤＢには、チケットにより参加が許可されるイベントに関する情報が格納される。
【0069】
図６に示すように、イベントＤＢは、「イベントＩＤ」フィールドと、「イベント名称」フィールドと、「イベント種別」フィールドと、「出演者」フィールドと、「会場」フィールドと、「主催者」フィールドと、「開催日時」フィールドと、を含む。
【0070】
「イベントＩＤ」フィールドには、イベントを識別するための識別情報が格納される。イベントＩＤは、各種のイベントごとに固有の値となる。
【0071】
「イベント名称」フィールドは、イベントＩＤに該当するイベントの名称が格納される。イベント名称は、イベントＩＤによって識別されるイベントの名称を示す情報である。
【0072】
「イベント種別」フィールドには、イベントＩＤに該当するイベントの種別に関する情報が格納される。イベント種別に関する情報は、イベントＩＤによって識別されるイベントの概要を示す情報である。例えば、イベント種別として、「プロ野球」「アニメ試写会」「オンラインライブ」等が挙げられる。
【0073】
「出演者」フィールドには、イベントＩＤに該当するイベントの出演者に関する情報が格納される。出演者情報は、イベントＩＤによって識別されるイベントへの出演者を示す情報である。出演者情報には、個人または団体（グループ名、チーム名、バンド名等）が含まれる。「出演者」フィールドには、ファン活動により応援される対象概念の情報が含まれ得る。
【0074】
「会場」フィールドには、イベントＩＤに該当するイベントの会場に関する情報が格納される。
【0075】
「主催者」フィールドには、イベントＩＤに該当するイベントの主催者に関する情報が格納される。イベント主催者に関する情報とは、例えば、当該イベントの興行主又は運営会社を示す情報である。イベント主催者に関する情報は、イベント主催者の名称の他、イベント主催者の所在地、および当該イベントに関する担当者の連絡先の情報を含んでもよい。
【0076】
「開催日時」フィールドには、イベントＩＤに該当するイベントの開催日時が格納される。
なお、図６に示すイベントＤＢの構造はあくまで例示であり、その他の情報を格納してもよい。例えば、イベントＤＢは、開場時刻、開演時刻、終演時刻、または閉場時刻などの当日の運営スケジュールに関する情報を格納してもよい。また、イベントＤＢは、例えば「イベント種別」フィールドなど、前述した各フィールドのうちのいずれかを含まなくてもよい。
なお、図６に示すイベントＤＢの構造はあくまで例示であり、その他の情報を格納してもよい。例えば、イベントＤＢは、開場時刻、開演時刻、終演時刻、または閉場時刻などの当日の運営スケジュールに関する情報を格納してもよい。また、イベントＤＢは、例えば「イベント種別」フィールドなど、前述した各フィールドのうちのいずれかを含まなくてもよい。
【0077】
（２－３）チケットＤＢ
チケットＤＢの構成例について説明する。
チケットＤＢの構成例について説明する。
【0078】
図７に示すチケットデータベースには、チケット情報が格納される。
図７に示すように、チケットＤＢは、「チケットＩＤ」フィールドと、「権限ＩＤ」フィールドと、「利用ステータス」と、「特典チケットＩＤ」フィールドと、「特典チケット付与条件」フィールドと、を含む。
図７に示すように、チケットＤＢは、「チケットＩＤ」フィールドと、「権限ＩＤ」フィールドと、「利用ステータス」と、「特典チケットＩＤ」フィールドと、「特典チケット付与条件」フィールドと、を含む。
【0079】
「チケットＩＤ」フィールドには、チケットＩＤが格納される。チケットＩＤは、チケットを識別するための情報である。
【0080】
「権限ＩＤ」フィールドには、チケットＩＤに対応するチケットについて設定されたチケットの権限に関する識別情報が格納される。チケットの権限に関する情報については後述する。なお、チケットＩＤに対応するチケットがイベント会場への入場チケットである場合には、権限ＩＤとして、当該イベントのイベントＩＤを用いてもよい。
【0081】
「利用ステータス」フィールドには、チケットＩＤに対応するチケットの使用状態を示す情報が格納される。チケットの状態としては、「未使用」、「使用済」が含まれる。入場チケットの場合には、後述するチケットのもぎり（検札処理）により、入場ステータスが、「使用済」に書き換えられる。なお、チケットが複数回の使用が可能な回数券である場合には、「利用ステータス」フィールドに代えて、当該チケットの利用可能な残回数を示す「利用可能残回数」や利用した回数を示す「利用回数」フィールドを設けてもよい。
【0082】
「特典チケットＩＤ」フィールドには、チケットＩＤに対応するチケットの使用により、特典としてユーザに対して付与される特典チケットの識別情報が格納される。特典チケットとは後述するＮＦＴ（非代替性トークン）であってもよい。なお、チケットＩＤに対応するチケットについて、特典が設定されていない場合は、「特典チケットＩＤ」フィールドは空欄であってもよい。
【0083】
「特典チケット付与条件」フィールドには、チケットＩＤに対応するチケットの使用により付与される特典チケットを付与可能な条件（付与条件）が格納されている。付与条件としては、例えば以下が挙げられる。
・時期的条件：付与可能な時期が設定されている
・位置的条件：付与可能なエリアが設定されている
・客体的条件：付与可能なユーザの属性が設定されている。（例えば、成人、学生、女性、または高齢者等）
・時期的条件：付与可能な時期が設定されている
・位置的条件：付与可能なエリアが設定されている
・客体的条件：付与可能なユーザの属性が設定されている。（例えば、成人、学生、女性、または高齢者等）
【0084】
なお、図７に示すチケットＤＢの構造はあくまで例示であり、その他の情報を格納してもよい。例えば、チケットＤＢには、以下の情報が格納されてもよい。
・当該チケットにより利用可能な座席番号
・当該チケットの利用期限
・当該チケットの利用可能回数
・当該チケットにより利用可能な座席番号
・当該チケットの利用期限
・当該チケットの利用可能回数
【0085】
（２－４）権限ＤＢ
図８は、権限ＤＢのデータ構造の一例を示す図である。権限ＤＢは、チケットを保有するユーザに対して承認される要求（チケットの権限）に関する情報を管理するデータベースである。チケットの権限とは、具体的には、当該チケットの所有者が、提供を受けることができる商品又はサービスの内容を指す。
図８は、権限ＤＢのデータ構造の一例を示す図である。権限ＤＢは、チケットを保有するユーザに対して承認される要求（チケットの権限）に関する情報を管理するデータベースである。チケットの権限とは、具体的には、当該チケットの所有者が、提供を受けることができる商品又はサービスの内容を指す。
【0086】
図８に示すように、権限ＤＢは、「権限ＩＤ」フィールドと、「利用イベントＩＤ」フィールドと、「利用条件」フィールドと、「チケット権限内容」フィールドと、を含む。
【0087】
「権限ＩＤ」フィールドには、チケットに設定された権限を、権限の内容ごとに識別可能な識別情報が格納される。権限ＩＤは、イベントＩＤの文字列の少なくとも一部を含む文字列により構成されてもよい。
【0088】
「利用イベントＩＤ」フィールドには、権限ＩＤに対応するチケットを使用可能なイベントの識別情報が格納される。
【0089】
「利用条件」フィールドには、権限ＩＤに対応するチケットを利用可能な条件が格納されている。利用条件としては、例えば以下が挙げられる。
・時期的条件：利用可能な期間が設定されている（例えば利用有効期間等）
・位置的条件：利用可能なエリアが設定されている（例えば所定の商業施設内、又は所定のイベント会場内において使用可能であること等）
・主体的条件：使用可能なユーザの属性が設定されている（例えば、子供、学生、女性、または高齢者等）
・時期的条件：利用可能な期間が設定されている（例えば利用有効期間等）
・位置的条件：利用可能なエリアが設定されている（例えば所定の商業施設内、又は所定のイベント会場内において使用可能であること等）
・主体的条件：使用可能なユーザの属性が設定されている（例えば、子供、学生、女性、または高齢者等）
【0090】
「チケット権限内容」フィールドには、チケットの権限の内容に関する情報として、権限ＩＤに対応するチケットを保有することで、ユーザが提供を受けることができる商品又はサービスに関する情報が格納されている。
チケットの権限の内容に関する情報としては、例えば、以下が含まれる。
・入場可能エリアの情報
・提供されるグッズの情報
・参加可能な特別イベントに関する情報
・割引サービスなどの優待に関する情報
・チケットの保有により利用可能な座席情報
チケットの権限の内容に関する情報としては、例えば、以下が含まれる。
・入場可能エリアの情報
・提供されるグッズの情報
・参加可能な特別イベントに関する情報
・割引サービスなどの優待に関する情報
・チケットの保有により利用可能な座席情報
【0091】
なお、図８に示す権限ＤＢの構造はあくまで例示であり、その他の情報を格納してもよい。例えば、権限ＤＢには、以下の情報が格納されてもよい。
・チケットの券種：権限ＩＤに対応するチケットの種別を示す情報が格納される。例えば、券種としては、一般チケット又は優待チケットなどがある。
・チケットの券種：権限ＩＤに対応するチケットの種別を示す情報が格納される。例えば、券種としては、一般チケット又は優待チケットなどがある。
【0092】
（２－５）保有ＤＢ
図９は、保有ＤＢのデータ構造の一例を示す図である。保有ＤＢは、ユーザが保有しているチケットの情報を管理するデータベースである。
図９は、保有ＤＢのデータ構造の一例を示す図である。保有ＤＢは、ユーザが保有しているチケットの情報を管理するデータベースである。
【0093】
図９に示すように、保有ＤＢは、「レコードＩＤ」フィールドと、「ユーザＩＤ」フィールドと、「チケットＩＤ」フィールドと、を含む。
【0094】
「レコードＩＤ」フィールドには、保有レコードを識別する識別情報が格納される。
【0095】
「ユーザＩＤ」フィールドには、レコードＩＤに対応する保有レコードにおいて、チケット保有の主体となるユーザの識別情報が格納される。
【0096】
「チケットＩＤ」フィールドには、レコードＩＤに対応する保有レコードにおいて、チケット保有の客体となるチケットの識別情報が格納される。
なお、図９に示す保有ＤＢの構造はあくまで例示であり、その他の情報を格納してもよい
なお、図９に示す保有ＤＢの構造はあくまで例示であり、その他の情報を格納してもよい
【0097】
（３）実施形態の概要
本実施形態の概要について説明する。
本実施形態の概要について説明する。
【0098】
（３－１）処理全体の流れ
図１０は、本実施形態の処理の全体の流れを示す図である。
図１０に示すように、例えばシステム１では、イベント会場への入場を要求するユーザに対して、イベント会場の入場ゲートでの検札処理を行う。この際、検札装置３０は、ユーザ端末１０に表示された二次元コードを撮影する。二次元コードには、来場者の主体情報となるユーザＩＤが記録されている。このため、検札装置３０はユーザＩＤを特定することができる。
図１０は、本実施形態の処理の全体の流れを示す図である。
図１０に示すように、例えばシステム１では、イベント会場への入場を要求するユーザに対して、イベント会場の入場ゲートでの検札処理を行う。この際、検札装置３０は、ユーザ端末１０に表示された二次元コードを撮影する。二次元コードには、来場者の主体情報となるユーザＩＤが記録されている。このため、検札装置３０はユーザＩＤを特定することができる。
【0099】
次に、システム１では、検札装置３０は、チケット管理サーバ２０に対して、特定したユーザＩＤを送信して、来場者であるユーザが保有するチケットを特定する。チケット管理サーバ２０は、保有ＤＢを参照して、検札装置３０から送信されたユーザＩＤと紐づけられたチケットのチケットＩＤを特定する。なお、予め検札装置３０に保有ＤＢの情報が記録されている場合には、チケット管理サーバ２０への照会は不要であり、検札装置３０は記録された保有ＤＢの情報を用いてユーザＩＤと紐付けられたチケットのチケットＩＤを特定する。
【0100】
次に、システム１では、チケット管理サーバ２０が、特定したチケットＩＤについて、権限ＤＢを参照して、ユーザが保有するチケットに設定された権限を特定する。これにより、システム１では、主体情報に紐づけられた権限情報が特定される。
ここで、権限情報とは、チケットの権限を特定可能な情報であり、本実施形態では、権限ＤＢにおける権限ＩＤが該当する。なお、権限情報は権限ＩＤに限定されない。権限情報のその他の例については、後述する各変形例において説明する。
ここで、権限情報とは、チケットの権限を特定可能な情報であり、本実施形態では、権限ＤＢにおける権限ＩＤが該当する。なお、権限情報は権限ＩＤに限定されない。権限情報のその他の例については、後述する各変形例において説明する。
【0101】
このように、システム１では、取得した前記主体情報と紐づけられたチケットのチケットＩＤを特定する処理と、特定したチケットＩＤと紐づけられた権限ＩＤを特定する処理と、により、権限情報である権限ＩＤが特定される。
【0102】
そして、検札装置３０には、それぞれが配備される検札場面において、承認するべきチケットの権限情報である承認対象情報（承認対象権限ＩＤ）が、承認対象情報として予め登録されている。
検札装置３０は、検札対象であるユーザが保有するチケットに設定された権限ＩＤと、予め登録された承認対象情報（承認対象権限ＩＤ）と、が一致するかどうかを判定することで、ユーザからの所定の要求についての承認の可否を判定する。
検札装置３０は、検札対象であるユーザが保有するチケットに設定された権限ＩＤと、予め登録された承認対象情報（承認対象権限ＩＤ）と、が一致するかどうかを判定することで、ユーザからの所定の要求についての承認の可否を判定する。
【0103】
そして、ユーザが保有するチケットの権限が、承認対象である権限ＩＤと一致する場合には、検札装置３０は、ユーザに対して、ユーザからの要求（入場）を許可する。図１０に示す来場チケットへの検札の場面では、検札装置３０は、ユーザに対してイベント会場への入場を承認する。
【0104】
一方、ユーザが保有するチケットの権限が、承認対象である権限ＩＤと一致しない場合、または、ユーザがチケットを保有していない場合には、検札装置３０は、ユーザに対して要求を拒絶する。図１０に示す来場チケットへの検札の場面では、検札装置３０は、ユーザに対してイベント会場への入場を拒絶する。
次に、検札装置３０が保有する検札時の承認対象情報に付いて説明する。
次に、検札装置３０が保有する検札時の承認対象情報に付いて説明する。
【0105】
（３－２）検札装置３０が保有する承認対象情報
図１１は、検札装置３０が保有する承認対象情報を説明する図である。
例えば、ユーザＡが、以下の３種類のチケットを保有した状態でイベント会場に来場したケースを例に挙げる。
・イベント会場への入場チケット（チケットＩＤ：Ｔｃ－Ａ０１０）
・全エリア利用チケット（チケットＩＤ：Ｔｃ－Ｂ０３５）
・ビール引換券（Ｔｃ－Ｃ０１０３）
図１１は、検札装置３０が保有する承認対象情報を説明する図である。
例えば、ユーザＡが、以下の３種類のチケットを保有した状態でイベント会場に来場したケースを例に挙げる。
・イベント会場への入場チケット（チケットＩＤ：Ｔｃ－Ａ０１０）
・全エリア利用チケット（チケットＩＤ：Ｔｃ－Ｂ０３５）
・ビール引換券（Ｔｃ－Ｃ０１０３）
【0106】
この場合において、以下の３つの検札装置３０がそれぞれの検札所に配備されている。
・検札装置３０Ａ（会場の入場ゲートに配備される検札装置３０）
・検札装置３０Ｂ（有料Ａエリアゲートに配備される検札装置３０）
・検札装置３０Ｃ（ドリンクブースに配備される検札装置３０）
・検札装置３０Ａ（会場の入場ゲートに配備される検札装置３０）
・検札装置３０Ｂ（有料Ａエリアゲートに配備される検札装置３０）
・検札装置３０Ｃ（ドリンクブースに配備される検札装置３０）
【0107】
この場合において、検札装置３０Ａには、イベント会場への入場に関する権限となる権限ＩＤ（権限ＩＤ：Ａ００１）が、承認対象情報として予め登録されている。ユーザＡは、ユーザＩＤが記録された二次元コードを入場ゲートにおいて検札装置３０Ａに提示することで、ユーザＡが権限ＩＤ：Ａ００１に該当するチケットを保有していることが確認され、入場が許可される。これにより、チケットＤＢにおける入場チケット（チケットＩＤ：Ｔｃ－Ａ０１０）の利用ステータスは使用済みに更新される。
【0108】
次に、検札装置３０Ｂには、有料Ａエリアへの入場に関する権限となる権限ＩＤ（権限ＩＤ：Ｂ００１およびＢ００２）が、承認対象情報として予め登録されている。ここで、権限ＩＤ：Ｂ００１は全エリア利用チケットの権限を指し、権限ＩＤ：Ｂ００２は、有料Ａエリアチケットの権限を指す。このように、複数の承認対象権限が検札装置に登録されることがある。
ユーザＡは、ユーザＩＤが記録された二次元コードを有料Ａエリアゲートにおいて検札装置３０Ｂに提示することで、ユーザＡが権限ＩＤ：Ｂ００１に該当するチケットを保有していることが確認され、有料Ａエリアへの入場が許可される。
ユーザＡは、ユーザＩＤが記録された二次元コードを有料Ａエリアゲートにおいて検札装置３０Ｂに提示することで、ユーザＡが権限ＩＤ：Ｂ００１に該当するチケットを保有していることが確認され、有料Ａエリアへの入場が許可される。
【0109】
次に、検札装置３０Ｃには、ビール引換券に関する権限となる権限ＩＤ（権限ＩＤ：Ｃ００５）が、承認対象情報として予め登録されている。ユーザＡは、ユーザＩＤが記録された二次元コードをビールブースにおいて検札装置３０Ｃに提示することで、ユーザＡが権限ＩＤ：Ｃ００５に該当するチケット（ビール引換券）を保有していることが確認され、引き換え対象となるビールが提供される。
【0110】
すなわち、システム１では、従来の検札処理のように、ユーザが提示するチケットに関する情報を読み取ったうえでの要求（入場）可否の判定は行わない。システム１では、チケットに関する情報を読み取ることなく、ユーザの主体情報を読み取りユーザを特定したうえで、チケットに関する保有記録からユーザに対する入場可否の判定を行う。
このようなシステム１の処理について、以下に具体的に説明する。
このようなシステム１の処理について、以下に具体的に説明する。
【0111】
（４）システム１の動作
本実施形態におけるシステム１の動作について説明する。
本実施形態におけるシステム１の動作について説明する。
【0112】
（４－１）ユーザの登録処理
図１２は、本実施形態のユーザ登録処理のフローチャートである。
図１２に示すように、ユーザ端末１０は、ユーザ登録申請の受付を行う（ステップＳ１１１）。
具体的には、ユーザ端末１０のプロセッサ１２は、ユーザから入力されたユーザに関する情報を受け付ける。この際、生体情報としては、ユーザがユーザ端末１０に内蔵されたカメラを用いて撮影した顔画像の情報を用いることができる。ユーザ端末１０のプロセッサ１２は、撮影されたユーザの顔画像に対して画像処理を行い、特徴量に関する情報を抽出する。
プロセッサ１２は、取得したユーザに関する情報を、チケット管理サーバ２０に対して送信する。
図１２は、本実施形態のユーザ登録処理のフローチャートである。
図１２に示すように、ユーザ端末１０は、ユーザ登録申請の受付を行う（ステップＳ１１１）。
具体的には、ユーザ端末１０のプロセッサ１２は、ユーザから入力されたユーザに関する情報を受け付ける。この際、生体情報としては、ユーザがユーザ端末１０に内蔵されたカメラを用いて撮影した顔画像の情報を用いることができる。ユーザ端末１０のプロセッサ１２は、撮影されたユーザの顔画像に対して画像処理を行い、特徴量に関する情報を抽出する。
プロセッサ１２は、取得したユーザに関する情報を、チケット管理サーバ２０に対して送信する。
【0113】
ステップＳ１１１の後に、チケット管理サーバ２０は、ユーザ登録の申請を受領する
（ステップＳ２１１）。
具体的には、チケット管理サーバ２０のプロセッサ２２は、ステップＳ１１１においてユーザ端末１０から送信されたユーザに関する情報を、ユーザＤＢに格納する。これにより、ユーザＤＢに新たなレコードが記録される。
（ステップＳ２１１）。
具体的には、チケット管理サーバ２０のプロセッサ２２は、ステップＳ１１１においてユーザ端末１０から送信されたユーザに関する情報を、ユーザＤＢに格納する。これにより、ユーザＤＢに新たなレコードが記録される。
【0114】
ステップＳ２１１の後に、ユーザ端末１０は、ユーザ情報の変更または更新に関する入力を受け付ける（ステップＳ１１２）。
具体的には、ユーザは、既に登録した情報うち、変更または更新された情報についてユーザ端末１０を操作して入力する。ユーザ端末１０のプロセッサ１２は、入力された情報をチケット管理サーバ２０に対して送信する。
具体的には、ユーザは、既に登録した情報うち、変更または更新された情報についてユーザ端末１０を操作して入力する。ユーザ端末１０のプロセッサ１２は、入力された情報をチケット管理サーバ２０に対して送信する。
【0115】
ステップＳ１１２の後に、チケット管理サーバ２０は、ユーザＤＢを更新する（ステップＳ２１２）。
具体的には、チケット管理サーバ２０のプロセッサ２２は、ステップＳ１１２においてユーザ端末１０から送信されたユーザに関する新たな情報を用いて、ユーザＤＢを更新する。これにより、ユーザＤＢは最新の情報に更新される。ユーザＤＢの更新は必要に応じて行われる。
以上により、ユーザの登録処理が終了する。
具体的には、チケット管理サーバ２０のプロセッサ２２は、ステップＳ１１２においてユーザ端末１０から送信されたユーザに関する新たな情報を用いて、ユーザＤＢを更新する。これにより、ユーザＤＢは最新の情報に更新される。ユーザＤＢの更新は必要に応じて行われる。
以上により、ユーザの登録処理が終了する。
【0116】
（４－２）チケットの購入処理
図１３は、本実施形態のチケットの購入処理のフローチャートである。
図１３に示すように、ユーザ端末１０は、チケット購入操作の受付（ステップＳ１２１）を実行する。
具体的には、ユーザ端末１０のプロセッサ１２は、入力デバイス１５に対してなされた購入操作を、入出力インタフェース１３を介して受け付ける。
購入操作は、例えば、ユーザＩＤの入力、興行の選択、日時の選択、座席種別の選択、購入ボタン（ボタンオブジェクトまたは物理ボタン）の押下、またはそれらの組み合わせを含み得る。
図１３は、本実施形態のチケットの購入処理のフローチャートである。
図１３に示すように、ユーザ端末１０は、チケット購入操作の受付（ステップＳ１２１）を実行する。
具体的には、ユーザ端末１０のプロセッサ１２は、入力デバイス１５に対してなされた購入操作を、入出力インタフェース１３を介して受け付ける。
購入操作は、例えば、ユーザＩＤの入力、興行の選択、日時の選択、座席種別の選択、購入ボタン（ボタンオブジェクトまたは物理ボタン）の押下、またはそれらの組み合わせを含み得る。
【0117】
ステップＳ１２１の後に、チケット管理サーバ２０は、チケットの販売処理を実行する（ステップＳ２２１）。
具体的には、プロセッサ１２は、ステップＳ１２１において受け付けた購入操作の内容に基づいて、ユーザが購入を希望するチケットを特定する。そしてプロセッサ１２は、特定したチケットの価格に応じた購入費用の決済の有無を確認する。
具体的には、プロセッサ１２は、ステップＳ１２１において受け付けた購入操作の内容に基づいて、ユーザが購入を希望するチケットを特定する。そしてプロセッサ１２は、特定したチケットの価格に応じた購入費用の決済の有無を確認する。
【0118】
ステップＳ１０２の後に、チケット管理サーバ２０は、保有ＤＢの更新を行う（ステップＳ２２２）を行う。具体的には、チケット管理サーバ２０のプロセッサ２２は、ステップＳ２２１において販売したチケットについて、購入したユーザが保有する記録を新たなレコードとして保有ＤＢに記録させる。
【0119】
ステップＳ２２２の後に、チケット管理サーバ２０は、チケット情報の提供（ステップＳ２２３）を実行する。
具体的には、プロセッサ２２は、ステップＳ２２２において更新した保有ＤＢを参照して、チケット情報を生成する。チケット情報は、ステップＳ２２２において登録したチケットＩＤに関する情報を含む。さらに、チケット情報は、チケット購入者のユーザＩＤを含むことができる。チケット情報に含まれる情報の一部または全部は例えばＱＲコード（登録商標）または他のコード情報に符号化されてもよい。プロセッサ２２は、生成したチケット情報を、チケットの購入者に提供する。一例として、プロセッサ２２は、通信インタフェース２４を介してユーザ端末１０へ送信する。
具体的には、プロセッサ２２は、ステップＳ２２２において更新した保有ＤＢを参照して、チケット情報を生成する。チケット情報は、ステップＳ２２２において登録したチケットＩＤに関する情報を含む。さらに、チケット情報は、チケット購入者のユーザＩＤを含むことができる。チケット情報に含まれる情報の一部または全部は例えばＱＲコード（登録商標）または他のコード情報に符号化されてもよい。プロセッサ２２は、生成したチケット情報を、チケットの購入者に提供する。一例として、プロセッサ２２は、通信インタフェース２４を介してユーザ端末１０へ送信する。
【0120】
ステップＳ２２３の後に、ユーザ端末１０は、チケット情報の保存（Ｓ１２３）を実行する。
具体的には、プロセッサ１２は、ステップＳ２２３において提供されたチケット情報を取得する。プロセッサ１２は、取得したチケット情報を記憶装置１１に保存する。これにより、プロセッサ１２は、必要に応じて、チケット情報を表示できる。
これにより、チケットの発券処理が終了する。
具体的には、プロセッサ１２は、ステップＳ２２３において提供されたチケット情報を取得する。プロセッサ１２は、取得したチケット情報を記憶装置１１に保存する。これにより、プロセッサ１２は、必要に応じて、チケット情報を表示できる。
これにより、チケットの発券処理が終了する。
【0121】
（４－３）来場時の検札処理
本実施形態の検札処理について説明する。図１４は、本実施形態の検札処理のフローチャートである。
本実施形態の検札処理について説明する。図１４は、本実施形態の検札処理のフローチャートである。
【0122】
例えば、イベント会場に来場したユーザは、第１の検札装置３０Ａ（以下、検札装置３０）が配備された入場ゲートを訪れる。図１４に示すように、入場ゲートにおいて、検札装置３０は、ユーザの主体情報を取得する（ステップＳ３３１）。
具体的には、検札装置３０のプロセッサ３２が、来場者のユーザ端末１０に表示された二次元コードを撮影する。
具体的には、検札装置３０のプロセッサ３２が、来場者のユーザ端末１０に表示された二次元コードを撮影する。
【0123】
ステップＳ３３１の後に、検札装置３０は、ユーザＩＤを特定する（ステップＳ３３２）。
具体的には、検札装置３０のプロセッサ３２は、撮影した二次元コードに記録されたユーザＩＤを識別することで、来場者のユーザＩＤを特定する。
具体的には、検札装置３０のプロセッサ３２は、撮影した二次元コードに記録されたユーザＩＤを識別することで、来場者のユーザＩＤを特定する。
【0124】
ステップＳ３３２の後に、検札装置３０は、ユーザが保有するチケットを特定する（ステップＳ３３３）。
具体的には、検札装置３０のプロセッサ３２は、ステップＳ３３２において特定したユーザＩＤについて、チケット管理サーバ２０に対して照会することで、当該ユーザＩＤに該当するユーザが保有するチケットのチケットＩＤを特定する。この際、チケット管理サーバ２０のプロセッサ２２は、保有ＤＢを参照して、特定したユーザＩＤに紐づけられたチケットＩＤを抽出する。これにより、検札対象である来場者が保有するチケットが特定される。
なお、予め検札装置３０に保有ＤＢの情報が記録されている場合には、チケット管理サーバ２０への照会は不要であり、検札装置３０は記録された保有ＤＢの情報を用いてユーザＩＤと紐付けられたチケットのチケットＩＤを特定する。
具体的には、検札装置３０のプロセッサ３２は、ステップＳ３３２において特定したユーザＩＤについて、チケット管理サーバ２０に対して照会することで、当該ユーザＩＤに該当するユーザが保有するチケットのチケットＩＤを特定する。この際、チケット管理サーバ２０のプロセッサ２２は、保有ＤＢを参照して、特定したユーザＩＤに紐づけられたチケットＩＤを抽出する。これにより、検札対象である来場者が保有するチケットが特定される。
なお、予め検札装置３０に保有ＤＢの情報が記録されている場合には、チケット管理サーバ２０への照会は不要であり、検札装置３０は記録された保有ＤＢの情報を用いてユーザＩＤと紐付けられたチケットのチケットＩＤを特定する。
【0125】
ステップＳ３３３の後に、検札装置３０は、チケットの権限を確認する（ステップＳ３３４）。
具体的には、検札装置３０のプロセッサ３２は、ユーザが保有するチケットについて、チケット管理サーバ２０に権限内容の照会を行う。この際、チケット管理サーバ２０のプロセッサ２２は、チケットＤＢを参照して、ユーザが保有するチケットに設定された権限ＩＤを特定する。プロセッサ２２は、検札装置３０に対して特定した権限ＩＤを送信する。なお、ステップＳ３３３およびステップＳ３３４におけるチケット管理サーバ２０への照会の処理は一連の処理として行ってもよい。
具体的には、検札装置３０のプロセッサ３２は、ユーザが保有するチケットについて、チケット管理サーバ２０に権限内容の照会を行う。この際、チケット管理サーバ２０のプロセッサ２２は、チケットＤＢを参照して、ユーザが保有するチケットに設定された権限ＩＤを特定する。プロセッサ２２は、検札装置３０に対して特定した権限ＩＤを送信する。なお、ステップＳ３３３およびステップＳ３３４におけるチケット管理サーバ２０への照会の処理は一連の処理として行ってもよい。
【0126】
ステップＳ３３４の後に、検札装置３０は、入場可否（ユーザからの要求の可否）の判定（ステップＳ３３５）を実行する。
具体的には、検札装置３０のプロセッサ３２は、ステップ３３４において確認された権限ＩＤと、予め記憶装置３１に登録された承認対象情報としての承認対象権限ＩＤと、が一致するかどうかを判定する。
具体的には、検札装置３０のプロセッサ３２は、ステップ３３４において確認された権限ＩＤと、予め記憶装置３１に登録された承認対象情報としての承認対象権限ＩＤと、が一致するかどうかを判定する。
【0127】
また、プロセッサ３２は、要求の可否を判定するステップ（ステップＳ３３５）では、権限ＤＢに記録されたチケットの利用条件を確認して、要求の可否の判定を行うことができる。利用条件が設定されていない場合には、利用条件による判定は省略してもよい。
例えば、プロセッサ３２は、ユーザＤＢに記録されたユーザの属性を参照して、利用条件との比較を行い、要求の可否を判定してもよい。具体的には、プロセッサ３２は、来場者として特定されたユーザについて、ユーザＤＢに記録された各種の属性を特定する。プロセッサ３２は、例えば、図６に示すユーザＤＢに記載された以下の属性を入場可否の判定に用いることができる。
・ワクチン接種情報
・ＢＡＮ適用フラグ
例えば、プロセッサ３２は、ユーザＤＢに記録されたユーザの属性を参照して、利用条件との比較を行い、要求の可否を判定してもよい。具体的には、プロセッサ３２は、来場者として特定されたユーザについて、ユーザＤＢに記録された各種の属性を特定する。プロセッサ３２は、例えば、図６に示すユーザＤＢに記載された以下の属性を入場可否の判定に用いることができる。
・ワクチン接種情報
・ＢＡＮ適用フラグ
【0128】
そして、来場が許可される条件として、ワクチンの接種回数などが入場可能条件として設定されている場合には、プロセッサ３２は、権限ＤＢに規定された利用条件と、検札対象であるユーザのワクチン接種情報と、を比較して、当該ユーザが当該チケットを利用可能（この場合は来場可能）かどうかについて判定する。当該ユーザが、仮に利用条件を満たさない場合は、プロセッサ３２は、当該ユーザについて入場エラー処理（要求拒絶処理）を実行する。
【0129】
また、プロセッサ３２は、検札対象であるユーザについて、ＢＡＮ適用フラグが記録されているかどうかを確認してもよい。仮にＢＡＮ適用フラグが記録されている場合は、プロセッサ３２は、当該ユーザについて入場エラー処理（要求拒絶処理）を実行する。
【0130】
ステップＳ３３５の後に、検札装置３０は、判定結果の出力を行う（ステップＳ３３６）。
例えば、プロセッサ３２は、ステップＳ３３５において、来場者であるユーザが入場権限となるチケットを保有していない場合、あるいは、本人の属性により入場がＮＧとなった場合には、検札装置３０は、入場エラー処理を実行する。検札装置３０は、チケットが特典の付与に関する者である場合には、入場エラー処理に代えて、特典付与エラー処理を実行する。
例えば、プロセッサ３２は、ステップＳ３３５において、来場者であるユーザが入場権限となるチケットを保有していない場合、あるいは、本人の属性により入場がＮＧとなった場合には、検札装置３０は、入場エラー処理を実行する。検札装置３０は、チケットが特典の付与に関する者である場合には、入場エラー処理に代えて、特典付与エラー処理を実行する。
【0131】
具体的には、プロセッサ３２は、ステップＳ３３６において来場者の入場を拒否すると判定した場合に、以下の少なくとも１つの処理を行う。
・警報の発報（例えば、ランプの点灯、所定音の出力、所定画面の表示、またはそれらの組み合わせにより、来場者の入場が拒否されたことを本人および係員に知覚させるとともに、係員にアフターケアを促す）
・ゲートの閉鎖或いは開放しない（例えば、電動式のゲートのバー、またはフラップドアを閉じて来場者の入場を物理的に阻害する）
・警報の発報（例えば、ランプの点灯、所定音の出力、所定画面の表示、またはそれらの組み合わせにより、来場者の入場が拒否されたことを本人および係員に知覚させるとともに、係員にアフターケアを促す）
・ゲートの閉鎖或いは開放しない（例えば、電動式のゲートのバー、またはフラップドアを閉じて来場者の入場を物理的に阻害する）
【0132】
なお、検札装置３０付近の滞留を防ぐ観点から、係員によるアフターケアは、来場者を対象空間に便宜的に入場させてから行われてもよい。一例として、係員は、来場者の属性情報、来場者の連絡先情報、チケットの購入場所、チケットの購入時期、またはそれらの組み合わせを来場者から聞き取り、チケット情報と照合してもよい。
ステップＳ３３６の後に、来場時の検札処理は終了する。
ステップＳ３３６の後に、来場時の検札処理は終了する。
【0133】
一方、ステップＳ３３５において、来場者であるユーザが入場権限となるチケットを保有している場合、かつ本人の属性により入場がＮＧとならなかった場合には、プロセッサ３２は、入場の許可、いわゆる「もぎり処理」を実行する。
検札装置３０は、チケットが物品の引換券である場合には、物品の引換を承認する。
検札装置３０は、チケットが物品の引換券である場合には、物品の引換を承認する。
【0134】
具体的には、プロセッサ３２は、ステップＳ３３５において来場者からの要求を承認すると判定した場合に、以下の少なくとも１つの処理を行う。
・入場が許可されたことの報知（例えば、ランプの点灯、所定音の出力、所定画面の表示、またはそれらの組み合わせにより、来場者の入場が許可されたことを本人および係員に知覚させる）
・ゲートの開放（例えば、電動式のゲートのバー、またはフラップドアを開いて来場者の進入を促す）
・該当する引換対象物品の提供（特典グッズの引き渡し等）
・入場が許可されたことの報知（例えば、ランプの点灯、所定音の出力、所定画面の表示、またはそれらの組み合わせにより、来場者の入場が許可されたことを本人および係員に知覚させる）
・ゲートの開放（例えば、電動式のゲートのバー、またはフラップドアを開いて来場者の進入を促す）
・該当する引換対象物品の提供（特典グッズの引き渡し等）
【0135】
プロセッサ３２は、ステップＳ３３６の際に、チェックインリストを作成、または更新してもよい。
チェックインリストは、各来場者に対する検札処理の結果一覧に関する情報である。チェックインリストは、一例として以下の要素の少なくとも１つを含む。
・チェックイン時刻
・チェックインの順番
・来場者のユーザＩＤ
・ユーザＩＤに関連付けられるユーザ名
・来場者が保有していた入場権限となるチケットのチケットＩＤ
・入場可否の判定（ステップＳ３３５）の結果（入場許可／入場拒否）
・イベント会場においてユーザに割り当てられた区域（例えば指定席）
ステップＳ３３６において、プロセッサ３２は、チケット管理サーバ２０に対してもぎり処理の結果を送信する。作成または更新したチェックインリストを共有することで、プロセッサ３２は、チケット管理サーバ２０に対してもぎり処理の結果を送信してもよい。
チェックインリストは、各来場者に対する検札処理の結果一覧に関する情報である。チェックインリストは、一例として以下の要素の少なくとも１つを含む。
・チェックイン時刻
・チェックインの順番
・来場者のユーザＩＤ
・ユーザＩＤに関連付けられるユーザ名
・来場者が保有していた入場権限となるチケットのチケットＩＤ
・入場可否の判定（ステップＳ３３５）の結果（入場許可／入場拒否）
・イベント会場においてユーザに割り当てられた区域（例えば指定席）
ステップＳ３３６において、プロセッサ３２は、チケット管理サーバ２０に対してもぎり処理の結果を送信する。作成または更新したチェックインリストを共有することで、プロセッサ３２は、チケット管理サーバ２０に対してもぎり処理の結果を送信してもよい。
【0136】
ステップＳ３３６の後に、チケット管理サーバ２０は、チケットの使用を検出する（ステップＳ２３１）。
具体的には、チケット管理サーバ２０のプロセッサ３２は、共有されたチェックインリストに基づいてチケットＤＢの「利用ステータス」フィールドを更新することで、使用されたチケットを把握する。プロセッサ３２は、チケットＤＢの「利用ステータス」フィールドの更新に代えて、「利用可能残回数」フィールドの残回数を減らす更新や「利用回数」フィールドの回数を増やす更新を行ってもよい。
具体的には、チケット管理サーバ２０のプロセッサ３２は、共有されたチェックインリストに基づいてチケットＤＢの「利用ステータス」フィールドを更新することで、使用されたチケットを把握する。プロセッサ３２は、チケットＤＢの「利用ステータス」フィールドの更新に代えて、「利用可能残回数」フィールドの残回数を減らす更新や「利用回数」フィールドの回数を増やす更新を行ってもよい。
【0137】
ステップＳ２３１の後に、チケット管理サーバ２０は、特典チケットの付与を行う（ステップＳ２３２）。
具体的には、チケット管理サーバ２０のプロセッサ２２は、ステップＳ２３１において使用が検出されたチケットについて、チケットＤＢを参照して、設定されている特典チケットのチケットＩＤを確認する。プロセッサ２２は、チケットを使用したユーザに対して、該当する特典チケットを付与するために、保有ＤＢに新たなレコードを記録する。プロセッサ２２は、保有ＤＢの新たなレコードとして、特典チケットを付与されるユーザのユーザＩＤと、特典チケットのチケットＩＤと、をそれぞれ記録する。プロセッサ２２は、特典チケットがユーザに対して特典として付与されたことを、ユーザ端末１０に対して通知する。
具体的には、チケット管理サーバ２０のプロセッサ２２は、ステップＳ２３１において使用が検出されたチケットについて、チケットＤＢを参照して、設定されている特典チケットのチケットＩＤを確認する。プロセッサ２２は、チケットを使用したユーザに対して、該当する特典チケットを付与するために、保有ＤＢに新たなレコードを記録する。プロセッサ２２は、保有ＤＢの新たなレコードとして、特典チケットを付与されるユーザのユーザＩＤと、特典チケットのチケットＩＤと、をそれぞれ記録する。プロセッサ２２は、特典チケットがユーザに対して特典として付与されたことを、ユーザ端末１０に対して通知する。
【0138】
プロセッサ２２は、特典チケットを付与するステップでは、チケットＤＢに記録された特典チケット付与条件を確認して、付与の可否の判定を行うことができる。付与条件が設定されていない場合には、付与条件による判定は省略してもよい。
例えば、プロセッサ２２は、ユーザＤＢに記録されたユーザの属性を参照して、利用条件との比較を行い、要求の可否を判定してもよい。具体的には、プロセッサ２２は、来場者として特定されたユーザについて、ユーザＤＢに記録された各種の属性を特定する。プロセッサ２２は、例えば、図６に示すユーザＤＢに記載された以下の属性を入場可否の判定に用いることができる。
・性別（例えば、男性又は女性のファンに対して付与される特典）
・年齢（例えば、アルコール類など成人に対して付与される特典、子供向けグッズ等）
・居住地（例えば、地元ファン獲得の施策として設定された特典等）
これにより、チケットの検札処理が終了する。
例えば、プロセッサ２２は、ユーザＤＢに記録されたユーザの属性を参照して、利用条件との比較を行い、要求の可否を判定してもよい。具体的には、プロセッサ２２は、来場者として特定されたユーザについて、ユーザＤＢに記録された各種の属性を特定する。プロセッサ２２は、例えば、図６に示すユーザＤＢに記載された以下の属性を入場可否の判定に用いることができる。
・性別（例えば、男性又は女性のファンに対して付与される特典）
・年齢（例えば、アルコール類など成人に対して付与される特典、子供向けグッズ等）
・居住地（例えば、地元ファン獲得の施策として設定された特典等）
これにより、チケットの検札処理が終了する。
【0139】
（５）小括
以上説明したように、本実施形態に係るシステム１によれば、検札装置３０が、ユーザの主体情報を取得し、取得した主体情報に紐づけられたユーザが保有するチケットに対して設定された権限に基づいて、ユーザからの要求（入場）の可否を判定する。
このため、一つのイベントにおいて用いられる付帯的なサービスに関する複数のチケットをユーザが保有している場合に、サービスごとの検札場面において、対応するチケットをユーザが選択して、検札装置３０に対して提示する必要が無く、ユーザの主体情報を画一的に提示することで、検札処理を行うことができ、イベント内での追加体験においてユーザの利便性を向上することができる。
以上説明したように、本実施形態に係るシステム１によれば、検札装置３０が、ユーザの主体情報を取得し、取得した主体情報に紐づけられたユーザが保有するチケットに対して設定された権限に基づいて、ユーザからの要求（入場）の可否を判定する。
このため、一つのイベントにおいて用いられる付帯的なサービスに関する複数のチケットをユーザが保有している場合に、サービスごとの検札場面において、対応するチケットをユーザが選択して、検札装置３０に対して提示する必要が無く、ユーザの主体情報を画一的に提示することで、検札処理を行うことができ、イベント内での追加体験においてユーザの利便性を向上することができる。
【0140】
また、システム１では、保有ＤＢには、チケットＩＤごとに、保有するユーザのユーザＩＤが紐づけられている。このため、ユーザが保有するチケットを正確に把握することができる。
【0141】
また、システム１では、ユーザからの要求の可否を判定する際に、権限に紐づけられたチケットの利用条件を参照して、要求の可否を判定する。このため、当該ユーザがチケットを保有しているかどうかだけではなく、適切な利用条件を満たすかどうかを考慮して、イベント運営者にとって好適なチケットの利用を促すことができる。
【0142】
また、システム１では、特典チケットの付与条件が設定されているので、例えば年齢制限のあるサービスに関する引換券について、付与対象を制限することができ、主催者の利便性を向上することができる。
【0143】
（６）変形例
本実施形態の変形例について説明する。
本実施形態の変形例について説明する。
【0144】
（６－１）変形例１（顔撮影による生体認証）
次に、変形例１に係るシステム１について説明する。図１５は変形例１に係るシステム１の処理全体の流れを説明する図である。
変形例１に係るシステム１における検札装置３０は、主体情報を取得するステップにおいて、ユーザを識別可能な生体情報を取得するステップと、取得した生体情報を用いて、ユーザＤＢを参照して、当該生体情報に対応するユーザのユーザＩＤを特定するステップと、を実行する。
次に、変形例１に係るシステム１について説明する。図１５は変形例１に係るシステム１の処理全体の流れを説明する図である。
変形例１に係るシステム１における検札装置３０は、主体情報を取得するステップにおいて、ユーザを識別可能な生体情報を取得するステップと、取得した生体情報を用いて、ユーザＤＢを参照して、当該生体情報に対応するユーザのユーザＩＤを特定するステップと、を実行する。
【0145】
具体的には、検札装置３０は、図１４に示すステップＳ３３１において、来場者の顔画像を撮影することで、来場者の生体情報を取得する。この際、検札装置３０のプロセッサ３２は、可視光カメラ３５２と協働して、来場者の顔画像を読み取る。この際、来場者の顔の画像を撮影するのではなく、来場者の顔を３次元スキャンしてもよい。
【0146】
ステップＳ３３１において、プロセッサ３２は、可視光カメラ３５２の撮影した画像を来場者向けに出力デバイス３６（ディスプレイ）に表示してもよい。これにより、来場者に、撮影されている自身の画像の様子をフィードバックし、カメラに対する位置、姿勢、および顔の向きなどの微調整を促すことができる。
【0147】
ステップＳ３３１の後に、検札装置３０は、ユーザＩＤを特定する（図１４に示すステップＳ３３２）。
具体的には、検札装置３０のプロセッサ３２には、抽出した来場者の生体情報の特徴量について、チケット管理サーバ２０に対して照会を行うことで、当該特徴量に該当するユーザを特定する。この際、チケット管理サーバ２０は、ユーザＤＢに記録されている生体情報（例えば顔画像の特徴量）と、ステップＳ３３１において取得した来場者の顔画像の特徴量と、を比較する。両者の特徴量が一定以上の類似度を備えていると判断されると、来場者のユーザＩＤが特定される。
具体的には、検札装置３０のプロセッサ３２には、抽出した来場者の生体情報の特徴量について、チケット管理サーバ２０に対して照会を行うことで、当該特徴量に該当するユーザを特定する。この際、チケット管理サーバ２０は、ユーザＤＢに記録されている生体情報（例えば顔画像の特徴量）と、ステップＳ３３１において取得した来場者の顔画像の特徴量と、を比較する。両者の特徴量が一定以上の類似度を備えていると判断されると、来場者のユーザＩＤが特定される。
【0148】
なお、検札装置３０の記憶装置３１に予めユーザＤＢに記録されたユーザ情報を格納することで、検札装置３０は、チケット管理サーバ２０に対してユーザの照会を行わなくてもよい。この場合には、検札装置３０は、記憶装置３１に記憶されたユーザ情報を用いて抽出された特徴量に対応するユーザの確認を行う。
【0149】
変形例２に係るシステム１では、ステップ３３２の後に、前述した実施形態と同様にステップＳ３３３以降の処理を実行する。
このように、変形例１に係るシステム１では、主体情報を検出するステップでは、ユーザの生体情報を取得することで、主体情報を取得する。このため、ユーザからの二次元コードの提示を要求することなく、例えば、検札時に来場者の顔画像を撮影するといった簡易な構成により、来場者の主体情報を取得することができる。これにより、検札処理の効率化に寄与することができる。
このように、変形例１に係るシステム１では、主体情報を検出するステップでは、ユーザの生体情報を取得することで、主体情報を取得する。このため、ユーザからの二次元コードの提示を要求することなく、例えば、検札時に来場者の顔画像を撮影するといった簡易な構成により、来場者の主体情報を取得することができる。これにより、検札処理の効率化に寄与することができる。
【0150】
また、ユーザの生体情報として、顔の特徴量に代えて、他のバイオメトリクス（例えば、指紋、掌紋、虹彩、静脈、筋電位など）に関する特徴量を用いて来場者のユーザＩＤを特定してもよい。
また、赤外線、ＲＦＩＤ、音波、レーザ型の一次元バーコードリーダー等のその他のセンサにより、ユーザ固有の情報を取得して、ユーザの生体情報として用いてもよい。
また、複数種類の生体情報を用いてユーザＩＤを特定してもよい。
また、赤外線、ＲＦＩＤ、音波、レーザ型の一次元バーコードリーダー等のその他のセンサにより、ユーザ固有の情報を取得して、ユーザの生体情報として用いてもよい。
また、複数種類の生体情報を用いてユーザＩＤを特定してもよい。
【0151】
（６－２）変形例２（イベント別ユーザＩＤを用いる）
次に、変形例２に係るシステム１について説明する。図１６は変形例２に係るシステム１の処理全体の流れを説明する図である。
次に、変形例２に係るシステム１について説明する。図１６は変形例２に係るシステム１の処理全体の流れを説明する図である。
【0152】
図１６に示すように、変形例２に係るシステム１では、ユーザの主体情報として、ユーザＩＤに代えて、ユーザＩＤおよびイベントＩＤにより作成されたイベント別ユーザＩＤを用いる。
イベント別ユーザＩＤとは、特定のイベント内の各種の検札シーンにおいて、特定のユーザが共通して利用することができる識別情報であり、ユーザごと、およびイベントごとに固有の値をとる識別情報である。
イベント別ユーザＩＤとは、特定のイベント内の各種の検札シーンにおいて、特定のユーザが共通して利用することができる識別情報であり、ユーザごと、およびイベントごとに固有の値をとる識別情報である。
【0153】
変形例２に係るシステム１では、ユーザが提示する二次元コードに、イベント別ユーザＩＤに関する情報が記録されている。そして、変形例２に係るシステム１では、保有ＤＢにおいて、「ユーザＩＤ」フィールドに代えて、「イベント別ユーザＩＤ」フィールドが設けられている。
「イベント別ユーザＩＤフィールド」には、イベントＩＤとユーザＩＤに基づいて作成され、イベントとユーザの双方を識別可能な識別情報が格納されている。
「イベント別ユーザＩＤフィールド」には、イベントＩＤとユーザＩＤに基づいて作成され、イベントとユーザの双方を識別可能な識別情報が格納されている。
【0154】
変形例２に係るシステム１では、主体情報の取得するステップ（図１４に示すステップＳ３３１）において、イベント別ユーザＩＤが記録された二次元コードを撮影することで、イベント別ユーザＩＤを主体情報として取得する。
そして、ステップＳ３３１の後に、変形例２に係るシステム１では、ユーザＩＤの特定に代えて、イベント別ユーザＩＤの特定を行う（ステップＳ３３２）。イベント別ユーザＩＤは、ユーザＩＤを含んでいるので、イベント別ユーザＩＤを特定することで、ユーザを特定することができる。
そして、ステップＳ３３１の後に、変形例２に係るシステム１では、ユーザＩＤの特定に代えて、イベント別ユーザＩＤの特定を行う（ステップＳ３３２）。イベント別ユーザＩＤは、ユーザＩＤを含んでいるので、イベント別ユーザＩＤを特定することで、ユーザを特定することができる。
【0155】
次に、変形例２に係るシステム１では、ステップＳ３３２の後に、イベント別ユーザＩＤを用いて保有するチケットの特定を行う（ステップＳ３３３）。
具体的には、検札装置３０のプロセッサ３２は、特定したイベント別ユーザＩＤについてチケット管理サーバ２０に対して照会を行うことで、保有するチケットを特定する。チケット管理サーバ２０は、図１６に示す保有ＤＢを参照し、検札装置３０からの照会に係るイベント別ユーザＩＤに紐づけられたチケットＩＤを特定する。
具体的には、検札装置３０のプロセッサ３２は、特定したイベント別ユーザＩＤについてチケット管理サーバ２０に対して照会を行うことで、保有するチケットを特定する。チケット管理サーバ２０は、図１６に示す保有ＤＢを参照し、検札装置３０からの照会に係るイベント別ユーザＩＤに紐づけられたチケットＩＤを特定する。
【0156】
その後、検札装置３０は、図１４に示すチケットの権限の確認の処理（ステップＳ３３４）を行う。その後の処理は、図１４に沿って行われる。
このように、変形例に係るシステム１では、ユーザＩＤに代えて、ユーザＩＤおよびイベントＩＤを含むイベント別ユーザＩＤを用いてユーザの主体情報を特定する。このため、保有ＤＢに記録されたチケットの保有状態を示すデータ群のうち、ユーザＩＤとイベントＩＤの二つの識別情報を用いて、検札に必要な情報をソートすることができ、検札処理における判定の付加を低減することができる。また、主体情報をイベント毎に変更するため不正やミスを抑制できる。
このように、変形例に係るシステム１では、ユーザＩＤに代えて、ユーザＩＤおよびイベントＩＤを含むイベント別ユーザＩＤを用いてユーザの主体情報を特定する。このため、保有ＤＢに記録されたチケットの保有状態を示すデータ群のうち、ユーザＩＤとイベントＩＤの二つの識別情報を用いて、検札に必要な情報をソートすることができ、検札処理における判定の付加を低減することができる。また、主体情報をイベント毎に変更するため不正やミスを抑制できる。
【0157】
（６－３）変形例３（権限情報の特定の前に本人確認を行う）
次に、変形例３に係るシステム１について説明する。図１７は変形例３に係るシステム１の処理全体の流れを説明する図である。
次に、変形例３に係るシステム１について説明する。図１７は変形例３に係るシステム１の処理全体の流れを説明する図である。
【0158】
図１７に示すように、変形例３に係るシステム１では、権限情報を特定するステップ（図１４におけるステップＳ３３４）に先立って、ユーザの本人確認を行う。
ユーザの本人確認では、ユーザを識別可能な生体情報を取得したうえで、予めユーザＤＢに登録されているユーザに関する情報を用いて生体認証を行う。
この変形例では、ユーザ端末１０に表示される二次元コードには、以下の情報が含まれる。
・チケットＩＤ（本人確認に用いる情報）
・チェックディジット（本人確認に用いる情報）
・ユーザＩＤ（権限確認に用いる情報）
そして、検札装置３０には、予め、以下の情報が登録されている。
・イベントＩＤ（本人確認に用いる情報）
・承認対象権限ＩＤ（承認対象情報、要求可否判定に用いる情報）
ユーザの本人確認では、ユーザを識別可能な生体情報を取得したうえで、予めユーザＤＢに登録されているユーザに関する情報を用いて生体認証を行う。
この変形例では、ユーザ端末１０に表示される二次元コードには、以下の情報が含まれる。
・チケットＩＤ（本人確認に用いる情報）
・チェックディジット（本人確認に用いる情報）
・ユーザＩＤ（権限確認に用いる情報）
そして、検札装置３０には、予め、以下の情報が登録されている。
・イベントＩＤ（本人確認に用いる情報）
・承認対象権限ＩＤ（承認対象情報、要求可否判定に用いる情報）
【0159】
まずシステム１では、イベント会場への入場を要求するユーザに対して、入場ゲートでの検札処理を行う。この際、検札装置３０は、来場者の顔画像と、来場者が提示するチケット券面に表示された二次元コードを撮影する。これにより、検札装置３０は、以下の情報を取得する。
・ユーザの生体情報（撮影した来場者の顔画像）
・チケットＩＤ（撮影した二次元コードに含まれた値）
・チェックディジット（撮影した二次元コードに含まれた値）
・ユーザＩＤ（撮影した二次元コードに含まれた値）
・ユーザの生体情報（撮影した来場者の顔画像）
・チケットＩＤ（撮影した二次元コードに含まれた値）
・チェックディジット（撮影した二次元コードに含まれた値）
・ユーザＩＤ（撮影した二次元コードに含まれた値）
【0160】
次に、検札装置３０はユーザの本人認証を行う。検札装置３０のプロセッサ３２は、取得した顔画像から、ユーザの生体情報の特徴量を抽出する。プロセッサ３２は、抽出した特徴量と、取得したチケットＩＤと、予め登録されたイベントＩＤと、を用いた演算を行うことで、本人確認に用いるチェック用データを算出する。
プロセッサ３２は、二次元コードを撮影することで取得したチェックディジットの値と、算出したチェック用データの値と、を用いた本人確認の判定を行う。チェックディジットの値とチェック用データの値とが、予め設定された基準に沿って類似すると判断された場合には、プロセッサ３２は、本人確認をＯＫとする出力を行う。一方、チェックディジットの値とチェック用データの値とが、予め設定された基準に沿って類似しないと判断されたプロセッサ３２は、本人確認をＮＧとする出力を行い、来場者の要求（入場）は拒絶される。
プロセッサ３２は、二次元コードを撮影することで取得したチェックディジットの値と、算出したチェック用データの値と、を用いた本人確認の判定を行う。チェックディジットの値とチェック用データの値とが、予め設定された基準に沿って類似すると判断された場合には、プロセッサ３２は、本人確認をＯＫとする出力を行う。一方、チェックディジットの値とチェック用データの値とが、予め設定された基準に沿って類似しないと判断されたプロセッサ３２は、本人確認をＮＧとする出力を行い、来場者の要求（入場）は拒絶される。
【0161】
すなわち、この説明における本人確認では、チェックディジットには、当該チェックディジットが記録されるチケットのチケットＩＤと、当該チケットの所有者であるユーザについて、ユーザＤＢに登録されたユーザＩＤに紐づく特徴量と、当該チケットが使用されるイベントのイベントＩＤと、を用いて作成された値が記録されている。このため、当該チケットの所有者として記録されているユーザ以外のユーザが使用した場合には、本人確認においてＮＧの判定を行うことができる。
【0162】
次に、検札装置３０は、本人確認がＯＫとなった場合において、撮影した二次元コードに含まれていたユーザＩＤを特定することで、来場者のユーザＩＤの特定の処理（図１４に示すステップＳ３３２）を実行する。その後、検札装置３０は、来場者であるユーザが保有するチケットの特定の処理（図１４に示すステップＳ３３３）を行う。その後の処理は、図１４に沿って行われる。
【0163】
このような構成を採用すれば、チェックディジットを用いた生体認証により本人確認を行ったうえで、同時に取得したユーザＩＤにより、ユーザが保有するチケットの権限の判定を行うことができる。これにより、本人へのなりすまし行為による不正利用を効果的に抑制することができる。また、本人確認のための生体情報の取得等の一連の処理により、ユーザの主体情報を取得できるので、検札処理に要する時間を削減することができる。
なお、本人確認として行われる生体認証については、前述したチェックディジットと用いた処理に限られず、予めユーザＤＢに登録されているユーザに関する情報を用いた生体認証であれば、その他の態様を採用してもよい。
なお、本人確認として行われる生体認証については、前述したチェックディジットと用いた処理に限られず、予めユーザＤＢに登録されているユーザに関する情報を用いた生体認証であれば、その他の態様を採用してもよい。
【0164】
（６－４）変形例４（承認対象情報がチケットＩＤ）
次に、変形例４に係るシステム１について説明する。図１８は変形例４に係るシステム１の処理全体の流れを説明する図である。
次に、変形例４に係るシステム１について説明する。図１８は変形例４に係るシステム１の処理全体の流れを説明する図である。
【0165】
図１８に示すように、変形例４に係るシステム１では、チケットの権限を識別可能な権限情報として、前述した権限ＩＤではなく、チケットを識別するチケットＩＤが用いられる。すなわち、この変形例では、承認対象情報として、承認対象権限ＩＤではなく、承認対象チケットＩＤを用いて、ユーザが保有するチケットの権限の判定が行われる。
【0166】
図１８に示すように、変形例４に係るシステム１では、検札装置３０に、承認対象情報として、チケットＩＤ（承認対象チケットＩＤ）が登録されている。検札装置３０は、ユーザが保有するチケットＩＤと、承認対象チケットＩＤとを比較して、ユーザが保有するチケットの権限の判定を行う。
【0167】
承認対象情報となる承認対象チケットＩＤは、例えば、承認対象権限ＩＤから設定することができる。具体的には、特定の検札装置３０が承認するべき承認対象権限ＩＤは、当該検札装置が配備される検札シーンに応じて設定される。次に、承認対象権限ＩＤに該当するチケットのチケットＩＤは、チケットＤＢを参照することで特定することができる。このようにして、承認対象情報となる承認対象チケットＩＤを設定することができる。
【0168】
変形例４に係るシステム１の処理としては、まず、検札装置３０のプロセッサ３２は、来場者が提示する二次元コードを撮影する（図１４に示すステップＳ３３１）。
ステップＳ３３１の後に、プロセッサ３２は、撮影した二次元コードを識別することで、二次元コードに記録されたユーザＩＤの特定を行う（図１４に示すステップＳ３３２）。
ステップＳ３３１の後に、プロセッサ３２は、撮影した二次元コードを識別することで、二次元コードに記録されたユーザＩＤの特定を行う（図１４に示すステップＳ３３２）。
【0169】
ステップＳ３３２の後に、検札装置３０は、ユーザが保有するチケットを特定する（ステップＳ３３３）。
具体的には、検札装置３０のプロセッサ３２は、ステップＳ３３２において特定したユーザＩＤについて、チケット管理サーバ２０に対して照会することで、当該ユーザＩＤに該当するユーザが保有するチケットのチケットＩＤを特定する。この際、チケット管理サーバ２０のプロセッサ２２は、保有ＤＢを参照して、特定したユーザＩＤに紐づけられたチケットＩＤを抽出する。これにより、検札対象である来場者が保有するチケットが特定される。
具体的には、検札装置３０のプロセッサ３２は、ステップＳ３３２において特定したユーザＩＤについて、チケット管理サーバ２０に対して照会することで、当該ユーザＩＤに該当するユーザが保有するチケットのチケットＩＤを特定する。この際、チケット管理サーバ２０のプロセッサ２２は、保有ＤＢを参照して、特定したユーザＩＤに紐づけられたチケットＩＤを抽出する。これにより、検札対象である来場者が保有するチケットが特定される。
【0170】
ステップＳ３３３の後に、検札装置３０は、ステップＳ３３３において特定した、検札対象である来場者が保有するチケットのチケットＩＤと、予め登録された承認対象チケットＩＤと、が一致するかどうかを判定する（図１４に示すステップＳ３３５）。すなわち、この変形例では、チケットの権限の確認（図１４に示すステップＳ３３４）は、ユーザが保有するチケットＩＤの特定（ステップＳ３３３）において同時に行われることとなる。
【0171】
そして、ユーザが保有するチケットのチケットＩＤが、承認対象チケットＩＤと一致する場合には、検札装置３０は、ユーザに対して、ユーザからの要求を許可する。図１８に示す入場チケットへの検札の場面では、検札装置３０は、ユーザに対してイベント会場への入場を承認する。
【0172】
一方、ユーザが保有するチケットのチケットＩＤが、承認対象チケットＩＤと一致しない場合、または、ユーザがチケットを保有していない場合には、検札装置３０は、ユーザに対して要求を拒絶する。図１８に示す来場チケットへの検札の場面では、検札装置３０は、ユーザに対してイベント会場への入場を拒絶する。
【0173】
（６－５）変形例５（承認対象情報がユーザＩＤ）
次に、変形例５に係るシステム１について説明する。図１９は変形例５に係るシステム１の処理全体の流れを説明する図である。
次に、変形例５に係るシステム１について説明する。図１９は変形例５に係るシステム１の処理全体の流れを説明する図である。
【0174】
図１９に示すように、変形例５に係るシステム１では、チケットの権限を識別可能な権限情報として、前述した権限ＩＤ又はチケットＩＤではなく、ユーザＩＤが用いられる。すなわち、この変形例では、承認対象情報として、承認対象権限ＩＤではなく、承認対象ユーザＩＤを用いて、ユーザが保有するチケットの権限の判定が行われる。
【0175】
変形例５に係るシステム１では、検札装置３０に、承認対象情報として、ユーザＩＤ（承認対象ユーザＩＤ）が登録されている。検札装置３０は、ユーザのユーザＩＤと、承認対象ユーザＩＤと、を比較して、ユーザが保有するチケットの権限の判定を行う。
【0176】
承認対象情報となる承認対象ユーザＩＤは、承認対象権限ＩＤから設定することができる。具体的には、特定の検札装置３０が承認するべき承認対象権限ＩＤは、当該検札装置が配備される検札シーンにより設定される。次に、承認対象権限ＩＤに該当するチケットのチケットＩＤは、チケットＤＢを参照することで特定することができる。そして、承認するべきチケットのチケットＩＤの保有者は、保有ＤＢを参照することで特定することができる。このようにして、承認対象情報となるユーザＩＤを設定することができる。
【0177】
変形例５に係るシステム１の処理としては、まず、検札装置３０のプロセッサ３２は、主体情報の取得として、来場者の顔画像を撮影する（図１４に示すステップＳ３３１）。なお、来場者の顔画像の撮影に代えて、検札装置３０は、ユーザＩＤが記録された二次元コードを撮影してもよい。
ステップＳ３３１の後に、プロセッサ３２は、撮影した顔画像への画像処理により、来場者の生体情報の特徴量を抽出し、チケット管理サーバ２０にユーザの照会を行うことで、ユーザＩＤの特定を行う（図１４に示すステップＳ３３２）。チケット管理サーバ２０は、ユーザＤＢを参照して、検札装置３０から送信された生体情報からユーザを特定し、特定したユーザＩＤを検札装置３０に送信する。
ステップＳ３３１の後に、プロセッサ３２は、撮影した顔画像への画像処理により、来場者の生体情報の特徴量を抽出し、チケット管理サーバ２０にユーザの照会を行うことで、ユーザＩＤの特定を行う（図１４に示すステップＳ３３２）。チケット管理サーバ２０は、ユーザＤＢを参照して、検札装置３０から送信された生体情報からユーザを特定し、特定したユーザＩＤを検札装置３０に送信する。
【0178】
ステップＳ３３２の後に、検札装置３０は、ステップＳ３３２において特定した、来場者のユーザＩＤと、予め登録された承認対象ユーザＩＤと、が一致するかどうかを判定し、承認可否の判定を行う（図１４に示すステップＳ３３５）。すなわち、変形例５に係るシステム１では、ユーザを特定する処理（ステップＳ３３２）により、チケットの権限の確認（図１４に示すステップＳ３３４）が同時に行われたこととなる。
【0179】
そして、来場者のユーザＩＤが、承認対象ユーザＩＤと一致する場合には、検札装置３０は、ユーザに対して、ユーザからの要求を許可する。図１９に示す入場チケットへの検札の場面では、検札装置３０は、ユーザに対してイベント会場への入場を承認する。
一方、来場者のユーザＩＤが、承認対象ユーザＩＤと一致しない場合には、検札装置３０は、ユーザに対して要求を拒絶する。図１９に示す来場チケットへの検札の場面では、検札装置３０は、ユーザに対してイベント会場への入場を拒絶する。
一方、来場者のユーザＩＤが、承認対象ユーザＩＤと一致しない場合には、検札装置３０は、ユーザに対して要求を拒絶する。図１９に示す来場チケットへの検札の場面では、検札装置３０は、ユーザに対してイベント会場への入場を拒絶する。
【0180】
（６－６）変形例６（一つの承認対象情報が複数の検札装置に登録）
次に、変形例６に係るシステム１について説明する。図２０は変形例６に係るシステム１の検札装置３０が保有する承認対象情報を説明する図である。
次に、変形例６に係るシステム１について説明する。図２０は変形例６に係るシステム１の検札装置３０が保有する承認対象情報を説明する図である。
【0181】
図２０に示すように、変形例６に係るシステム１では、一つの承認対象情報が、複数の検札装置３０に登録されている構成を備えている。
図２０に示すように、例えばイベント会場内において、利用料金の違いなどに応じて、利用エリアに等級が設定されていることがある。この場合には、全ての来場者は会場の入場ゲートから入場したうえで、自身が所有するチケットが該当する利用エリアに進入する。そして、会場内には個別ゲートが設けられている。図示の例では、入場ゲートの他に、以下の３つの個別ゲートが設けられている。
・ＶＩＰエリアゲート
・Ｓ、Ａエリア共通ゲート
・Ｂ、Ｃエリア共通ゲート
図２０に示すように、例えばイベント会場内において、利用料金の違いなどに応じて、利用エリアに等級が設定されていることがある。この場合には、全ての来場者は会場の入場ゲートから入場したうえで、自身が所有するチケットが該当する利用エリアに進入する。そして、会場内には個別ゲートが設けられている。図示の例では、入場ゲートの他に、以下の３つの個別ゲートが設けられている。
・ＶＩＰエリアゲート
・Ｓ、Ａエリア共通ゲート
・Ｂ、Ｃエリア共通ゲート
【0182】
そして変形例６に係るシステム１では、図２０に示すように、一つのイベントにおいて用いられる複数の検札装置３０について、配備される検札場面ごとに、異なる承認対象情報が登録され、検札装置３０同士で重複することが許容されている。図示の例では、以下の４つの検札装置３０が、それぞれのゲートに配備されている。
・第１の検札装置３０Ａ（会場の入場ゲートに配備）
・第２の検札装置３０Ｂ（ＶＩＰエリアゲートに配備）
・第３の検札装置３０Ｃ（Ｓ、Ａエリア共通ゲートに配備）
・第４の検札装置３０Ｄ（Ｂ、Ｃエリア共通ゲートに配備）
・第１の検札装置３０Ａ（会場の入場ゲートに配備）
・第２の検札装置３０Ｂ（ＶＩＰエリアゲートに配備）
・第３の検札装置３０Ｃ（Ｓ、Ａエリア共通ゲートに配備）
・第４の検札装置３０Ｄ（Ｂ、Ｃエリア共通ゲートに配備）
【0183】
この場合には、会場入場ゲートに配備される第１の検札装置３０Ａは、全ての来場者の通過を承認する必要がある。このため、検札装置３０Ａには、承認対象権限ＩＤとして、当該イベントの全てのチケットに関する権限ＩＤが、承認対象情報（承認対象権限ＩＤ）として登録されている。
【0184】
次に、ＶＩＰエリアゲートに配備される第２の検札装置３０Ｂは、来場者のうち、ＶＩＰエリアチケットに該当するチケットの保有者のみの通過を承認する。このため、検札装置３０Ｂには、ＶＩＰエリアチケットに関する権限ＩＤが、承認対象情報（承認対象権限ＩＤ）として登録されている。
【0185】
次に、Ｓ、Ａエリア共通ゲートに配備される第３の検札装置３０Ｃは、来場者のうち、Ｓエリア又はＡエリアに該当するチケットの保有者のみの通過を承認する。このため、検札装置３０Ｃには、ＳエリアチケットおよびＡエリアチケットに関する権限ＩＤが、承認対象情報（承認対象権限ＩＤ）として登録されている。
【0186】
次に、Ｂ、Ｃエリア共通ゲートに配備される第４の検札装置３０Ｄは、来場者のうち、Ｂエリア又はＣエリアに該当するチケットの保有者のみの通過を承認する。このため、検札装置３０Ｄには、ＢエリアチケットおよびＣエリアチケットに関する権限ＩＤが、承認対象情報（承認対象権限ＩＤ）として登録されている。
【0187】
（７）その他の変形例
システム１のその他の変形例について以下に説明する。
記憶装置１１は、ネットワークＮＷを介して、ユーザ端末１０と接続されてもよい。記憶装置２１は、ネットワークＮＷを介して、チケット管理サーバ２０と接続されてもよい。記憶装置３１は、ネットワークＮＷを介して、検札装置３０と接続されてもよい。
システム１のその他の変形例について以下に説明する。
記憶装置１１は、ネットワークＮＷを介して、ユーザ端末１０と接続されてもよい。記憶装置２１は、ネットワークＮＷを介して、チケット管理サーバ２０と接続されてもよい。記憶装置３１は、ネットワークＮＷを介して、検札装置３０と接続されてもよい。
【0188】
上記の検札処理は、図１４のように検札装置３０が単独で行ってもよいし、検札装置３０と他の装置（例えばチケット管理サーバ２０）とが協働して行ってもよい。すなわち、チケット管理サーバ２０に記憶された各ＤＢの情報の少なくとも一部を、予め検札装置３０の記憶装置３１に記憶されることで、検札装置３０が単独で処理を行うことができる。
【0189】
また、上記実施形態では、使用者がイベント会場に来場する態様について説明した。しかしながら、例えばイベントがオンラインイベントの場合には、使用者がユーザ端末１０に表示される視聴ボタンを押下して、要求されるアカウント情報の入力を行うことで、図１４に示す主体情報の取得（ステップＳ３３１）が実行される。この場合には、ユーザが使用する端末は、検札装置３０としての機能を実現してもよい。
【0190】
すなわち、チケットが、情報通信を介して提供されるイベントに関するものである場合には、チケットを用いてユーザが情報通信の提供を受けることをチケットの使用と呼び、チケットの使用の検出は、情報通信の提供の開始により実行される。
また、検札装置３０は、要求可否の判定（図１４に示すステップＳ３３５）に代えて、視聴可否の判定を行う。
また、検札装置３０は、要求可否の判定（図１４に示すステップＳ３３５）に代えて、視聴可否の判定を行う。
【0191】
また、上記実施形態では、チケット管理サーバ２０が、チケット情報をユーザ端末１０に送信する例を示した。しかしながら、チケット管理サーバ２０は、チケット情報の代わりに、当該チケット情報の保存されたリソースを参照するためのリソース情報（例えば、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ））をユーザ端末１０へ送信してもよい。来場者は、自らのユーザ端末１０によってリソース情報の示すリソースにアクセスすることで、当該ユーザ端末１０のディスプレイにチケット情報を表示させることができる。
また、システム１では、チケット情報のユーザ端末１０への送信を省略してもよい。
また、システム１では、チケット情報のユーザ端末１０への送信を省略してもよい。
【0192】
上記の説明では、チケットの利用条件および付与条件として、ユーザの属性に関する情報を用いる例を示したが、この限りではない。チケットの利用条件および付与条件としては、例えば以下が挙げられる。
（１）利用条件として
・開場後からイベント終了時までにおいて利用可能（時期的条件）
・所定の場所のブースにおいて利用可能（位置的条件）
（２）付与条件として
・イベント開始３０分前までの利用で付与可能（時期的条件）
・ＶＩＰルームでの検札を通過した場合に付与可能（位置的条件）
（１）利用条件として
・開場後からイベント終了時までにおいて利用可能（時期的条件）
・所定の場所のブースにおいて利用可能（位置的条件）
（２）付与条件として
・イベント開始３０分前までの利用で付与可能（時期的条件）
・ＶＩＰルームでの検札を通過した場合に付与可能（位置的条件）
【0193】
また、チケットの利用条件および付与条件としては、ユーザの行動態様に対して所定の条件を設定してもよい。行動条件となるユーザの行動態様には、例えば、以下のいずれかが含まれ得る。
・ユーザのイベント会場に来場時刻、退場時刻、来場の順番
・自身のＳＮＳアカウントでのイベントに関する発信
・当該イベントに関連するグッズの購入実績
・当該イベントに関連するイベントへの過去の参加実績
・当該イベント会場への来場時刻
・当該イベント会場からの退場時刻
・当該イベントへの同伴者の有無
・ユーザのイベント会場に来場時刻、退場時刻、来場の順番
・自身のＳＮＳアカウントでのイベントに関する発信
・当該イベントに関連するグッズの購入実績
・当該イベントに関連するイベントへの過去の参加実績
・当該イベント会場への来場時刻
・当該イベント会場からの退場時刻
・当該イベントへの同伴者の有無
【0194】
またシステム１では、デジタルコンテンツの所有者の情報がブロックチェーン上に記録された非代替性トークンであるＮＦＴを、本発明のチケットとして管理してもよい。すなわち、チケットとして発行されたＮＦＴを保有しているユーザが、当該ＮＦＴに設定された何らかの特典を付与される権限を有していることとなる。
【0195】
また、システム１では、チケットの検札時にこれまでの利用ステータスを、利用条件にしてもよい。具体的には、システム１は、既に利用済みのチケットについて、保有ＤＢから保有記録を削除することで、その後の再利用において、ユーザＩＤと紐づいたチケットＩＤが確認できなくすることにより、既に利用済みのチケットを再度利用できないようにすることができる。
【0196】
また、システム１では、検札装置３０は、チケットの検札時にチェックインリストを確認することで、利用ステータスや利用回数を確認してもよい。
【0197】
また、変形例２に係るシステム１では、ユーザＩＤとイベントＩＤとを含むイベント別ユーザＩＤを用いる処理を説明したが、この限りではない。
システム１では、イベント別ユーザＩＤに代えて、ユーザＩＤと、タイムスタンプ情報と、が記録された二次元コードを用いて処理を行ってもよい。
システム１では、イベント別ユーザＩＤに代えて、ユーザＩＤと、タイムスタンプ情報と、が記録された二次元コードを用いて処理を行ってもよい。
【0198】
また、上記の説明では、ユーザ端末１０に主体情報が含まれる二次元コードを表示し、当該二次元コードを検札装置３０により撮影する構成を示したが、この限りではない。例えばユーザ端末１０と、検札装置３０と、の間で行われる近距離無線通信により、ユーザＩＤ、ユーザが保有するチケットＩＤ、イベント別ユーザＩＤ、および生体情報などのユーザの主体情報、並びに、本人確認に用いられるチェックディジットを含む各種の情報をユーザ端末１０から検札装置３０に対して送信することで、検札装置３０による各種の情報の取得が行われてもよい。
【0199】
また、権限ＤＢに記録された利用条件については、権限ＤＢ以外の領域に記録されてもよい。例えば、チケットＤＢに、チケットＩＤに対応するチケットの利用条件が設定されていてもよいし、イベントＤＢに、イベントＩＤに対応するイベントへの参加条件が設定されていてもよい。
【0200】
以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態および変形例は、処理が矛盾しない範囲において、それぞれの一部の処理を組合せ可能、またはその一部を省略可能である。
【0201】
（８）付記
実施形態および変形例で説明した事項を、以下に付記する。
実施形態および変形例で説明した事項を、以下に付記する。
【0202】
（付記１）
プロセッサを備え、チケットを管理するシステムの処理に用いられるプログラムであって、
プログラムは、プロセッサに、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップ（ステップＳ３３１）と、
主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定するステップ（ステップＳ３３４）と、
特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定するステップ（ステップＳ３３５）と、を実行させるプログラム。
プロセッサを備え、チケットを管理するシステムの処理に用いられるプログラムであって、
プログラムは、プロセッサに、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップ（ステップＳ３３１）と、
主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定するステップ（ステップＳ３３４）と、
特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定するステップ（ステップＳ３３５）と、を実行させるプログラム。
【0203】
（付記２）
主体情報を取得するステップ（ステップＳ３３１）では、
ユーザを識別可能な生体情報を取得するステップと、
取得した生体情報を用いて、ユーザデータベースを参照して、当該生体情報に対応するユーザのユーザＩＤを特定するステップと、を実行させる付記１に記載のプログラム。
主体情報を取得するステップ（ステップＳ３３１）では、
ユーザを識別可能な生体情報を取得するステップと、
取得した生体情報を用いて、ユーザデータベースを参照して、当該生体情報に対応するユーザのユーザＩＤを特定するステップと、を実行させる付記１に記載のプログラム。
【0204】
（付記３）
主体情報は、ユーザのユーザＩＤおよびイベントを識別するイベントＩＤにより作成された当該イベントにおいて共通する当該ユーザ固有のイベント別ユーザＩＤを含み、
主体情報を取得するステップ（ステップＳ３３１）では、イベント別ユーザＩＤが記録された二次元コードを撮影することで、イベント別ユーザＩＤを取得する、付記１に記載のプログラム。
主体情報は、ユーザのユーザＩＤおよびイベントを識別するイベントＩＤにより作成された当該イベントにおいて共通する当該ユーザ固有のイベント別ユーザＩＤを含み、
主体情報を取得するステップ（ステップＳ３３１）では、イベント別ユーザＩＤが記録された二次元コードを撮影することで、イベント別ユーザＩＤを取得する、付記１に記載のプログラム。
【0205】
（付記４）
権限情報は、チケットを識別するチケットＩＤであり、
権限情報を特定するステップ（ステップＳ３３１）では、取得した主体情報と紐づけられたチケットのチケットＩＤを特定する、付記１に記載のプログラム。
権限情報は、チケットを識別するチケットＩＤであり、
権限情報を特定するステップ（ステップＳ３３１）では、取得した主体情報と紐づけられたチケットのチケットＩＤを特定する、付記１に記載のプログラム。
【0206】
（付記５）
権限情報は、チケットの権限について識別可能に設定された権限ＩＤであり、
権限情報を特定するステップ（ステップＳ３３４）では、取得した主体情報と紐づけられたチケットのチケットＩＤを特定するステップと、
特定したチケットＩＤと紐づけられた権限ＩＤを特定するステップと、を実行させる、付記１に記載のプログラム。
権限情報は、チケットの権限について識別可能に設定された権限ＩＤであり、
権限情報を特定するステップ（ステップＳ３３４）では、取得した主体情報と紐づけられたチケットのチケットＩＤを特定するステップと、
特定したチケットＩＤと紐づけられた権限ＩＤを特定するステップと、を実行させる、付記１に記載のプログラム。
【0207】
（付記６）
承認の可否を判定するステップ（ステップＳ３３５）では、
チケットの利用条件を参照して、要求の可否を判定する、付記１に記載のプログラム。
承認の可否を判定するステップ（ステップＳ３３５）では、
チケットの利用条件を参照して、要求の可否を判定する、付記１に記載のプログラム。
【0208】
（付記７）
権限情報を特定するステップに先立って（ステップＳ３３４）において、
ユーザを識別可能な生体情報を取得したうえで、予め登録されているユーザ情報を参照して、ユーザの本人確認を行うステップを実行させる、
付記１に記載のプログラム。
権限情報を特定するステップに先立って（ステップＳ３３４）において、
ユーザを識別可能な生体情報を取得したうえで、予め登録されているユーザ情報を参照して、ユーザの本人確認を行うステップを実行させる、
付記１に記載のプログラム。
【0209】
（付記８）
プロセッサを備え、チケットを管理するシステムの処理に用いられる方法であって、
方法は、プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップ（ステップＳ３３１）と、
主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定するステップ（ステップＳ３３４）と、
特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定するステップ（ステップＳ３３５）と、を実行する方法。
プロセッサを備え、チケットを管理するシステムの処理に用いられる方法であって、
方法は、プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得するステップ（ステップＳ３３１）と、
主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定するステップ（ステップＳ３３４）と、
特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定するステップ（ステップＳ３３５）と、を実行する方法。
【0210】
（付記９）
プロセッサを備え、チケットを管理するシステムであって、
システムは、プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得する手段と、
主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定する手段と、
特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定する手段と、を備えるシステム。
プロセッサを備え、チケットを管理するシステムであって、
システムは、プロセッサが、
ユーザからの所定の要求に応答して、当該ユーザを識別可能な主体情報を取得する手段と、
主体情報に紐づけられたユーザが保有するチケットの権限を特定可能な権限情報を特定する手段と、
特定した権限情報が、所定の要求に対して予め登録された承認対象情報と一致するかどうかにより、ユーザからの所定の要求についての承認の可否を判定する手段と、を備えるシステム。
【符号の説明】
【0211】
１ ：チケット管理システム
１０ ：ユーザ端末
１１ ：記憶装置
１２ ：プロセッサ
１３ ：入出力インタフェース
１４ ：通信インタフェース
２０ ：チケット管理サーバ
２１ ：記憶装置
２２ ：プロセッサ
２３ ：入出力インタフェース
２４ ：通信インタフェース
３０ ：検札装置
３１ ：記憶装置
３２ ：プロセッサ
３３ ：入出力インタフェース
３４ ：通信インタフェース
１０ ：ユーザ端末
１１ ：記憶装置
１２ ：プロセッサ
１３ ：入出力インタフェース
１４ ：通信インタフェース
２０ ：チケット管理サーバ
２１ ：記憶装置
２２ ：プロセッサ
２３ ：入出力インタフェース
２４ ：通信インタフェース
３０ ：検札装置
３１ ：記憶装置
３２ ：プロセッサ
３３ ：入出力インタフェース
３４ ：通信インタフェース
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
