特許 7691202 管理装置、管理方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2025-06-03

(45)【発行日】2025-06-11

(54)【発明の名称】管理装置、管理方法及びプログラム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20250604BHJP

【ＦＩ】

G06Q50/10

【請求項の数】 8

(21)【出願番号】P 2024165457

(22)【出願日】2024-09-24

【審査請求日】2025-02-19

【早期審査対象出願】

(73)【特許権者】

【識別番号】522313639

【氏名又は名称】株式会社Ｋｕｌｔｕｒｅ

(73)【特許権者】

【識別番号】397043259

【氏名又は名称】株式会社アミューズ

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】白石 耕介

(72)【発明者】

【氏名】江戸原 允文

(72)【発明者】

【氏名】阿部 祐輝

(72)【発明者】

【氏名】藤井 達也

(72)【発明者】

【氏名】小南 勇介

【審査官】日比野 可奈子

(56)【参考文献】

【文献】特開２０１４－０９６１３７（ＪＰ，Ａ）

【文献】特開２００４－２６０３９４（ＪＰ，Ａ）

【文献】国際公開第２０２４／１２７７０７（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ１０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

開催されるイベントに関するイベント開催情報を記憶する記憶部と、
出演者及びイベントの単位で開設されるコミュニケーションツールであるチャネルを管理する管理部と、
ユーザが所有する前記イベントのチケットに関するチケット情報を取得し、取得したチケット情報と前記イベント開催情報とを突合することで、前記ユーザがチケットを所有していることの確認を行う所有確認部と、
を有し、
前記管理部は、前記イベントのチケットを所有していることが確認されたユーザ及び前記イベントの出演者に対し、前記チャネルへの投稿及び前記チャネルの投稿の閲覧を許可し、
前記イベント開催情報には、前記イベントを一意に特定する特定情報が含まれており、
前記所有確認部は、
前記ユーザが所有しているチケットの画像データを取得し、
前記画像データから読み取った前記チケット情報に含まれる前記イベントを一意に特定するイベント特定情報と、前記イベント開催情報とを突合し、
前記イベント特定情報が、前記イベント開催情報に含まれる特定情報と一致する場合に、前記ユーザは前記イベントのチケットを所有していると判断する、
管理装置。

【請求項2】

前記所有確認部は、更に、
前記チケット情報に含まれる、前記イベントの座席を一意に特定する座席情報が、他のユーザから取得したチケットの画像データから特定された前記座席情報と同一ではない場合、前記ユーザは前記イベントのチケットを所有していると判断し、
前記チケット情報に含まれる、前記イベントにおける座席を一意に特定する座席情報が、他のユーザから取得したチケットの画像データから特定された前記座席情報と同一である場合、前記ユーザは前記イベントのチケットを所有していないと判断する、
請求項１に記載の管理装置。

【請求項3】

前記チャネルの投稿には、前記イベントのチケットを所有していることが確認されたユーザ及び前記イベントの出演者を含む限定されたユーザのみが閲覧可能な限定投稿と、閲覧が制限されない通常投稿とが含まれており、
前記管理部は、前記限定されたユーザに対し、前記通常投稿及び前記限定投稿の閲覧を許可し、前記限定されたユーザ以外のユーザに対し、前記通常投稿の閲覧を許可するが前記限定投稿の閲覧は許可しない、
請求項１に記載の管理装置。

【請求項4】

前記管理部は、前記限定されたユーザに対し、前記チャネルに対する通常投稿の投稿及び限定投稿の投稿を許可し、前記限定されたユーザ以外のユーザに対し、前記チャネルに対する通常投稿の投稿及び限定投稿の投稿を許可しない、
請求項３に記載の管理装置。

【請求項5】

前記チャネルの通常投稿には、前記限定されたユーザが投稿可能な、特別な通常投稿が含まれており、
前記管理部は、前記限定されたユーザ及び前記限定されたユーザ以外のユーザに対し、前記特別な通常投稿の閲覧を許可する、
請求項３に記載の管理装置。

【請求項6】

前記イベントのチケットを所有していると判断されたユーザのブロックチェーンウォレットに対し、前記イベントに参加したことに関する情報を含むＮＦＴを付与する、付与部、を有する、
請求項１に記載の管理装置。

【請求項7】

開催されるイベントに関するイベント開催情報を記憶部に記憶するステップと、
出演者及びイベントの単位で開設されるコミュニケーションツールであるチャネルを管理するステップと、
ユーザが所有する前記イベントのチケットに関するチケット情報を取得し、取得したチケット情報と前記イベント開催情報とを突合することで、前記ユーザがチケットを所有していることの確認を行うステップと、
を含み、
前記管理するステップは、前記イベントのチケットを所有していることが確認されたユーザ及び前記イベントの出演者に対し、前記チャネルへの投稿及び前記チャネルの投稿の閲覧を許可し、
前記イベント開催情報には、前記イベントを一意に特定する特定情報が含まれており、
前記確認するステップは、
前記ユーザが所有しているチケットの画像データを取得し、
前記画像データから読み取った前記チケット情報に含まれる前記イベントを一意に特定するイベント特定情報と、前記イベント開催情報とを突合し、
前記イベント特定情報が、前記イベント開催情報に含まれる特定情報と一致する場合に、前記ユーザは前記イベントのチケットを所有していると判断する、
管理装置が行う管理方法。

【請求項8】

コンピュータに、
開催されるイベントに関するイベント開催情報を記憶部に記憶するステップと、
出演者及びイベントの単位で開設されるコミュニケーションツールであるチャネルを管理するステップと、
ユーザが所有する前記イベントのチケットに関するチケット情報を取得し、取得したチケット情報と前記イベント開催情報とを突合することで、前記ユーザがチケットを所有していることの確認を行うステップと、
を実行させ、
前記管理するステップは、前記イベントのチケットを所有していることが確認されたユーザ及び前記イベントの出演者に対し、前記チャネルへの投稿及び前記チャネルの投稿の閲覧を許可し、
前記イベント開催情報には、前記イベントを一意に特定する特定情報が含まれており、
前記確認するステップは、
前記ユーザが所有しているチケットの画像データを取得し、
前記画像データから読み取った前記チケット情報に含まれる前記イベントを一意に特定するイベント特定情報と、前記イベント開催情報とを突合し、
前記イベント特定情報が、前記イベント開催情報に含まれる特定情報と一致する場合に、前記ユーザは前記イベントのチケットを所有していると判断する、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、管理装置、管理方法及びプログラムに関する。

【背景技術】

【0002】

現在、ライブやスポーツなど、現実の会場を用いた様々なイベントが開催されている。また、イベントやコンサート等のチケットを発券する際、チケットの受け取りを容易にすることが可能なチケット発券システムが開示されている（特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１７－０２７４４１号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ユーザは、イベントのチケットを購入してイベントに参加することで、出演者を身近に感じることができる。このようなリアルな体験は、実際にイベントに参加するユーザのみが得られることになる。また、イベントに参加するユーザが更に出演者を身近に感じることができ、ユーザ間の距離及びユーザと出演者との距離を近づけるようにするために、イベントに参加するユーザ間及びユーザと出演者が直接コミュニケーションすることを可能とする仕組みが求められている。

【0005】

そこで、本発明は、イベントに参加するユーザ間及びユーザと出演者とが直接コミュニケーションを取ることを可能とする技術を提供することを目的とする。

【課題を解決するための手段】

【0006】

本発明の一態様に係る管理装置は、開催されるイベントに関するイベント開催情報を記憶する記憶部と、出演者及びイベントの単位で開設されるコミュニケーションツールであるチャネルを管理する管理部と、ユーザが所有する前記イベントのチケットに関するチケット情報を取得し、取得したチケット情報と前記イベント開催情報とを突合することで、前記ユーザがチケットを所有していることの確認を行う所有確認部と、を有し、前記管理部は、前記イベントのチケットを所有していることが確認されたユーザ及び前記イベントの出演者に対し、前記チャネルへの投稿及び前記チャネルの投稿の閲覧を許可する。

【発明の効果】

【0007】

本発明によれば、イベントに参加するユーザ間及びユーザと出演者とが直接コミュニケーションを取ることが可能になる。

【図面の簡単な説明】

【0008】

【図1】本実施形態に係るコミュニケーション管理システムの一例を示す図である。

【図2】管理サーバのハードウェア構成例を示す図である。

【図3】管理サーバの機能ブロック構成例を示す図である。

【図4】イベント管理ＤＢの一例を示す図である。

【図5】アカウント管理ＤＢの一例を示す図である。

【図6】チケット管理ＤＢの一例を示す図である。

【図7】チャネル管理ＤＢの一例を示す図である。

【図8】投稿管理ＤＢの一例を示す図である。

【図9】管理サーバが行う処理手順の一例を示す図である。

【図10】管理サーバが行う処理手順の一例を示す図である。

【図11】チケット登録を行う画面の一例を示す図である。

【図12】投稿表示画面の一例を示す図である。

【発明を実施するための形態】

【0009】

添付図面を参照して、本発明の実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

【0010】

＜システム構成＞
図１は、本実施形態に係るコミュニケーション管理システム１の一例を示す図である。コミュニケーション管理システム１は、管理サーバ１０（管理装置ともいう）と、１以上の端末２０と、ブロックチェーンネットワーク３０とを含む。管理サーバ１０と、１以上の端末２０と、ブロックチェーンネットワーク３０とは、無線又は有線の通信ネットワークＮを介して接続され、相互に通信を行うことができる。

【0011】

コミュニケーション管理システム１は、イベントの出演者とチケットを購入してイベントに参加する参加者との間、及び、チケットを購入してイベントに参加する参加者の間でコミュニケーションを行うことを可能とするサービス（以下、「コミュケーションサービス」という。）を提供するシステムである。これまでも、イベントの出演者が、ＳＮＳ等で情報を発信したりすることで、参加者にメッセージを伝えることは可能であった。しかしながら、ＳＮＳで発信した情報は、イベント参加者のみならず不特定多数の人が参照可能であるため、誰宛の情報なのかわかりにくいという問題があった。また、イベント参加者がＳＮＳに書き込みを行っても、出演者のみならず不特定多数の人が参照可能であるため、イベント参加者しか知らない情報が不特定多数の人に伝わってしまうことになるという問題があった。

【0012】

そこで、本実施形態に係るコミュニケーション管理システム１は、コミュニケーションの内容が外部に公開される状態、又は、コミュニケーションの内容が外部には公開されない状態を提供しつつ、イベントに参加するためのチケットを所有していることが確認できた参加者と出演者との間、及び、チケットを所有していることが確認できた参加者の間で直接コミュニケーションを行うことを可能とする。

【0013】

以下の説明において、コミュニケーションサービスを利用する利用者をユーザという。ユーザには、イベントの出演者、関係者（出演者のマネージャーやイベントの運営を行う人）及び、出演者及び関係者以外のユーザ（以下、「一般ユーザ」という。）が含まれる。また、ユーザのうち出演者を示す場合は、ユーザ（出演者）又は出演者と記載する。ユーザのうち関係者を示す場合は、ユーザ（関係者）又は関係者と記載する。また、出演者、関係者及び一般ユーザを区別しない場合は単に「ユーザ」と記載する。

【0014】

「イベント」は、出演者が存在し、かつ、イベントのチケットを所有する人が参加可能なイベントである。具体的には、イベントには、ライブ、コンサート、公演、映画、演劇、トークショー、スポーツの試合、ｅスポーツの試合等が含まれる。なお、公演とは、特定の期間、特定の場において出演者がパフォーマンスを行うことを意味する。イベントには、実際の会場で行われるイベントに加えて、オンラインで開催されるイベントが含まれていてもよい。また、ツアーのように、同一のタイトルで複数の公演が行われる場合、イベントは、ツアーの単位であってもよいし、公演の単位であってもよい。

【0015】

また、一般ユーザのうち、イベントに参加するためのチケットを所有していることが確認できたユーザを、を「チケット所有ユーザ」といい、チケットを所有していることが確認できていないユーザ及びチケットを所有していないユーザを「チケット未所有ユーザ」という。

【0016】

本実施形態では、管理サーバ１０は、インターネット上で、出演者及びチケット所有ユーザ間の双方向コミュニケーションを実現するツール（以下、「チャネル」と言う。）を提供する。チャネルは、テキスト、画像、音声及び動画等を投稿することができるものであれば、どのようなものであってもよい。チャネルには、例えば、ソーシャルメディア、掲示板、ＳＮＳ（Social Networking Service）、及び、動画共有サービス等が含まれる。

【0017】

チャネルは、出演者及びイベントの単位で開設され、出演者、関係者及びチケット所有ユーザは、任意のテキスト、画像及び動画等を含むメッセージを投稿することができる。例えば、出演者Ａ（例えばアーティストＡ）が出演する東京で開催されるイベントＸ（例えばライブＸ）と、出演者Ｂ（例えばアーティストＢ）が出演する大阪で開催されるイベントＹ（例えばライブＹ）が存在する場合、それぞれ異なるチャネルが開設されることになる。

【0018】

なお、１つのイベントに複数の出演者が出演する場合、出演者ごとに異なるチャネルが開設されてもよいし、複数の出演者共通のチャネルが開設されてもよい。例えば、出演者Ａ、Ｂ及びＣが出演する同一のイベントＸ（例えばロックフェスティバル等）が開催される場合、イベントＸに関する出演者Ａのチャネル、イベントＸに関する出演者Ｂのチャネル、イベントＸに関する出演者Ｃのチャネルがそれぞれ開設されるようにしてもよいし、イベントＸに関する出演者Ａ～Ｃ共通のチャネルが開設されるようにしてもよい。なお、出演者が複数名のグループである場合、出演者一人ずつチャネルが開設されてもよいし、グループ単位でチャネルが開設されてもよい。また、出演者Ｘが、公演Ａ、公演Ｂ及び公演Ｃを行うツアーＹを行う場合、チャネルは、出演者Ｘ及びツアーＹのチャネルのように、出演者及びツアーの単位で１つ開設されてもよいし、出演者Ｘ及び公演Ａのチャネル、出演者Ｘ及び公演Ｂのチャネル、出演者Ｘ及び公演Ｃのチャネルのように、出演者及び公演の単位で複数開設されてもよい。

【0019】

また、チャネルが開設されるタイミング及び終了するタイミングは任意である。例えば、チャネルは、イベント開始日又はイベント開始日の所定日前に開設され、イベント終了日から所定日後に終了することとしてもよい。

【0020】

管理サーバ１０は、チャネルの提供に係る各種の処理を行う。例えば、管理サーバ１０は、チャネル上で行われるメッセージの投稿の管理、コミュニケーション管理システム１を利用するためのアカウント管理、ユーザが参照するページ（Ｗｅｂページやアプリ画面に表示させるページ）の提供等を行う。

【0021】

端末２０は、管理サーバ１０にアクセスするために用いられる端末であり、例えば、スマートフォン、タブレット端末、携帯電話機、パーソナルコンピュータ（ＰＣ）等が挙げられる。

【0022】

ブロックチェーンネットワーク３０は、ＮＦＴ（Non-Fungible Token）を管理するスマートコントラクトを実行する。管理サーバ１０は、イベントに参加したことを示すＮＦＴを発行してチケット所持ユーザに付与する。管理サーバ１０が発行するＮＦＴは、出演者及びイベントの単位（つまりチャネル単位）であってもよいし、イベント単位であってもよい。チケット所持ユーザは、ＮＦＴが付与されることで、出演者のファンであることを証明することができる。

【0023】

＜ハードウェア構成＞
図２は、管理サーバ１０のハードウェア構成例を示す図である。管理サーバ１０は、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）等のプロセッサ１１、メモリ（例えばＲＡＭ（Random Access Memory）又はＲＯＭ（Read Only Memory））、ＨＤＤ（Hard Disk Drive）及び／又はＳＳＤ（Solid State Drive）等の記憶装置１２、有線又は無線通信を行うネットワークＩＦ（Network Interface）１３、入力操作を受け付ける入力装置１４、及び情報の出力を行う出力装置１５を有する。入力装置１４は、例えば、キーボード、タッチパネル、マウス及び／又はマイク等である。出力装置１５は、例えば、ディスプレイ、タッチパネル及び／又はスピーカ等である。

【0024】

＜機能ブロック構成＞
図３は、管理サーバ１０の機能ブロック構成例を示す図である。管理サーバ１０は、記憶部１００と、管理部１０１と、所有確認部１０２と、付与部１０３と、表示制御部１０４とを含む。記憶部１００は、管理サーバ１０が備える記憶装置１２を用いて実現することができる。また、管理部１０１と、所有確認部１０２と、付与部１０３と、表示制御部１０４とは、管理サーバ１０のプロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体（Non-transitory computer-readable medium）であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢ（Universal Serial Bus）メモリ又はＣＤ－ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体であってもよい。

【0025】

記憶部１００は、開催されるイベントに関する情報（イベント開催情報）を格納するイベント管理ＤＢ１００ａと、管理サーバ１０が提供するＷｅｂサイトにアクセスするためのアカウントを管理するアカウント管理ＤＢ１００ｂと、一般ユーザが所有するチケットの情報を管理するチケット管理ＤＢ１００ｃと、開設中のチャネルに関する情報を管理するチャネル管理ＤＢ１００ｄと、チャネルに投稿されたデータ（テキスト、画像データ、動画データ等）を格納する投稿管理ＤＢ１００ｅとを記憶する。

【0026】

管理部１０１は、出演者及びイベントの単位で開設されるコミュニケーションツールであるチャネルを管理する。具体的には、管理部１０１は、チャネルへの投稿及びチャネルの投稿の閲覧を管理する。また、管理部１０１は、チャネルへの投稿の受け付けると、投稿された投稿データを投稿管理ＤＢ１００ｅに格納する。また、管理部１０１は、チャネルに投稿された投稿データの閲覧を受け付けると、投稿管理ＤＢ１００ｅから投稿データを取得して端末２０の画面に表示させる。

【0027】

また、管理部１０１は、チャネルへの投稿及びチャネルの投稿の閲覧を受け付ける際、権限の有無を確認する。例えば、管理部１０１は、イベントのチケットを所有していることが確認されたチケット所有ユーザ及びイベントの出演者に対し、チャネルへの投稿及びチャネルの投稿の閲覧を許可する。

【0028】

所有確認部１０２は、イベントに参加するユーザが所有するイベントのチケットに関するチケット情報を取得し、取得したチケット情報とイベント開催情報とを突合することで、ユーザがチケットを所有していることの確認を行う。

【0029】

付与部１０３は、ブロックチェーンネットワーク３０で動作するスマートコントラクトに対し、イベントに参加したことを示すＮＦＴを発行するように指示する。また、付与部１０３は、イベントのチケットを所有していると判断されたチケット所有ユーザのブロックチェーンウォレットに対し、イベントに参加したことに関する情報（例えばイベント名、イベント開催日時及び出演者名等）を含むＮＦＴを付与する。また、付与部１０３は、イベントに参加したことに関する情報としてバッジの画像をチケット所有ユーザに付与する。バッジの画像は、アイコンと呼ばれてもよい。

【0030】

表示制御部１０４は、コミュニケーションサービスを実現するための各種の画面を端末２０に表示させる。なお、表示制御部１０４は、管理部１０１に含まれていてもよい。

【0031】

図４は、イベント管理ＤＢ１００ａの一例を示す図である。イベントＩＤは、開催されるイベントを一意に識別するＩＤを示す。イベント開催情報は、開催されるイベントを一意に特定する特定情報を含む。開催日時は、イベントが開催される日及びイベント開始時刻を示す。開催場所は、イベントが開催される場所を示す。イベント名称は、イベントの名称を示す。出演者ＩＤは、出演者を一意に識別するＩＤを示す。なお、出演者ＩＤには、出演者ＩＤに対応する出演者名がさらに含まれていてもよい。座席番号一覧は、イベント会場に設けられた全ての座席番号に関する情報（例えば、Ａ～Ｆ列についてそれぞれ１番～３０番の座席が存在するなど）を示す。

【0032】

図５は、アカウント管理ＤＢ１００ｂの一例を示す図である。ユーザＩＤは、コミュニケーションサービスに登録されたユーザを一意に識別するＩＤを示す。ログイン情報は、コミュニケーションサービスにログインするためのログイン情報（例えばログインＩＤ及びパスワード）を示す。ユーザ属性は、ユーザの属性（出演者、関係者及び一般ユーザのいずれか）を示す。デジタルバッジ情報（ＮＦＴ）には、一般ユーザに対しイベントに参加したことを示すＮＦＴが付与されている場合、付与されたＮＦＴのトークンＩＤが格納される。もし、ＮＦＴが付与されていない場合、デジタルバッジ情報（ＮＦＴ）には何も格納されない。デジタルバッジ情報（バッジ画像）には、一般ユーザがどのイベントに参加したのかを示すバッジの画像のＩＤが格納される。当該バッジの画像は、コミュケーションサービスの画面の中で一般ユーザに対応づけて表示される。もし、バッジが付与されていない場合、デジタルバッジ情報（バッジ画像）には何も格納されない。

【0033】

図６は、チケット管理ＤＢ１００ｃの一例を示す図である。ユーザＩＤ（一般ユーザ）は、一般ユーザを一意に識別するＩＤを示す。チケット所有状態は、一般ユーザがチケットを所有していることが確認されたか否かを示す。「確認済み」は、一般ユーザがチケットを所有していることが確認できた状態を示す。「確認中」は、アップロードされたチケットの画像データを解析中である場合や管理者が確認中である場合など、一般ユーザがチケットを所有していることを確認中であることを示す。「エラー」は、一般ユーザがチケットを所有していることの確認ができなかったことを示す。イベントＩＤは、後述するイベント特定情報から特定されたイベントのＩＤを示す。チケット情報には、ユーザが所有するチケットに関する各種情報が格納される。イベント特定情報は、チケット画像データから読み取られた、イベントを一意に特定するイベント特定情報を示す。イベント特定情報の具体的な内容については後述する。座席番号は、チケットに記載された座席番号を示す。チケット画像データには、管理サーバ１０にアップロードされた画像データが格納される。

【0034】

図７は、チャネル管理ＤＢ１００ｄの一例を示す図である。チャネルＩＤは、開設されるチャネルを一意に識別するＩＤを示す。ユーザＩＤ（出演者、関係者）は、コミュニケーション管理システム１に登録されたユーザのうち出演者及び関係者を一意に識別するＩＤを示す。イベントＩＤは、イベントを一意に識別するＩＤを示す。ＵＲＬは、開設されるチャネルにアクセスするためのＵＲＬを示す。開始日時は、チャネルの開設が開始される日時を示す。終了日時は、チャネルの開設が終了する（閉鎖される）日時を示す。なお、複数の出演者が出演するイベントである場合、チャネルは出演者ごとに開設されてもよいし、複数の出演者共通に開設されてもよい。前者の場合、同一のイベントＩＤに対して異なる複数のチャネルＩＤが対応づけられることになる。一方、後者の場合、同一のイベントＩＤに対して１つのチャネルＩＤが対応づけられることになる。

【0035】

図８は、投稿管理ＤＢ１００ｅの一例を示す図である。チャネルＩＤは、開設されるチャネルを一意に識別するＩＤを示す。投稿ＩＤは、投稿データを一意に識別するＩＤを示す。投稿日時は、投稿データがチャネルに投稿された日時を示す。ユーザＩＤ（投稿者）は、投稿データをチャネルに投稿したユーザのＩＤが格納される。例えば、出演者が投稿した場合、投稿者ＩＤには出演者のユーザＩＤが格納される。また、チケット所有ユーザが投稿した場合、投稿者ＩＤにはチケット所有ユーザのユーザＩＤが格納される。

【0036】

閲覧制限は、投稿の閲覧が制限されるか否かを示す。本実施形態では、チャネルへの投稿には、限定されたユーザのみが閲覧可能な投稿（以下、「限定投稿」という。）と、閲覧が制限されない投稿（以下、「通常投稿」という。）とが含まれている。投稿が通常投稿の場合は、「無し」が設定され、投稿が限定投稿の場合は、「限定」が設定される、投稿データには、投稿されたテキストデータ、画像データ、音声データ及び／又は映像データ等が格納される。なお、限定されたユーザ（以下、「限定ユーザ」という。）は、チケット所有ユーザ及びイベントの出演者であってもよい。又は、限定されたユーザは、チケット所有ユーザ、イベントの出演者及びイベントの関係者であってもよい。すなわち、「限定ユーザ」は、チケット所有ユーザ及びイベントの出演者を含む限定されたユーザと定義されてもよい。

【0037】

「投稿属性」は、投稿の属性を示す。本実施形態では、チャネルへの投稿には、特別な投稿と特別ではない投稿が含まれていてもよい。特別な投稿は、金銭を支払うことで投稿可能なメッセージであってもよい。一例として、特別な投稿は、画像、音声又は映像を含むメッセージであってもよいが、これに限定されるものではない。他の例として、特別な投稿は、投稿を一覧表示する画面において特別ではない投稿よりも優先的に表示される投稿であってもよい。一方、特別ではない投稿は、金銭を支払うことなく、通常投稿可能なメッセージであってもよい。一例として、特別ではない投稿は、画像、音声及び映像を含まないテキストのみのメッセージであってもよいが、これに限定されるものではない。特別な投稿の「投稿属性」カラムには、投稿の属性として、「特別」が格納される。また、特別ではない投稿の「投稿属性」カラムには、投稿の属性として「通常」が格納される。

【0038】

特別な投稿であるのか否かは、通常投稿及び限定投稿の両方に適用可能である。つまり、本実施形態では、投稿は、特別ではない通常投稿、特別ではない限定投稿、特別な通常投稿、及び、特別な限定投稿の４種類に分かれていてもよい。

【0039】

＜処理手順＞
図９は、管理サーバ１０が行う処理手順の一例を示す図である。図９を用いて、管理サーバ１０が提供するコミュニケーションサービス上で行われる各種処理について説明する。

【0040】

ステップＳ１００で、管理部１０１は、コミュニケーションサービスを利用するユーザからログイン情報の入力を受け付けることで、ログイン処理を行う。管理部１０１は、入力されたログインＩＤ及びパスワードと、アカウント管理ＤＢ１００ｂとを突合することでログイン処理を行う。ログインが完了した場合はステップＳ１０１に進み、ログインに失敗した場合は処理を終了する。

【0041】

ステップＳ１０１で、ログインしたユーザが画面を操作することでチケット登録を選択した場合、ステップＳ１０２の処理手順に進む。チケット登録を選択しなかった場合はステップＳ１０４の処理手順に進む。

【0042】

ステップＳ１０２で、所有確認部１０２は、ユーザが利用する端末２０からチケット情報を取得し、ユーザがチケットを所有しているか否かの確認を行う。具体的には、ユーザは、紙チケットを撮影した画像データ、又は、電子チケットのスクリーンショットを、端末２０から管理サーバ１０にアップロード（登録）する。所有確認部１０２は、ユーザが所有しているチケットの画像データを取得する。続いて、所有確認部１０２は、チケットの画像データをＯＣＲ（Optical Character Recognition）処理することで、チケットに記載された文字を読み取り、読み取った文字列に対し固有表現抽出処理を行うことで、チケット情報を抽出する。なお、所有確認部１０２は、画像データをＯＣＲ処理することに代えて、チケットの画像データを入力するとチケット情報を出力するように学習された学習モデルを用いて、チケット情報を抽出するようにしてもよい。また、コミュニケーションサービスの管理者が目視でチケット情報を読み取ることとしてもよい。この場合、所有確認部１０２は、コミュニケーションサービスの管理者から、目視で読み取ったチケット情報の入力を受け付けるようにしてもよい。

【0043】

また、コミュニケーションサービスの中でチケットの購入が可能である場合、すなわち、管理サーバ１０が自らチケットを発行した場合、所有確認部１０２は、発行したチケットの情報を管理するデータベースから、ユーザが所有するチケットのチケット情報を取得するようにしてもよい。

【0044】

また、チケットの購入データを、チケットの売買情報を管理する他のサーバ（例えば他社が運営するプレイガイドのサーバ等）から取得することが可能である場合、所有確認部１０２は、発行したチケットの情報を管理する他のサーバから、ユーザが所有するチケットのチケット情報を取得するようにしてもよい。

【0045】

続いて、所有確認部１０２は、画像データから読み取ったチケット情報に含まれる、イベントを一意に特定するイベント特定情報と、イベント管理ＤＢ１００ａに含まれるイベント開催情報とを突合し、イベント特定情報がイベント開催情報に含まれる特定情報と一致する場合（つまり、イベントが一意に特定できた場合）に、ユーザはイベントのチケットを所有していることが確認できたと判断する。

【0046】

一方、所有確認部１０２は、イベント特定情報がイベント開催情報に含まれる特定情報と一致しない場合（つまり、イベントが一意に特定できない場合）、ユーザはイベントのチケットを所有していることが確認できなかったと判断するようにしてもよい。この場合、所有確認部１０２は、更に、コミュニケーションサービスの管理者に対し、チケットの画像データを目視で確認するように依頼するようにしてもよい。所有確認部１０２は、管理者から、ユーザはイベントのチケットを所有しているとの通知を受けた場合、ユーザはイベントのチケットを所有していることが確認できたと判断する。

【0047】

また、所有確認部１０２は、チケットを所有していることが確認されたチケット所有ユーザについて、イベント管理ＤＢ１００ａから、チケットに対応するイベントＩＤを取得する。続いて、管理部１０１は、取得したイベントＩＤとイベント特定情報とチケットの座席番号とを、チケット管理ＤＢ１００ｃのチケット所有ユーザのレコードに格納する。

【0048】

チケット画像データから読み取られたイベント特定情報及びイベント管理ＤＢ１００ａのイベント開催情報に含まれる特定情報は、例えば、イベントの開催日時、開催場所及び／又はイベント名称であってもよい。例えば、所有確認部１０２は、チケットの画像データから読み取ったイベント特定情報（イベント開催日時、開催場所及びイベント名称）とイベント管理ＤＢ１００ａのイベント開催情報に含まれる特定情報（イベント開催日時、開催場所及びイベント名称）とが一致する場合に、ユーザはイベントのチケットを所有していることが確認できたと判断するようにしてもよい。また、例えば、所有確認部１０２は、チケットの画像データから読み取ったイベント特定情報（イベント開催日時及びイベント名称）とイベント管理ＤＢ１００ａのイベント開催情報に含まれる特定情報（イベント開催日時及びイベント名称）とが一致する場合に、ユーザはイベントのチケットを所有していることが確認できたと判断するようにしてもよい。また、例えば、所有確認部１０２は、チケットの画像データから読み取ったイベント特定情報（イベント名称）とイベント管理ＤＢ１００ａのイベント開催情報に含まれる特定情報（イベント名称）とが一致する場合に、ユーザはイベントのチケットを所有していることが確認できたと判断するようにしてもよい。

【0049】

また、イベント特定情報及びイベント開催情報に含まれる特定情報には、更に、出演者が含まれていてもよい。例えば、所有確認部１０２は、更に、チケットの画像データから読み取った出演者名が、イベント管理ＤＢ１００ａのイベント開催情報に含まれる出演者に含まれる場合に、ユーザはイベントのチケットを所有していることが確認できたと判断するようにしてもよい。

【0050】

また、イベント特定情報及びイベント開催情報に含まれる特定情報には、更に、座席番号が含まれていてもよい。例えば、所有確認部１０２は、更に、チケットの画像データから読み取った座席番号が、イベント管理ＤＢ１００ａのイベント開催情報に含まれる座席番号一覧に含まれる場合に、ユーザはイベントのチケットを所有していることが確認できたと判断するようにしてもよい。これにより、実在しない座席番号が記載されている不正なチケットを排除することが可能になる。

【0051】

なお、コミュニケーションサービス内でチケット販売を行う場合、チケットにイベントＩＤを記載することが可能である。そこで、チケットにイベントＩＤが記載されている場合、イベント特定情報及びイベント開催情報に含まれる特定情報は、イベントＩＤであるものとしてもよい。この場合、所有確認部１０２は、チケットの画像データから読み取ったイベント特定情報（イベントＩＤ）とイベント管理ＤＢ１００ａのイベント開催情報に含まれる特定情報（イベントＩＤ）とが一致する場合に、ユーザはイベントのチケットを所有していることが確認できたと判断するようにしてもよい。

【0052】

また、コミュニケーションサービス内でチケット販売を行う場合、又は、チケットの購入データを、チケットの売買情報を管理する他のサーバから取得することが可能である場合、所有確認部１０２は、ユーザはチケットを所持しているものとみなし、ステップＳ１０２の処理手順を省略し、ステップＳ１０３の処理手順に進むようにしてもよい。

【0053】

ここで、所有確認部１０２は、更に、チケットの座席情報を用いることで、アップロードされたチケットが、既に登録済みのチケットではないことを確認するようにしてもよい。また、所有確認部１０２は、アップロードされたチケットが既に登録済みのチケットではないことが確認できた場合に、ユーザはイベントのチケットを所有していると判断するようにしてもよい。

【0054】

具体的には、所有確認部１０２は、更に、チケット情報に含まれる、イベントにおける座席を一意に特定する座席情報が、他のユーザから取得したチケットの画像データから特定された座席情報と同一ではない場合（つまり、座席情報が重複していない場合）、ユーザは、イベントのチケットを所有していると判断するようにしてもよい。また、所有確認部１０２は、チケット情報に含まれる、イベントにおける座席を一意に特定する座席情報が、他のユーザから取得したチケットの画像データから特定された座席情報と同一である場合（つまり座席情報が重複している場合）、ユーザはイベントのチケットを所有していないと判断するようにしてもよい。これにより、複数のユーザが同一のチケットを重複して登録することを排除することができる。

【0055】

ステップＳ１０３で、管理部１０１は、ステップＳ１０２の処理手順でチケットを所有していることが確認されたチケット所有ユーザについて、チケット管理ＤＢ１００ｃから、チケット所有ユーザが所有しているチケットに対応するイベントＩＤを取得する。続いて、管理部１０１は、チャネル管理ＤＢ１００ｄにアクセスし、イベントＩＤに対応するチャネルのＵＲＬを取得し、取得したＵＲＬをチケット所有ユーザの端末２０に送信する。なお、同一のイベントに複数のチャネルが開設される場合、管理部１０１は、複数のＵＲＬを取得することになる。例えば、図７の例では、イベントＩＤがＥ１００であった場合、管理部１０１は、チャネルＩＤがＣ１１０であるチャネルのＵＲＬと、チャネルＩＤがＣ２１０であるチャネルのＵＲＬとの２つを取得することになる。続いて、管理部１０１は、取得したＵＲＬを、チケット所有ユーザの端末２０に送信する。取得したＵＲＬが複数である場合、管理部１０１は、複数のＵＲＬを、チケット所有ユーザの端末２０に送信する。

【0056】

なお、管理部１０１は、ＵＲＬを端末２０に送信することに加えて又は代えて、ユーザが所有しているチケットに対応するチャネルを一覧表示するチャネル一覧画面を端末２０に表示させるようにしてもよい。

【0057】

ステップＳ１０４で、管理部１０１は、ユーザがチャネルの閲覧を選択した場合、すなわち、ＵＲＬにアクセスした場合、又はチャネル一覧画面からチャネルを選択した場合、ステップＳ１０５の処理手順に進む。ユーザがチャネルの閲覧を選択しなかった場合はステップＳ１０９の処理手順に進む。

【0058】

ステップＳ１０５で、管理部１０１は、ユーザから閲覧を希望するチャネルの選択を受け付ける。例えば、管理部１０１は、ユーザがＵＲＬにアクセスした場合、当該ＵＲＬのチャネルを選択したと認識するようにしてもよい。又は、管理部１０１は、チャネル一覧画面の中から、閲覧を希望するチャネルの選択を受け付けるようにしてもよい。なお、ユーザが、開始前又は終了しているチャネルのＵＲＬにアクセスした場合、管理部１０１は、アクセスしたチャネルは開始前であること又は終了していることを示すメッセージを端末２０の画面に表示させるようにしてもよい。

【0059】

ステップＳ１０６で、管理部１０１は、選択されたチャネルに投稿された投稿メッセージを、端末２０の画面に表示させる。具体的には、管理部１０１は、投稿管理ＤＢ１００ｅから、ステップＳ１０５で選択されたチャネルにおける投稿データ及び閲覧制限の設定値を取得する。続いて、管理部１０１は、端末２０の画面に投稿データを一覧表示させる。

【0060】

ここで、管理部１０１は、閲覧対象のチャネルの限定ユーザに対し、通常投稿及び限定投稿の閲覧を許可するようにしてもよい。また、管理部１０１は、閲覧対象のチャネルの限定ユーザ以外のユーザ（つまりチケット未所持ユーザ）に対し、通常投稿の閲覧を許可し、限定投稿の閲覧を許可しないようにしてもよい。

【0061】

管理部１０１は、端末２０の画面に投稿データを一覧表示させる際、チャネル管理ＤＢ１００ｄにアクセスし、閲覧対象のチャネルのイベントＩＤ及び出演者のユーザＩＤを取得する。続いて、管理部１０１は、アカウント管理ＤＢ１００ｂを参照することで、ユーザの属性を確認する。

【0062】

管理部１０１は、ユーザの属性が「一般ユーザ」である場合、更に、チケット管理ＤＢ１００ｃの「チケット所有状態」を参照することで、一般ユーザが、閲覧対象のチャネルのチケット所有ユーザであるかチケット未所有ユーザであるかを確認する。例えば、管理部１０１は、閲覧対象であるチャネルのイベントＩＤのレコードについて、「チケット所有状態」が「確認済み」である一般ユーザはチケット所有ユーザであり、「チケット所有状態」が「確認中」又は「エラー」である一般ユーザは、チケット未所持ユーザであると判断してもよい。また、チケット管理ＤＢ１００ｃに、閲覧対象であるチャネルのイベントＩＤ及びユーザＩＤに合致するレコードが存在しない一般ユーザは、チケット未所持ユーザであると判断してもよい。

【0063】

また、管理部１０１は、ユーザの属性が「出演者」又は「関係者」である場合、チャネル管理ＤＢ１００ｄを参照し、当該ユーザのユーザＩＤが、閲覧対象のチャネルの「ユーザＩＤ（出演者、関係者）」に含まれるか否かを確認する。含まれる場合、当該ユーザは、閲覧対象チャネルの出演者又は関係者であると判断し、含まれない場合、当該ユーザは、閲覧対象チャネルの出演者及び関係者ではないと判断する。後者の場合、管理部１０１は、閲覧対象のチャネルにおいて、当該ユーザをチケット未所持ユーザとして扱うようにしてもよい。

【0064】

続いて、管理部１０１は、投稿管理ＤＢ１００ｅから、閲覧対象のチャネルにおける投稿データ及び閲覧制限の設定値を取得する。続いて、管理部１０１は、ユーザが閲覧対象のチャネルの「出演者」、「関係者」及び「チケット所有ユーザ」である場合、閲覧対象のチャネルの投稿のうち閲覧制限が「無し」及び「限定」に設定されている投稿データを、端末２０の画面に表示させる。一方、管理部１０１は、ユーザが閲覧対象のチャネルの「チケット未所有ユーザ」である場合、閲覧対象のチャネルの投稿のうち閲覧制限が「無し」に設定されている投稿データを端末２０の画面に表示させ、「限定」に設定されている投稿データについては端末２０の画面に表示させないようにする。なお、管理部１０１は、閲覧制限が「限定」に設定されている投稿データについて、投稿データが存在することは認識可能であるが投稿データ自体の閲覧や出力は不可能な態様（例えばテキストや画像をマスクする等）で端末２０の画面に表示させるようにしてもよい。

【0065】

また、管理部１０１は、閲覧対象のチャネルの限定ユーザ及び限定ユーザ以外のユーザ（つまりすべてのユーザ）に対し、特別ではない通常投稿及び特別な通常投稿の閲覧を許可するようにしてもよい。

【0066】

ステップＳ１０７で、管理部１０１は、ユーザが画面を操作することでメッセージの投稿を選択した場合、ステップＳ１０８の処理手順に進む。メッセージの投稿を選択しなかった場合はステップＳ１０９の処理手順に進む。

【0067】

ステップＳ１０８で、管理部１０１は、ユーザから投稿を受け付ける。管理部１０１は、ユーザの端末２０から取得した投稿データとユーザ（投稿者）のユーザＩＤとを対応づけて投稿管理ＤＢに格納する。

【0068】

ここで、管理部１０１は、閲覧対象（投稿対象と称してもよい）のチャネルの限定ユーザに対し、閲覧対象のチャネルに対する新たな通常投稿の投稿及び新たな限定投稿の投稿を許可する。一方、管理部１０１は、閲覧対象のチャネルの限定ユーザ以外のユーザ（チケット未所有ユーザ）に対し、閲覧対象のチャネルに対する通常投稿の投稿及び限定投稿の投稿いずれも許可しないようにしてもよい。

【0069】

管理部１０１は、アカウント管理ＤＢ１００ｂを参照することで、ログインしているユーザの属性を確認する。また、管理部１０１は、ユーザの属性が一般ユーザである場合、チケット管理ＤＢ１００ｃを参照することで、ユーザが、閲覧対象のチャネルのチケット所有ユーザであるかチケット未所有ユーザであるかを確認する。続いて、管理部１０１は、ユーザが閲覧対象のチャネルの出演者、関係者及びチケット所有ユーザである場合（つまり限定ユーザである場合）、ユーザから、限定投稿を投稿するのか、通常投稿を投稿するのかの選択を受け付け、受け付けた閲覧制限の設定と投稿データとを対応づけて投稿管理ＤＢ１００ｅに格納する。一方、管理部１０１は、ユーザが、閲覧対象のチャネルのチケット未所有ユーザである場合（つまり限定ユーザ以外のユーザである場合）、投稿を受け付けないようにする。

【0070】

また、管理部１０１は、ユーザが、閲覧対象のチャネルの出演者、関係者及びチケット所有ユーザである場合（つまり限定ユーザである場合）、特別ではない通常投稿、特別な通常投稿、特別ではない限定投稿又は特別な限定投稿の投稿を受け付けるようにしてもよい。管理部１０１は、閲覧制限の設定と投稿属性の設定と投稿データとを対応づけて投稿管理ＤＢ１００ｅに格納する。

【0071】

また、管理部１０１は、閲覧対象のチャネルのチケット未所有ユーザに対し、当該チャネルに対する通常投稿の投稿を許可するが限定投稿の投稿は許可しないようにしてもよい。また、管理部１０１は、更に、閲覧対象のチャネルのチケット未所有ユーザに対し、特別ではない通常投稿の投稿を許可するが、特別な通常投稿の投稿については許可しないようにしてもよい。

【0072】

ステップＳ１０９で、管理部１０１は、ユーザがログアウトを選択した場合は処理を終了し、ログアウトを選択しない場合はステップＳ１０１に戻る。

【0073】

図１０は、管理サーバ１０が行う処理手順の一例を示す図である。図１０を用いて、管理サーバ１０がチケット所有ユーザに、イベントに参加したことを示すバッジを付与する際の処理手順を説明する。なお、図１０の処理手順を実行するタイミングは任意であるが、例えば、チャネルを閉鎖する際に実行されてもよいし、イベント終了後からチャネルを閉鎖するまでの間に実行されてもよい。以下の説明では、チャネルを閉鎖する際にバッジを付与するものとして説明する。

【0074】

ステップＳ２００で、付与部１０３は、閉鎖するチャネルに対応するチケットを所有するユーザを抽出する。具体的には、付与部１０３は、チャネル管理ＤＢ１００ｄを参照し、閉鎖するチャネルに対応するイベントＩＤを取得する。続いて、付与部１０３は、チケット管理ＤＢ１００ｃを参照し、取得したイベントＩＤに対応する「チケット所有状態」が「確認済み」であるユーザを抽出する。

【0075】

ステップＳ２０１で、付与部１０３は、抽出したチケット所有ユーザが、ブロックチェーンのウォレットを開設済みであるか否かを確認する。例えば、付与部１０３は、抽出したチケット所有ユーザの端末２０に、ブロックチェーンのウォレットのアドレスを入力する画面を表示させるようにしてもよい。付与部１０３は、チケット所有ユーザがウォレットのアドレスを入力した場合、チケット所有ユーザはウォレットを開設済みと判断してステップＳ２０２に進み、チケット所有ユーザがウォレットのアドレスを所有していないことを選択した場合、チケット所有ユーザはウォレットを開設済みではないと判断してステップＳ２０３に進む。もしくは、付与部１０３は、アカウント管理ＤＢ１００ｂに、ウォレットのアドレスが登録されているか否かを参照することで、抽出したチケット所有ユーザが、ブロックチェーンのウォレットを開設済みであるか否かを確認するようにしてもよい。

【0076】

ステップＳ２０２で、付与部１０３は、チケット所有ユーザのブロックチェーンウォレットに対し、イベントに参加したことに関する情報を含むＮＦＴを付与する。具体的には、付与部１０３は、ブロックチェーンネットワーク３０のスマートコントラクトに対し、ＮＦＴを発行するメソッドを発行することでＮＦＴを生成し、生成したＮＦＴのトークンＩＤを、アカウント管理ＤＢ１００ｂにおけるチケット所有ユーザのレコードのデジタルバッジ情報（ＮＦＴ）に格納する。また、付与部１０３は、チケット所有ユーザに対し、バッチ画像を付与する。具体的には、付与部１０３は、バッチ画像に対応する画像ＩＤを、アカウント管理ＤＢ１００ｂにおけるチケット所有ユーザのレコードの「デジタルバッジ情報（バッジ画像）」に格納する。

【0077】

ステップＳ２０３で、付与部１０３は、アカウント管理ＤＢ１００ｂを参照し、ユーザのレコードの「デジタルバッジ情報（ＮＦＴ）」に、ＮＦＴを発行可能であることを記録する。また、付与部１０３は、チケット所有ユーザに対し、バッチ画像を付与する。具体的には、付与部１０３は、バッチ画像に対応する画像ＩＤを、アカウント管理ＤＢ１００ｂにおけるチケット所有ユーザのレコードの「デジタルバッジ情報（バッジ画像）」に格納する。

【0078】

ステップＳ２０４で、付与部１０３は、ユーザの端末２０に対し、ウォレットの開設を促すメッセージを送信する。

【0079】

＜画面表示例＞
図１１は、チケット登録を行う画面の一例を示す図である。画面Ｗ１０は、チケットの登録を受け付ける画面である。Ｂ１０が押下されると、チケットを撮影した画像の選択する画面が表示される。画像表示エリアＰ１０には、選択されたチケット画像が表示される。送信ボタンＢ１１が押下されると、チケット画像が管理サーバ１０にアップロードされる。チケットの登録が完了し、ユーザがチケットを所有していることが確認されると画面Ｗ２０に遷移する。画面Ｗ２０には、登録されたチケットで参加できるイベントのチャネルが一覧表示される。

【0080】

図１２は、投稿表示画面の一例を示す図である。図１１の画面Ｗ２０で選択されたチャネルの投稿が、投稿表示画面Ｗ３０に時系列で一覧表示される。投稿メッセージＭ３０及びＭ３１は通常投稿の投稿メッセージであり、投稿メッセージＭ３２は限定投稿の投稿メッセージである。投稿メッセージＭ３２は、閲覧制限されているため、投稿内容は表示されない。例えば、ユーザがチケット所有ユーザ、出演者及び関係者である場合、投稿メッセージＭ３２に、閲覧制限されているメッセージを表示させるボタンＢ３２が表示される。また、ユーザがチケット未所有ユーザである場合、メッセージＭ３２には、ボタンＢ３２は表示されないようにしてもよいし、ボタンＢ３２が押下できない態様（グレーアウト）で表示されてもよいし、ボタンＢ３２が押下されても投稿メッセージＭ３２の内容は表示されないようにしてもよい。

【0081】

ボタンＭ３２が押下されると、投稿表示画面Ｗ４０に示すように、投稿メッセージＭ３２の内容が表示される。

【0082】

また、ユーザがチケット所有ユーザ、出演者及び関係者である場合、投稿表示画面Ｗ３０にはメッセージ投稿ボタンＢ３０及び特別メッセージ投稿ボタンＢ３１が表示される。一方、ユーザがチケット未所有ユーザである場合、ボタンＢ３０及びボタンＢ３１は表示されないようにしてもよいし、ボタンＢ３０及びボタンＢ３１が押下できない態様（グレーアウト）で表示されてもよいし、ボタンＢ３０及びボタンＢ３１が押下されても投稿画面Ｗ５０に遷移しないようにしてもよい。

【0083】

メッセージ投稿ボタンＢ３０又は特別メッセージ投稿ボタンＢ３１が押下されると、投稿画面Ｗ５０に遷移する。投稿画面Ｗ５０には、投稿する内容を入力するエリアＮ５０が表示される。また、投稿画面Ｗ５０には、ユーザがチケット所有ユーザ、出演者及び関係者である場合、投稿メッセージＭ３２に、閲覧制限されているメッセージを投稿するボタンＢ５０と、閲覧制限されていないメッセージを投稿するボタンＢ５１が表示される。

【0084】

＜変形例＞
（変形例１）
所有確認部１０２は、更に、チケットを所有するユーザが、実際にイベントに参加したことを確認するようにしてもよいまた、チケットを所有しており、かつ、実際にイベントに参加したことが確認できたユーザを「イベント参加ユーザ」といい、チケットを所有していることが確認できていないユーザ及びチケットを所有しているがイベントに参加しなかったユーザを「イベント未参加ユーザ」と呼ぶようにしてもよい。また、本実施形態で説明した各種処理において、チケット所有ユーザ及びチケット未所有ユーザを、それぞれ、イベント参加ユーザ及びイベント未参加ユーザに置き換えてもよい。

【0085】

ステップＳ１０２の処理手順で、端末２０は、チケット画像に加えて、実際にイベントに参加したことを確認可能な情報をアップロードするようにしてもよい。また、所有確認部１０２は、チケット画像に加えて、実際にイベントに参加したことを確認可能な情報が正しい情報であることを確認することで、ユーザがイベントに参加したことを確認するようにしてもよい。

【0086】

実際にイベントに参加したことを確認可能な情報は、例えば、イベント会場毎に予め指定された情報であってもよい。具体的には、イベント会場内において、指定された位置から指定された方向を撮影した画像であってもよいし、イベント会場内に存在する指定されたオブジェクト（例えば座席表や椅子に記載された座席番号など）を撮影した画像であってもよい。また、イベント管理ＤＢ１００ａのイベント開催情報には、イベント会場毎に予め指定された情報が格納されており、所有確認部１０２は、端末２０からアップロードされた情報と、イベント開催情報に格納されたイベント会場毎に予め指定された情報とを突合し、両者が一致した場合、ユーザは実際にイベントに参加したと判断するようにしてもよい。

【0087】

（変形例２）
ステップＳ１００におけるログイン処理は、管理サーバ１０とは異なる他のサーバで実行することとしてもよい。例えば、本実施形態では、各ユーザのログイン処理を、外部のＳＳＯ（Single Sign On）サービスを利用して実現するようにしてもよい。また、管理部１０１は、コミュニケーションサービスを利用するユーザから受け付けたログイン情報を他のサーバに転送し、他のサーバからログイン結果（成功／失敗）を取得するようにしてもよい。

【0088】

（変形例３）
本実施形態において、「座席番号」に代えて、チケットを一意に識別可能な情報を用いることで、複数のユーザが同一のチケットを重複して登録することを排除するようにしてもよい。すなわち、本実施形態における「座席番号」を「チケットを一意に識別可能な情報」に読み替えてもよい。チケットを一意に識別可能な情報は、例えば文字列及び／又は数字の組合せで構成されていてもよい。また、チケットを一意に識別可能な情報は、整理番号であってもよい。なお、整理番号は、チケットに記載されたチケット毎に異なる番号であり、例えば、来場者が会場に入る際の入場順序を指定したりする際に用いられる。

【0089】

（変形例４）
本実施形態では、コミュニケーションサービスを利用するユーザに対し、自動的にウォレットが開設されることとしてもよい。例えば、コミュニケーションサービスのアカウントを作成するためには、ウォレットを開設することが必須であってもよい。この場合、図１０のステップＳ２００、ステップＳ２０１、ステップＳ２０３及びステップＳ２０４の処理手順は省略されてもよい。

【0090】

（変形例４）
本実施形態において、「関係者」は省略されてもよい。この場合、コミュニケーションサービスを利用するユーザには、出演者と一般ユーザの２種類が存在することになる。

【0091】

＜まとめ＞
以上説明した実施形態によれば、管理サーバ１０は、出演者及びイベントの単位で開設されるコミュニケーションツールであるチャネルを管理し、イベントのチケットを所有していることが確認されたユーザとイベントの出演者に対し、当該チャネルへの投稿及び投稿を閲覧できるようにした。これにより、イベントに参加するユーザ間及びユーザと出演者とが直接コミュニケーションを取ることが可能になる。

【0092】

また、管理サーバ１０は、チケットの画像データからチケット情報を読み取るようにした。チケットの画像データからチケット情報を読み取るようにしたことで、チケットを発行する企業ごとにチケットの媒体が異なる場合であっても、チケット情報を取得することが可能になる。例えば、管理サーバ１０は、チケットが紙媒体である場合、端末２０が備えるカメラでチケットを撮影した画像からチケット情報を読み取ることが可能になる。また、管理サーバ１０は、チケットが電子チケットである場合、端末２０が備えるスクリーンショット機能で得られた画像からチケット情報を読み取ることが可能になる。

【0093】

また、管理サーバ１０は、チャネルに通常投稿と限定投稿の両方を投稿可能とし、限定投稿については、限定ユーザ（例えば出演者とチケット所有ユーザ）のみ閲覧可能とし、限定ユーザ以外のユーザ（チケット未所有ユーザ）は閲覧できないようにした。これにより、出演者やチケット所有ユーザは、例えば出演者やイベントに実際に参加したユーザしか知らない情報を流すことができ、出演者をより身近に感じてもらうことや、イベントに参加したユーザ間でより密なコミュニケーションを行うことが可能になる。

【0094】

以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。

【符号の説明】

【0095】

１ コミュニケーション管理システム、１０ 管理サーバ、１１ プロセッサ、１２ 記憶装置、１３ ネットワークＩＦ、１４ 入力装置、１５ 出力装置、２０ 端末、３０ ブロックチェーンネットワーク、１０ 管理サーバ、１００ 記憶部、１０１ 管理部、１０２ 所有確認部、１０３ 付与部、１０４ 表示制御部

【要約】

【課題】イベントに参加するユーザ間及びユーザと出演者とが直接コミュニケーションを取ることを可能とする技術を提供すること。
【解決手段】開催されるイベントに関するイベント開催情報を記憶する記憶部と、出演者及びイベントの単位で開設されるコミュニケーションツールであるチャネルを管理する管理部と、ユーザが所有する前記イベントのチケットに関するチケット情報を取得し、取得したチケット情報と前記イベント開催情報とを突合することで、前記ユーザがチケットを所有していることの確認を行う所有確認部と、を有し、前記管理部は、前記イベントのチケットを所有していることが確認されたユーザ及び前記イベントの出演者に対し、前記チャネルへの投稿及び前記チャネルの投稿の閲覧を許可する、管理装置を提供する。
【選択図】図３

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】