JP7018508B2 - 中央サーバ及びそれを含むドラマティック興行システム - Google Patents

Description

発明の背景
1. 技術分野
本明細書の開示は、中央サーバ及びそれを含む興行システムに関する。

2. 関連技術の説明
照明装置は、多くの人々が集まる興行ホール、音楽コンサート、またはアートギャラリーで、パフォーマンスを誘導するため、空間に動作の指示を出すため、あるいは審美的な応援をするために活用され得る。

特に、各個人に提供される照明装置は、空間における特定の場所または照明装置が提供される個人に合わせて、異なる方法で操作され得る。

照明装置には、照明装置が出力すべき光パターンの情報を保存してもよい。光パターンの情報は、興行システム内で中央サーバが生成してもよく、また、生成された情報をユーザーのモバイル端末を経由して照明装置に伝達してもよい。

複数の照明装置によって出力される光パターンが、観客や演技者にとって自然に見えるようにするためには、照明装置によって出力される色とカラーパターンの抽出を行うことが重要である。

発明の概要
本明細書が開示するある態様は、複数の照明装置によって出力される光パターンに対応するカラーパターンを効果的に生成できる中央サーバを提供するものである。

本明細書が開示する他の態様は、色の抽出の間に256色だけを抽出をすることでそれぞれの照明装置に伝達されるデータ容量を減らすものである。

本明細書に開示する具体的態様に従えば、中央サーバは、照明装置によって実行されるライブラリに対応するライブラリデータを保存するように構成されたデータベースと、ライブラリデータをユーザーのモバイル端末に送信するように構成されたコミュニケーションユニットと、興行ホールの座席マップを取得して、座席マップを構成する複数のピクセルの各々に、複数のピクセルの各々によって表現されるカラーパターンの情報を含む演出データを与えるように構成されたプロセッサとを含む。

本明細書に開示する具体的態様に従えば、興行システムは、ライブラリを生成するように構成された中央サーバと、ライブラリの実行コマンドを示す制御メッセージを生成するように構成された制御装置と、生成された制御メッセージを送信するように構成された送信装置と、ブロードキャスト方式において、送信装置から受信した制御メッセージを伝達するように構成された複数の中継器と、ライブラリに対応するライブラリデータを保存し、かつ、中継器から受信した制御メッセージに従って、保存されたライブラリデータを使用してライブラリを実行するように構成された複数の照明装置とを含むものであって、中央サーバは、興行ホールの座席マップを取得して、座席マップを構成する複数のピクセルの各々に、複数のピクセルの各々によって表現されるカラーパターンの情報を含む演出データを与えるように構成されている。

本明細書の開示に従えば、短時間で、複数の照明装置によって出力される光パターンに対応するカラーパターンを生成することが可能である。

本明細書の開示に従えば、色の抽出の間に256色だけが抽出されるので、それぞれの照明装置に伝達されるデータの容量を減らし、データ送信の速度を上げることができる。

図面の簡単な説明
図1は、本明細書に開示する具体的態様に従う、興行システムを説明するブロック図である。 図2は、本明細書に開示する具体的態様に従う、興行システムの構成を詳細に表現する模式図である。 図3は、本明細書に開示する具体的態様に従う、中央サーバの構成を説明するブロック図である。 図4は、本明細書に開示する具体的態様に従う、モバイル端末の構成を説明するブロック図である。 図5は、本明細書に開示する具体的態様に従う、制御装置の構成を説明するブロック図である。 図6は、本明細書に開示する具体的態様に従う、送信装置の構成を説明するブロック図である。 図7は、本明細書に開示する具体的態様に従う、照明装置の構成を説明する模式図である。 図8は、本明細書に開示する具体的態様に従う、中央サーバと、モバイル端末と、照明装置との間の動作の関係を説明するラダー図である。 図9は、本明細書に開示する具体的態様に従う、照明装置がシナリオの実行に使用する制御メッセージが送信される工程を説明するラダー図である。 図10は、本明細書に開示する具体的態様に従う、シナリオの例を説明する模式図である。 図11は、本明細書に開示する具体的態様に従う、シナリオデータの実際の構成を説明する模式図である。 図12は、本明細書に開示する具体的態様に従う、シナリオデータに含まれる情報を説明する模式図である。 図13A及び図13Bは、本明細書に開示する具体的態様に従う、制御メッセージの反復受信に従って、照明装置がタイミングを制御する例を説明する模式図である。 図13A及び図13Bは、本明細書に開示する具体的態様に従う、制御メッセージの反復受信に従って、照明装置がタイミングを制御する例を説明する模式図である。 図14A～図14Cは、本明細書に開示する具体的態様に従う、制御メッセージの反復受信及び同期パケットの受信に従って照明装置がタイミングを制御する例を説明する模式図である。 図14A～図14Cは、本明細書に開示する具体的態様に従う、制御メッセージの反復受信及び同期パケットの受信に従って照明装置がタイミングを制御する例を説明する模式図である。 図14A～図14Cは、本明細書に開示する具体的態様に従う、制御メッセージの反復受信及び同期パケットの受信に従って照明装置がタイミングを制御する例を説明する模式図である。 図15は、本明細書に開示する具体的態様に従う、照明装置の電源をオンにした時の初期化動作を説明する模式図である。 図16は、本明細書に開示する具体的態様に従う、演出の類型に基づく照明装置の動作過程を説明するフローチャートである。 図17A及び図17Bは、本明細書に開示する具体的態様に従う、照明装置と受台とが互いに連結されていない場合における照明装置の動作を説明する模式図である。 図17A及び図17Bは、本明細書に開示する具体的態様に従う、照明装置と受台とが互いに連結されていない場合における照明装置の動作を説明する模式図である。 図18A及び図18Bは、本明細書に開示する具体的態様に従う、照明装置と受台とが互いに連結されている場合における照明装置の動作過程を説明する模式図である。 図18A及び図18Bは、本明細書に開示する具体的態様に従う、照明装置と受台とが互いに連結されている場合における照明装置の動作過程を説明する模式図である。 図19は、本明細書に開示する他の具体的態様に従う、中央サーバの構成を説明するブロック図である。 図20は、本明細書に開示する他の具体的態様に従う、中央サーバの動作方法を説明するフローチャートである。 図21は、本明細書に開示する具体的態様に従い取得された、座席マップを説明する模式図である。 図22及び図23は、本明細書に開示する具体的態様に従う、ドットアニメーションを説明する模式図である。 図22及び図23は、本明細書に開示する具体的態様に従う、ドットアニメーションを説明する模式図である。 図24は、本明細書に開示する具体的態様に従う、照明装置により出力されるべき光のカラーパターンを検知する工程を説明するフローチャートである。 図25は、本明細書に開示する具体的態様に従う、ピクセルのカラーパターンを検知する工程を説明するフローチャートである。 図26及び図27は、本明細書に開示する具体的態様に従う、ピクセルの色の継続性を抽出する工程を説明する模式図である。 図26及び図27は、本明細書に開示する具体的態様に従う、ピクセルの色の継続性を抽出する工程を説明する模式図である。 図28は、本明細書に開示する具体的態様に従い、コサイン類似度技術を使って色の変遷を決定する工程を説明する模式図である。 図29は、本明細書に開示する具体的態様に従い抽出したカラーパターンが呼吸パターンである場合のRGB値の変化を示すグラフあり、図30は、本明細書に開示する具体的態様に従い抽出したカラーパターンが点滅パターンである場合のRGB値の変化を示すグラフある。 図29は、本明細書に開示する具体的態様に従い抽出したカラーパターンが呼吸パターンである場合のRGB値の変化を示すグラフあり、図30は、本明細書に開示する具体的態様に従い抽出したカラーパターンが点滅パターンである場合のRGB値の変化を示すグラフある。 図31は、本明細書に開示する具体的態様に従う、エラーが発生するフレームの色データを修正する工程を説明する模式図である。 図32は、本明細書に開示する具体的態様に従う、制御装置がシナリオまたはライブラリを編集するためのシナリオ編集画面を説明する模式図である。

詳細な説明
以下、本明細書の開示に関する具体的態様を添付の図面を参照してより詳細に説明する。以下の説明において、本明細書中に記載される、構成要素についての接尾辞「．．．モジュール」及び「．．．ユニット」は、説明の作成における便宜のみを考慮して使用されているか、または互いに交換可能に使用されているにすぎず、互いに区別される意味や役割を持たない。

説明において、「装置」であって、個人によって持ち運ばれたり個人に提供されたりする、様々なパターンで発光する、かつ、補助的な振動機能を含むものは「照明装置（Lighting Device）」と呼ばれる。照明装置は、興行ホールや音楽コンサートにおいて興行を鑑賞するユーザーによって所持されていてもよく、あるいは各ユーザーに提供される個々のユーザーの座席に固定されていてもよい。

次に、照明装置が発光、点灯、または追加的に振動を提供する様式は、「パターン」と呼ばれ、1以上のパターンが互いに組み合わせられてシナリオを提供する。

シナリオは、興行主（プロモーター）がデザインした画像が照明装置によって出力される光を使って表現されるようにする。

例えば、1つのシナリオが、歌に対応していてもよい。従って、1つのシナリオの再生時間は、歌の再生時間に等しくてもよい。

シナリオは、複数のライブラリで構成されていてもよい。複数のライブラリの各々は、シナリオの再生区間の一部分に対応していてもよい。

シナリオデータは、シナリオの実行に必要な情報を含んでいてもよい。

シナリオデータは、複数個のライブラリデータを含んでいてもよい。

図1は、本明細書に開示する具体的態様に従う、興行システムを説明するブロック図であり、図2は、本明細書に開示する具体的態様に従う、興行システムの構成を詳細に表現する模式図である。

図1及び図2を参照すると、本明細書に開示する具体的態様に従う興行システム1は、中央サーバ5と、興行管理装置10と、制御装置20と、送信装置30と、複数の中継器40-1～40-nと、複数の照明群50-1～50-nと、複数のモバイル端末60-1～60-nと、興行装置70とを含んでいてもよい。

中央サーバ5は、シナリオを生成して保存してもよい。シナリオは、興行の興行主がデザインしてもよい。興行主は、中央サーバ5に含まれている、または中央サーバ5とは別個に構成されている計算装置を通してシナリオを生成してもよい。

その後、モバイル端末60と制御装置20が、中央サーバ5からシナリオに対応するシナリオデータをダウンロードしてもよい。

興行管理装置10は、舞台を構成する音響装置と照明装置の動作を管理する装置であってもよい。

興行管理装置10は、音響と照明を出力するためのタイミング信号をそれぞれ、音響装置と照明装置に対して、特定の時間に伝達してもよい。

制御装置20は、中央サーバ5からシナリオを受信してもよく、また、送信装置30に対して、受信したシナリオに従って照明装置50を動作させるための制御メッセージを送信してもよい。

送信装置30は、制御装置20から伝達された制御メッセージを複数の中継器40-1～40-nに送信してもよい。

これまで送信装置30を別個の構成として説明してきたが、これは単なる例示であり、送信装置30は、制御装置20に含まれていてもよい。

複数の中継器40-1～40-nは、送信装置30から伝達された制御メッセージを複数の照明群50-1～50-nに送信してもよい。

複数の中継器40-1～40-nが必要である理由は、制御メッセージが、興行ホールが大規模である場合には、それぞれの照明装置50に適切に送信されないためである。

複数の中継器40-1～40-nの各々は、ブロードキャスト方式において隣接する照明群に制御メッセージを送信してもよい。ブロードキャスト方式は、受信者が指定されないメッセージ送信方法であってもよい。

複数の照明群50-1～50-nの各々は、複数の照明装置を含んでいてもよい。

複数のモバイル端末60-1～60-nの各々複数の照明装置の各々とペアリングされていてもよい。ユーザーは、モバイル端末と照明装置50とを所持していてもよい。

モバイル端末60は、中央サーバ5からシナリオを受信してもよい。

興行装置70は、音声を出力するための音響装置と、照明を出力するための照明装置と、画像を出力するためのディスプレイ装置とを含んでいてもよい。

興行システム1を構成するそれぞれの構成要素間の動作については後述する。

図3は、本明細書に開示する具体的態様に従う、中央サーバの構成を説明するブロック図である。

図3を参照すると、中央サーバ5は、キャンバスメーカ310と、ライブラリコンバータ320と、ライブラリスライサ330と、アカウントマネージャ340と、ライブラリマネージャ350と、ファームウェアマネージャ360と、データベース370とを含んでいてもよい。

キャンバスメーカ310は、興行の座席マップを生成してもよい。さらに、キャンバスメーカ310は、座席マップを構成する複数の座席の各々に対するチケット識別子をマップしてもよい。チケット識別子は、座席を識別するための座席番号であってもよい。

複数の座席の各々を1ピクセルと呼んでもよい。

ライブラリコンバータ320は、照明装置からの実行が意図される画像を使用して、座席マップを構成する複数のピクセルに色を付けてもよい。

つまり、画像を構成する複数の場面を表現するために、複数のピクセルに、場面に対応する色が与えられてもよい。

ライブラリコンバータ320は、複数のピクセルに与えられた色に基づいて画像をドットアニメーションに変換してもよい。

ライブラリスライサ330は、ある興行時間に使用されている全ての演出のデータをドットアニメーションに基づく複数のピクセルに分離してもよい。この演出のためのデータは、それぞれのピクセルによって表現されるべき色とその色を表現する時間についての情報を含んでいてもよい。

アカウントマネージャ340は、複数のアカウントを管理してもよい。複数のアカウントの各々は、複数の興行主の各々のアカウントに対応していてもよい。

ライブラリマネージャ350は、キャンバスメーカ310、ライブラリコンバータ320と、ライブラリスライサ330の動作を管理してもよい。

ライブラリマネージャ350は、複数のライブラリを1つのシナリオとして生成してもよい。

ファームウェアマネージャ360は、興行を演出するためのソフトウェアを管理してもよい。

データベース370は、複数のライブラリと複数のシナリオを保存してもよい。

データベース370は、複数のアカウントのそれぞれに対応する、複数のシナリオを保存する。

図4は、本明細書に開示する具体的態様に従う、モバイル端末の構成を説明するブロック図である。

図4を参照すると、本明細書に開示する具体的態様に従うモバイル端末60は、コミュニケーションユニット610と、ディスプレイ装置630と、コントローラ650とを含んでいてもよい。

コミュニケーションユニット610は、中央サーバ5から、シナリオに対応するシナリオデータと、シナリオデータを使用するアプリケーションを実行するためのファームウェアを受信してもよい。

コミュニケーションユニット610は、シナリオデータとファームウェアを照明装置50に送信してもよい。

コミュニケーションユニット610は、モバイルコミュニケーションまたはコミュニケーションスキームのための技術標準（例えば、GSM（global system for mobile communications）、符号分割多元接続（CDMA）、CDMA2000、EV-DO （enhanced voice-data optimizedまたはenhanced voice-data only）、WCDMA（登録商標）（wideband CDMA）、HSDPA（high speed downlink packet access）、HSUPA（high speed uplink packet access）、LTE（long term evolution）及びLTE-A（long term evolution-advanced））に従って構築された、モバイルコミュニケーションネットワークの基地局、外部端末及びサーバの少なくとも1つに情報を送信／から受信してもよい。

コミュニケーションユニット610は、Bluetooth（登録商標）、BLE（Bluetooth（登録商標） low energy）、WiFi（登録商標）、ZigBee（登録商標）またはUWB等の無線周波数（RF）のコミュニケーションを使用する照明装置50に情報を送信／から受信してもよい。

コントローラ650は、モバイル端末60の動作全般を制御してもよい。

コントローラ650は、ライブラリダウンローダ651と、ファームウェアアップグレーダ653と、ライブラリプレーヤ655とを含んでいてもよい。

ライブラリダウンローダ651は、シナリオデータとライブラリデータを中央サーバ5からコミュニケーションユニット610を経由してダウンロードしてもよい。

ファームウェアアップグレーダ653は、コミュニケーションユニット610が中央サーバ5から受信したファームウェアを使用して新しいバージョンのファームウェアを受信した場合は、既存のファームウェアを新しいバージョンのファームウェアにアップグレードしてもよい。

ライブラリプレーヤ655は、モバイル端末60にペアリングされた照明装置50が興行時間に実行すべきシナリオを再生してもよい。

これを通じて、ユーザーは、興行時間の間にユーザー自身の照明装置50によって実行されるべき動作を事前に特定してもよい。

図5は、本明細書に開示する具体的態様に従う、制御装置の構成を説明するブロック図である。

制御装置20は、興行主または興行ホールまたは音楽コンサートにおいて照明装置50の動作を制御する支配人によって所持される装置であるが、コンピュータ、スマートフォン、またはタブレットコンピュータであってもよい。

図5を参照すると、制御装置20は、第1コミュニケーションユニット21と、第2コミュニケーションユニット22と、インターフェースユニット23と、ディスプレイユニット24と、保存ユニット25と、プロセッサ26とを含んでいてもよい。

第1コミュニケーションユニット21は、送信装置30と通信してもよい。第1コミュニケーションユニット21は、送信装置30とのコミュニケーションを実行するためにUSB（universal serial bus）基準を使用してもよい。

第1コミュニケーションユニット21は、制御メッセージを送信装置30に送信してもよい。制御メッセージは、シナリオを構成するライブラリを開始するためのメッセージであってもよい。

他の例として、制御メッセージは、現在実行中のライブラリを停止するためのメッセージであってもよい。

さらに他の例として、制御メッセージは、照明装置50内に保存されたライブラリのパターンとは異なるパターンを有するライブラリを実行するためのメッセージであってもよい。

第2コミュニケーションユニット22は、中央サーバ5または興行管理装置10とコミュニケーションを行ってもよい。

第2コミュニケーションユニット22は、シナリオデータを中央サーバ5から受信してもよい。

インターフェースユニット23は、ユーザーの入力を受信してもよい。インターフェースユニット23は、制御メッセージを送信装置30に送信するためのユーザーの入力を受信してもよい。

インターフェースユニット23は、タッチキーとプッシュキーとを含んでいてもよい。

ディスプレイユニット24は、保存されたシナリオをこれをシミュレーションすることを通じて出力してもよい。ユーザーは、シミュレーションを通じたシナリオに従って、照明装置が適切に動作するかどうか識別してもよい。

保存ユニット25は、シナリオと制御メッセージを保存してもよい。

プロセッサ26は、制御装置20の動作全般を制御してもよい。

プロセッサ26は、制御メッセージを生成してもよく、生成された制御メッセージを送信装置に第2コミュニケーションユニット22経由で送信してもよい。

プロセッサ26は、タイムコードコンバータ26aとシナリオエディタ26bとを含んでいてもよい。

タイムコードコンバータ26aは、制御メッセージをタイムコードに変換してもよい。タイムコードは、照明群50-1～50-nを同期させるためのコードであってもよい。

シナリオエディタ26bは、ユーザーの入力に従って照明装置が実行すべきシナリオを生成したり編集したりしてもよい。

図6は、本明細書に開示する具体的態様に従う、送信装置の構成を説明するブロック図である。

送信装置30は、タイムコードレシーバ31と、タイムコードデコーダ32と、ライブラリパーサー33と、データプロトコルコンバータ34と、パケット管理ユニット35と、コミュニケーションユニット36とを含んでいてもよい。

タイムコードレシーバ31は、アナログ型タイムコードを制御装置20から受信してもよい。

タイムコードデコーダ32は、アナログ型タイムコードをデジタル型フレームデータにデコードしてもよい。フレームデータは、時間／分／秒の情報を含んでいてもよい。

ライブラリパーサー33は、デコードされたタイムコードを分析することによって、現在実行されているべきライブラリを識別するためのライブラリ識別情報を取得してもよい。

データプロトコルコンバータ34は、コミュニケーションプロトコルを変換して、取得したライブラリ識別情報を送信してもよく、また、変換されたパケットをパケット管理ユニット35に伝達してもよい。

パケット管理ユニット35は、受信したパケットをコミュニケーションユニット36に伝達してもよい。

パケット管理ユニット35は、複数の制御メッセージを生成してもよい。複数の制御メッセージの各々は、同じライブラリ識別情報を含んでいてもよい。

連続番号を複数の制御メッセージの各々に与えて、制御メッセージが所定の間隔で送信されるようにしてもよい。

複数の制御メッセージは、照明装置50に送信されているライブラリのための実行コマンドを示していてもよい。

複数の制御メッセージは、再送パケットと名付けられてもよい。

再送パケットの送信は、図13A及び図13Bを参照して説明する。

パケット管理ユニット35は、制御メッセージの損失を最小化してもよく、また、歪められているかもしれないタイミングの調整のための同期パケットを生成してもよい。

同期パケットは、照明装置50がライブラリの実行に良く従っているかを識別して、ライブラリの実行の同期をマッチングさせるパケットであってもよい。

同期パケットは、再送パケットの送信後に、ライブラリの実行が終了するまで周期的に生成されてもよい。

コミュニケーションユニット36は、パケット管理ユニット35から伝達されたパケットを複数の中継器40-1～40-nに、RFコミュニケーションを使用して、送信してもよい。

図7は、本明細書に開示する具体的態様に従う、照明装置の構成を説明する模式図である。

図7を参照すると、照明装置50は、第1コミュニケーションユニット51と、保存ユニット52と、第2コミュニケーションユニット53と、プロトコルプロセッサ54と、タイミングコントローラ55と、光源ユニット56と、プロセッサ57とを含んでいてもよい。

第1コミュニケーションユニット51は、シナリオデータまたはライブラリデータをモバイル端末60から受信してもよい。

第1コミュニケーションユニット51は、BLEモジュールまたはIEEE802.15.4基準を使用するワイヤレスコミュニケーションモジュールを含んでいてもよい。ただし、第1コミュニケーションユニット51は必ずしもこれに限られず、有線でシナリオデータを受信してもよい。

保存ユニット52は、受信したシナリオデータまたはライブラリデータを保存してもよい。

ユーザーは、興行ホールではなく家庭で照明装置50内にシナリオデータを予め保存してもよく、または興行ホールで照明装置50内にシナリオデータを保存してもよい。

第2コミュニケーションユニット53は、制御メッセージを送信装置30から受信してもよい。

第2コミュニケーションユニット53は、情報をBluetooth、BLE（Bluetooth low energy）、WiFi、ZigBeeまたはUWB等の無線周波数（RF）コミュニケーションを使用して中継器に送信／から受信してもよい。

プロトコルプロセッサ54は、第2コミュニケーションユニット53が受信するメッセージまたはパケットのタイプを区別してもよい。受信されたメッセージが制御メッセージ、再送パケットまたはsync（同期）パケットであれば、プロトコルプロセッサ54は、これをタイミングコントローラ55に伝達してもよい。

再送パケットを受信した場合は、タイミングコントローラ55が、受信された再送パケットに含まれる、複数の制御メッセージのそれぞれの連続番号に基づいて、照明装置50の動作タイミングを制御してもよい。

sync（同期）パケットを受信した場合は、タイミングコントローラ55が、受信したsync（同期）パケットに基づいて、照明装置50の動作タイミングを制御してもよい。

sync（同期）パケットは、「同期パケット」と呼んでもよい。

その詳細は後述する。

図7において、タイミングコントローラ55は別個の構成として説明されているが、これは単なる例示に過ぎず、タイミングコントローラ55は、プロセッサ57の構成に含まれていてもよい。

光源ユニット56は、プロセッサ57の制御下で保存ユニット52に保存された情報に従って、特定の色を有する発光、点滅、または明るさを制御する動作を行ってもよい。

光源ユニット56は、LEDで構成されていてもよいが、これは単なる例示であり、光源ユニット56は特定の発光材料で構成されていてもよい。

プロセッサ57は、照明装置50の動作全般を制御してもよい。

プロセッサ57は、保存ユニット52に保存されたシナリオデータと、第2コミュニケーションユニット53が受信した制御メッセージに従って、光源ユニット56の動作を制御してもよい。

プロセッサ57は、受信した制御メッセージに基づいて、どのシナリオライブラリが再生されるべきかを決定してもよい。

つまり、プロセッサ57は、制御メッセージを分析することによって、シナリオを構成する複数のライブラリのどれが実行されるべきかを決定してもよい。

プロセッサ57は、決定されたライブラリに従って動作するように光源ユニット56を制御してもよい。

特に、制御メッセージに含まれるライブラリ識別情報に基づいて、プロセッサ57は、保存ユニット52を通して、ライブラリ識別情報に対応するパターンを検索してもよく、また、対応するパターンを出力するように光源ユニット56を制御してもよい。

図8は、本明細書に開示する具体的態様に従う、中央サーバと、モバイル端末と、照明装置との間の動作の関係を説明するラダー図である。

中央サーバ5は、シナリオデータとシナリオデータに対応するシナリオを実行できるファームウェアとを取得して（S801）、その取得したシナリオデータとファームウェアとをモバイル端末60に送信する（S803）。

モバイル端末60は、中央サーバ5から受信したシナリオデータとファームウェアを保存する（S805）。

モバイル端末60は、受信したファームウェアを使用してアプリケーションをインストールしてもよい。アプリケーションは、シナリオデータの照明装置50への送信に使用されてもよい。

モバイル端末60は、照明装置50によって実行されるシナリオの群情報を構成する（S807）。

群情報は、ユーザーの座席に対応する情報であってもよい。群情報は、図1を参照して上述した照明群を識別するための情報であってもよい。

群情報は、モバイル端末60にインストールされたアプリケーションを使用して、チケット番号またはチケットの座席番号を通してQRコード（登録商標）を付ける方法において、ユーザーによって構成されてもよい。

群情報を構成した後に、モバイル端末60は、シナリオデータを照明装置50に送信する（S809）。

具体的態様において、モバイル端末60は、全ての照明群のシナリオデータを照明装置50に送信してもよい。

他の例として、モバイル端末60は、構成した群情報に対応するシナリオデータを送信してもよい。

照明装置50は、モバイル端末60から受信したシナリオデータを保存する（S811）。

モバイル端末60は、シナリオデータに加えて、ファームウェアも照明装置50に送信してもよい。

従って、照明装置50は、受信したファームウェアに従って駆動される。

図9は、本明細書に開示する具体的態様に従う、照明装置がシナリオの実行に使用する制御メッセージが送信される工程を説明するラダー図である。

制御装置20は、複数の照明装置50-1～50-nに送信されるべき制御メッセージを取得する（S901）。

具体的態様において、制御メッセージは、シナリオの実行コマンドを示すメッセージであってもよい。

例えば、1つのシナリオが歌手が歌う歌に対応する場合、制御装置20は、その歌の再生時間の間実行されるシナリオを実行するための制御メッセージを生成してもよい。

制御装置20は、取得した制御メッセージを送信装置30に送信する（S903）。

送信装置30は、取得した制御メッセージを複数の中継器40-1～40-nに送信する（S905）。

複数の中継器40-1～40-nは、送信装置30から送信された制御メッセージを複数の照明装置50-1～50-nのそれぞれに送信する（S907）。

具体的態様において、複数の中継器40-1～40-nは、受信者が指定されないブロードキャスト方式において、制御メッセージを複数の照明装置50-1～50-nのそれぞれに送信してもよい。

複数の照明装置50-1～50-nは、受信した制御メッセージに従って、それぞれの光源ユニット56の動作を制御する（S909）。

次に、本明細書に開示する具体的態様に従う、シナリオとシナリオを構成するデータを説明する。

図10は、本明細書に開示する具体的態様に従う、シナリオの例を説明する模式図であり、図11は、本明細書に開示する具体的態様に従う、シナリオデータの実際の構成を説明する模式図である。

図10は、1曲の歌の再生区間に対応する、シナリオ1000の例を示す。

1つのシナリオ1000は、複数のライブラリ1010、1020、1030、1040及び1050を含んでいてもよい。

シナリオの興行主は、制御装置20または中央サーバ5を通して1曲の歌の総再生区間を複数の区間に分割することによってシナリオを設計してもよい。

1曲の歌の総再生時間を4分間と想定する。

複数の区間は、それぞれ、複数のライブラリ1010、1020、1030、1040及び1050に対応していてもよい。

第1のライブラリ1010は、全ての照明装置の光源ユニット56が、歌の開始から10秒間電源オフにすべきことを示していてもよい。

第2のライブラリ1020は、全ての照明装置の光源ユニット56が、第1のライブラリ1010の実行後20秒間電源オンにすべきことを示していてもよい。

第3のライブラリ1030は、全ての照明装置の光源ユニット56が、第2のライブラリ1020の実行後1分間明滅する動作を行うべきことを示していてもよい。

第4のライブラリ1040は、全ての照明装置の光源ユニット56が、第3のライブラリ1030の実行後2分間歌手のロゴを表現する光を出力すべきことを示していてもよい。

第5のライブラリ1050は、全ての照明装置の光源ユニット56が、第4のライブラリ1040の実行後30秒間電源オフにすべきことを示していてもよい。

上述の通り、1つのシナリオは、第1～第5のライブラリ1010、1020、1030、1040及び1050の組合せを通して完成されてもよい。

制御装置20が送信装置30と複数の中継器40-1～40-nを経由して全ての照明装置に送信する制御メッセージは、シナリオ実行コマンドであってもよい。

他の具体的態様において、制御装置20が送信装置30と複数の中継器40-1～40-nを経由して全ての照明装置に送信する制御メッセージは、シナリオを構成する1ライブラリを実行するためのコマンドであってもよい。

図11を参照すると、シナリオ1000に対応するシナリオデータ1100の構造が図示されている。

シナリオデータ1100は、ヘッダ1110と、パレットフィールド1120と、複数のライブラリフィールド1130-1～1130-nとを含んでいてもよい。

パレットフィールド1120は、256色を表現できるカラーテーブルについての情報を含んでいてもよい。カラーテーブルは、256色のそれぞれに対応するインデックス値を含んでいてもよい。この場合、カラーテーブルは、1バイトのサイズを有していてもよい。

後述のライブラリデータは、カラーテーブルに含まれるインデックス値を含んでいてもよい。

複数のライブラリフィールド1130-1～1130-nの各々は、ライブラリヘッダ及びライブラリデータを含んでいてもよい。

例えば、第1のライブラリフィールド1130-1は、第1のライブラリヘッダ1130-1a及び第1のライブラリデータ1130-1bを含んでいてもよい。

第1のライブラリデータ1130-1bは、図10の第1のライブラリ1010に対応していてもよい。

各ライブラリデータは、群識別情報、ライブラリ識別情報、照明群動作開始時間、照明群動作終了時間、照明群によって出力されるべき色情報、及び照明群によって出力されるべきパターンのうち1以上の情報を含んでいてもよい。

各ライブラリデータに含まれる情報を図12を参照して詳細に説明する。

図12は、本明細書に開示する具体的態様に従う、シナリオデータに含まれる情報を説明する模式図である。

図12を参照すると、シナリオデータ1200は、複数のライブラリデータ1210～1250を含んでいてもよい。

群識別情報は、空間内に配備された複数の照明装置がn群に分割されること、及びそれぞれの照明群が異なる動作を行うことを識別するための情報である。

群識別情報は、図1を参照して上述した照明群を識別するための情報として使用されてもよい。

群識別情報が「ALL」の場合、全ての照明群が同じライブラリを実行することを示していてもよい。

ライブラリ識別情報は、制御装置20がそれぞれの照明装置に特定のライブラリに従って動作するように指令を与える場合に含まれる情報である。

例えば、制御装置20が制御メッセージ「library 002 operation」を送信する場合、照明装置は、ライブラリ識別情報の中から「002」を実行する。

照明装置が複数の群に分割される場合は、照明装置50は、構成された群番号に従って動作してもよい。

例えば、同様に、第1の照明群「GROUP1」に属する照明装置50が、制御装置20からコマンドメッセージ「library 002 operation」を受信する場合、照明装置50は、対応するパターン「R / GRAD_10 / B / Repeat 60」を実行してもよい。

さらに、第2の照明群「GROUP2」に属する照明装置50が、制御装置20からコマンドメッセージ「library 002 operation」を受信する場合、照明装置50は、対応するパターン「B / GRAD_30 / G / Repeat 60」を実行してもよい。

さらに、第3の照明群「GROUP3」に属する照明装置50が、制御装置20からコマンドメッセージ「library 002 operation」を受信する場合、照明装置50は、対応するパターン「G / GRAD_30 / R / Repeat 60」を実行してもよい。

「StartTime」は、ライブラリが実行される時間に対応する情報を示してもよい。

「StartTime」が「NULL」の場合は、対応するライブラリが制御装置20の制御メッセージの表示に従って動作することを意味する。

パターン（pattern）は、光源ユニット56が発する光の色、発光時間、反復期間、または点滅または消灯期間を示してもよい。R、G及びBは、それぞれ、赤、緑及び青を示す。

光源ユニット56が光をより精密に調整できる場合は、光源ユニット56は、R、G及びBを組み合わせることによって得られる色を出力してもよい。RGB256色の表示の場合、1バイト（8ビット）は、R、G及びBのそれぞれについて定義されてもよく、そうしてRGBを定義すると、RGBを表示するには3バイトが要求され得る。

光源ユニット56によって出力される光の色は、RGB、R/G/Bまたは特定のバイナリ数字または16進法の数字等の様々な型に構成されてもよい。

さらに、光源のオン／オフと持続時間（秒）は一緒に記録されてもよい。さらに、反復の回数や反復時間が「REPEAT」として構成されてもよい。

「GRAD」は、光源ユニット56によって出力される光が、グラデーションで光を徐々に変化させるパターンを有することを意味する。具体的態様において、第1の照明群のライブラリ「002」が「R / GRAD_10 / B / REPEAT_60」であり、これは、照明装置50によって出力される光の色が10秒間グラデーションで赤から青に変化され、その変化が60回反復される（または60秒間反復される）ことを意味する。「BLINK」は、点滅することを示す。

さらに、図12には図示されないが、「明滅」が、「点滅」の速度よりも速い速度で点滅することを示してもよい。

図13A及び図13Bは、本明細書に開示する具体的態様に従う、制御メッセージの反復受信に従って、照明装置がタイミングを制御する例を説明する模式図である。

制御メッセージは、ブロードキャスト方式において、中継器40を経由して照明装置50に送信されてもよい。ブロードキャスト方式ではなくユニキャスト方式を使用する場合は、送信装置30は、照明装置50から、送信した制御メッセージの受領に対応する確認応答（ack）メッセージを受信する必要がある。この場合において、確認応答メッセージが多数の照明装置から受信される場合は、コミュニケーション状態が悪化する場合がある。

従って、本明細書に開示する具体的態様においては、送信装置30は、制御メッセージをブロードキャスト方式で照明装置50に送信する。

図13を参照すると、送信装置30は、特定のライブラリの実行コマンドを示す制御メッセージを5回反復して照明装置50に送信してもよい。

送信装置30は、第0番～第4番の制御メッセージ1301～1305を照明装置50に連続して送信してもよい。

この第0番～第4番の制御メッセージ1301～1305は、所定期間内に照明装置50に連続して送信されてもよい。

第0番～第4番の制御メッセージ1301～1305の各々は、同じライブラリ識別情報を含んでいてもよい。ただし、それぞれの制御メッセージは異なる連続番号を有し得る。

例えば、第0番～第4番の制御メッセージ1301～1305が連続して送信される時、連続番号は1増加する。

連続番号は、連続して送信された制御メッセージ間の送信間隔を示していてもよい。それぞれの制御メッセージの送信間隔は0.4秒でもよいが、これは単なる例示である。

この5個の制御メッセージ1301～1305が連続して送信される理由は、制御メッセージの送信がコミュニケーション状態次第で行われない可能性がある状態における、それぞれの照明群間または照明群の照明装置間の微妙なタイミングの違いさえも制御するためである。

この制御メッセージの送信の脱落は、照明装置50が制御メッセージを受信できないことを示していてもよい。

図13Bを参照すると、1ライブラリの実行時間中に照明装置50によって実行されるべきパターンが、グラフで示されている。

1ライブラリの実行時間を3秒と想定すると、照明装置50は、（1303と1305を参照する）青と緑を出力しないが、1秒間徐々に強くなる赤を出力し、その後残りの2秒間その出力を維持する（1301）。

最初の0.5秒間を拡大して説明する。

第1の赤のパターングラフ1331は、第1の照明装置が第0番の制御メッセージ1301を受信する場合に、第1の照明装置が、第0番の制御メッセージ1301に従って赤い光を徐々に増加させて出力することを示している。

第2の赤のパターングラフ1333は、第2の照明装置が第0番の制御メッセージ1301と第1番の制御メッセージ1302を受信できない場合に、第2の照明装置が、第2番の制御メッセージ1303に従って赤い光を徐々に増加させて出力することを示している。

第3の赤のパターングラフ1335は、第3の照明装置が第0番～第2番の制御メッセージ1301～1303を受信できない場合に、第3の照明装置が、第3番の制御メッセージ1304に従って赤い光を徐々に増加させて出力することを示している。

5個の制御メッセージ1301～1305が連続して送信される時間は非常に短く、そのため、たとえ最初の制御メッセージを受信できない照明装置があったとしても、照明装置は、その後の制御メッセージの受信を通してライブラリを直ちに実行することができる。

さらに、この5個の制御メッセージ1301～1305は、送信間隔を示す連続番号を含んでいてもよい。最初のいくつかの制御メッセージを受信していない照明装置50は、制御メッセージに含まれる連続番号を使ってライブラリの実行タイミングを制御してもよい。

連続番号に従って、それぞれの照明装置50の動作間の微妙な時間差が制御され得る。

図14A～図14Cは、本明細書に開示する具体的態様に従う、制御メッセージの反復受信及び同期パケットの受信に従って照明装置がタイミングを制御する例を説明する模式図である。

図14A～図14Cにおいて、1ライブラリの実行時間は3秒と想定している。

さらに、ライブラリの実行コマンドを示す5個の制御メッセージの束が再送パケット1400であると想定している。5個の制御メッセージについては、図13A及び図13Bを参照して説明した。

再送パケット1400の送信後、送信装置30は、同期パケット1410をそれぞれの照明装置に各々の所定期間内に送信してもよい。さらに、同期パケットは、それぞれの照明装置50がライブラリの実行にうまく従っているか否かをチェックするためのパケットであってもよい。

同期パケットは、ライブラリの1時点の情報と、それぞれの照明装置50の間で動作の同期を一致させるために対応する1時点において実行されるべきパターンの情報とを含んでいてもよい。

図14Aは、第1の照明装置が再送パケット1400と同期パケット1410を受信してライブラリに対応するパターンを出力するグラフを示す。

図14Bは、第2の照明装置が、再送パケット1400の受信はできないが第1の同期パケット1410は受信し、第1の同期パケット1410を受信した時点からライブラリに対応するパターンを出力するグラフを示す。

図14Bに図示するとおり、第2の照明装置が再送パケット1400を受信できない場合でも、第2の照明装置は、それに続く第1の同期パケット1410という手段により、第1の同期パケット1410を受信した時点からライブラリを実行し得る。

図14Cは、第3の照明装置が、再送パケット1400と第1の同期パケット1410を受信するが第2の同期パケット1430を受信できずに、対応するパターンをライブラリに出力するグラフを示す。

図14Cに図示するとおり、第3の照明装置が第2の同期パケット1430を受信できない場合でも、第3の照明装置は、先に受信した再送パケット1400という手段により、ライブラリを適切に実行し得る。

上述の通り、本明細書に開示する具体的態様に従えば、照明装置50がライブラリを実行するための制御メッセージを受信できない場合でも、照明装置50は同期パケットという手段により直ちにライブラリを実行し得るので、他の照明装置と効果的に同期を一致させることができる。

次に、照明装置の動作モードを説明する。

図15は、本明細書に開示する具体的態様に従う、照明装置の電源をオンにした時の初期化動作を説明する模式図である。

以下、照明装置50の動作モードが、RFモード1510と、BLEモード1530と、独立（スタンドアロン）モード1550とを含むと想定する。

RFモード1510は、ZigBeeのようなコミュニケーションプロトコルを使って中継器40とのコミュニケーションを行うためのモードであってもよい。

BLEモード1530は、低出力のBluetoothモジュールを使ってモバイル端末60とのコミュニケーションを行うためのモードであってもよい。

独立モード1550は、外部装置とコミュニケーションすることなく、光源ユニット56の出力をオン／オフに変更できるモードであってもよい。

図15を参照すると、照明装置50の電源をオンにすると、照明装置50はRFモード1510で動作する。

5秒後、照明装置50の動作モードは、RFモード1510からBLEモード1530に切り替わってもよい。再び、25秒後、照明装置50の動作モードは、BLEモード1530からRFモード1510に切り替わってもよい。

照明装置が、サイクルをn回反復してもモバイル端末60とBLE接続できないか、中継器から「Heartbeat MSG」メッセージを受信できない場合は、照明装置50の動作モードが独立モード1550に切り替わってもよい。

照明装置50の動作モードが電源の初期化工程において変更される理由は、複数のRFのスタックを使う場合にRFプロトコルを同時に使用するのは不可能なため、動作モードを変更することで興行に参加できるかどうかを判断することにある。

次に、図16を説明する。

図16は、本明細書に開示する具体的態様に従う、演出の類型に基づく照明装置の動作過程を説明するフローチャートである。

図16を参照すると、照明装置50は、RFモード下で興行準備メッセージを受信する（S1601）。

具体的態様において、照明装置50は、中継器40から制御装置20を経由して興行準備メッセージを受信してもよい。

興行準備メッセージは、独立モードへの切替えを遮断するためのメッセージであってもよい。ユーザーが興行ホールに入場して、独立モードで照明装置50を動作させることによりライブラリとは別個に動作を行う場合は、照明装置経由の演出は適切に実行されない可能性がある。

そのため、興行準備メッセージがそれぞれの照明装置50に送信されて、ユーザーが照明装置50を任意に制御するのを妨げてもよい。

興行準備メッセージの受信に従って、照明装置50は、独立モードへの切換えを遮断する（S1603）。

具体的態様において、照明装置50は、興行準備メッセージの受信に従って、RFモードからBLEモードに切り替えられてもよい。この理由は、照明装置50がライブラリデータまたはシナリオデータをモバイル端末60から受信すべき状況が起こり得るためである。

照明装置50は、興行類型が興行準備メッセージに含まれる興行識別子に基づく総合演出であるか否かを判断する（S1605）。

具体的態様において、興行類型が総合演出である場合は、全ての照明装置は、制御装置20の制御下で集合的に制御されてもよい。この場合において、照明装置50がライブラリデータを保存する必要はない。その理由は、制御装置20によって送信されるメッセージが照明装置50の詳細な動作内容（光出力のオン／オフ）を含んでいてもよいからである。

興行類型が総合演出の場合は、照明装置50は、RFモードで動作する（S1607）。

従って、照明装置50は、制御メッセージを制御装置20から受信する準備をする。

興行類型が個別演出の場合は、照明装置50は、興行準備メッセージに含まれる協調識別子が保存されているか否かを判断する（S1609）。

興行類型が個別演出の場合は、照明装置50は、興行準備メッセージに含まれる協調識別子が保存ユニット52のライブラリデータに保存されているか否かを検索してもよい。

興行準備メッセージに含まれる協調識別子が保存されている場合は、照明装置50はRFモードで動作する（S1607）。

協調識別子が興行準備メッセージに保存されていない場合は、照明装置50は、対応する協調識別子を含むライブラリデータをモバイル端末60から取得する（S1611）。

つまり、図8の具体的態様に従えば、照明装置50は、ライブラリデータをモバイル端末60から受信してもよい。

次に、照明装置50と照明装置50を乗せることができる受台が互いに連結されているか否かによる照明装置50の動作を説明する。

図17A及び図17Bは、本明細書に開示する具体的態様に従う、照明装置と受台とが互いに連結されていない場合における照明装置の動作を説明する模式図である。

受台1700は、照明装置50が受台1700に乗せられている場合に、外部から提供される電源を照明装置50に供給できる装置であってもよい。

図17Aを参照すると、照明装置50と受台1700は互いに分離され、照明装置50の電源はオフの状態である。

図17Bを参照すると、照明装置50と受台1700は互いに分離され、照明装置50の電源はオンの状態である。照明装置50は、電源オン状態で独立モードで動作する場合は、4種類の応援モードをサポートできる。

4種類の応援モードは、照明装置50上にそれぞれ提供される複数のボタン58a～58dに対応していてもよい。

複数のボタン58a～58dのいずれか1つが選択されると、照明装置50は、選択されたボタンに対応する応援モードで動作するように、光源ユニット56の動作を制御してもよい。

次に、照明装置50と受台1700とが互いに連結されている場合の照明装置50の動作を説明する。

図18A及び図18Bは、本明細書に開示する具体的態様に従う、照明装置と受台とが互いに連結されている場合における照明装置の動作過程を説明する模式図である。

特に、図18Aは、照明装置50と受台1700は互いに連結されているが、モバイル端末はその周辺に存在しないという想定で、動作過程を説明する。

照明装置50と受台1700が互いに連結されている場合、照明装置50は、受台1700がそこに接続されていることを示す光パターンを出力してもよい（S1801）。

その後、照明装置50がBLEモード（具体的には、ビーコンモード）を動作させてもよく、また、AltBeaconプロトコルを使って、ブロードキャスト方式において外部にビーコン信号を送信してもよい（S1803）。

図18Bを参照すると、動作S1801とS1803の実行後、照明装置50は、ビーコン信号に応答して、モバイル端末60に接続されてもよい（S1805）。

照明装置50がモバイル端末60に接続される場合は、照明装置50は、ウェルカムサインを示す光を出力してもよい（S1807）。

モバイル端末60が照明装置50に接続される場合は、モバイル端末60は、ウェルカムサインを示す光を出力するためのコマンドを照明装置50に送信してもよい。

その後、照明装置50は、ビーコン信号認識領域から外れるまで待機する（S1809）、つまり、照明装置50は、モバイル端末60がその周辺に存在しないことを認識し、そして、モバイル端末60がその周辺に存在しない場合は、照明装置50は、所定の時間待機する（S1811）。

以下、中央サーバが、それぞれの照明装置が興行時間の間に使用する全演出のデータを生成する工程を説明する。

図19は、本明細書に開示する他の具体的態様に従う、中央サーバの構成を説明するブロック図である。

本明細書に開示する他の具体的態様に従う中央サーバ1900は、キャンバスメーカ1910と、ライブラリコンバータ1920と、ライブラリスライサ1930と、データベース1940と、コミュニケーションユニット1950と、ディスプレイユニット1960と、プロセッサ1970とを含んでいてもよい。

キャンバスメーカ1910は、興行の座席マップを生成してもよい。

キャンバスメーカ1910は、座席マップを構成する複数の座席の各々に対するチケット識別子をマップしてもよい。チケット識別子は、座席を識別するための座席番号であってもよい。

複数の座席の各々を1ピクセルと呼んでもよい。

具体的態様において、キャンバスメーカ1910は、データベース1940に保存された座席マップの画像を取得してもよく、また、取得した画像を使って座席マップを生成してもよい。

他の具体的態様において、キャンバスメーカ1910は、拡張現実装置を通して得た画像を使って座席マップを生成してもよい。

これは後述する。

ライブラリコンバータ1920は、動く画像を使って照明装置を通して実行されるべきドットアニメーションを生成してもよい。

ライブラリスライサ1930は、生成したドットアニメーションに基づいて興行時間にそれぞれの照明装置が出力すべき光パターンの情報を含む演出データを生成してもよい。

演出データは、それぞれのピクセルによって表現されるべき色またはカラーパターン、その色を表現するための所要時間及びそのカラーパターンを表現するための所要時間の情報を含んでいてもよい。

演出データは、上記のライブラリデータに含まれていてもよい。

ライブラリスライサ1930は、それぞれのピクセルに、それぞれのピクセルに対応する演出データを与えてもよい。

データベース1940は、座席マップ、演出データ、ライブラリに対応するライブラリデータ、シナリオに対応するシナリオデータ及びライブラリを駆動するファームウェアを保存してもよい。

コミュニケーションユニット1950は、ライブラリデータまたはシナリオデータをモバイル端末60に送信してもよい。このために、コミュニケーションユニット1950は、モバイルコミュニケーションモジュールを備えていてもよい。

コミュニケーションユニット1950は、ライブラリデータまたはシナリオデータを制御装置20に送信してもよい。このために、コミュニケーションユニット1950は、非シールドツイストペア（UTP）ケーブルを使ってデータを制御装置20に送信してもよい。

ディスプレイユニット1960は、演出データ、ライブラリデータ及びシナリオデータを生成するのに必要な画面を表示してもよい。

プロセッサ1970は、中央サーバの動作全般を制御してもよい。

プロセッサ1970は、演出データを含むライブラリデータと、複数個のライブラリデータを含むシナリオデータを生成してもよい。

さらに、図19のキャンバスメーカ1910、ライブラリコンバータ1920及びライブラリスライサ1930は、別個の構成として説明されているが、これは単なる例示にすぎず、上記の構成はプロセッサ1970の構成に含まれていてもよい。

図20は、本明細書に開示する他の具体的態様に従う、中央サーバの動作方法を説明するフローチャートである。

以下、キャンバスメーカ1910、ライブラリコンバータ1920及びライブラリスライサ 1930が、プロセッサ1970の構成に含まれていると想定して説明する。

図20を参照すると、プロセッサ1970は、座席マップを取得する（S2001）。

具体的態様において、プロセッサ1970は、データベース1940に保存された興行座席の配置を示す座席マップの画像を使って座席マップを取得してもよい。

座席マップは、複数のピクセル群を含んでいてもよい。複数のピクセル群は、それぞれ、複数の照明群50-1～50-nに対応していてもよい。

複数のピクセル群の各々は、複数のピクセルを含んでいてもよい。

座席マップの画像は、観客の座席を区別するための点を含んでいてもよい。プロセッサ1970は、全ての点の中のいくつかの点を指定するための入力に従って指定されたいくつかの点を1ピクセル群として生成してもよい。

他の具体的態様において、プロセッサ1970は、拡張現実装置を通して撮像した画像を使って座席マップを生成してもよい。プロセッサ1970は、いくつかの角度で興行ホールの画像を撮像することによって得たそれぞれの画像についてピクセル群を指定するための入力を受信してもよい。

プロセッサ1970は、指定された入力に従って複数のピクセル群を含む座席マップを取得してもよい。

図21は、本明細書に開示する具体的態様に従い取得された、座席マップを説明する模式図である。

図21を参照すると、座席マップ2100が図示されている。座席マップ2100は、複数のピクセル群を含んでいてもよい。

複数のピクセル群の任意の1つ2110は、複数のピクセルを含んでいてもよい。複数のピクセルは、それぞれ、複数の座席に対応していてもよい。具体的に、複数のピクセルは、それぞれ、複数の照明装置に対応していてもよい。

中央サーバ1900のディスプレイユニット1960は、座席マップ2100を編集するための編集メニュー2130を表示してもよい。編集メニュー2130は、ピクセル群2110を編集するためのメニューであってもよい。

ピクセル群2110は、1つの照明群を示していてもよい。

編集メニュー2130は、ピクセル群2110の形状、配置、コピー及び消去等のピクセル群2110の編集のためのメニューであってもよい。

シナリオを設計する場合は、興行主が座席マップを使ってシナリオを設計してもよい。

一方、本明細書に開示する他の具体的態様に従い、プロセッサ1970が、座席の位置及び高さを考慮して3D座席マップを生成してもよい。

一般的な座席マップは空から見た平面の様式であるが、演技者と観客が垂直の光パターンを見るためには、光パターンを歪めることが必要である。

プロセッサ1970は、座席の位置をGPSモジュールを使って取得してもよく、また、座席の高さをバロメーターを使って取得してもよい。

プロセッサ1970は、平面形状の座席マップにおけるそれぞれの座席から取得されたそれぞれの座席の位置と高さを反映することによって、座席マップを変更してもよい。従って、照明装置による光出力パターンの出力は、観客または舞台上で演技する演技者の視点から修正されてもよい。

再び図20を参照して説明する。

プロセッサ1970は、動く画像を使ってドットアニメーションを生成する（S2003）。

具体的態様において、ドットアニメーションは、複数の照明装置によってドットとして時間経過に従って出力されるべき光パターンを示すアニメーションであってもよい。

本明細書に開示する他の具体的態様に従えば、プロセッサ1970は、動く画像というよりも連続的な画像の組合せを使用するドットアニメーションを生成してもよい。

図22及び図23は、本明細書に開示する具体的態様に従う、ドットアニメーションを説明する模式図である。

プロセッサ1970は、動く画像から抽出された画像フレームから複数のピクセルを抽出してもよい。

プロセッサ1970は、複数の抽出されたピクセルのそれぞれの色を検知してもよく、また、検知された色を256色のいずれか1色に変換してもよい。256色は、主な使用色としてあらかじめ選択されており、1バイトを有するインデックスタイプを有している。

これは、照明装置の光源ユニットによって出力される色の微妙な変化を肉眼で感知するのは難しいことから、色の解像度を下げることによってデータサイズを小さくするためである。

プロセッサ1970は、変化した色を複数のピクセルに与えることによって、ライブラリを構成するためのドットアニメーションを生成してもよい。

図22は、生成したドットアニメーションの1場面2200を示す。つまり、複数のピクセルの各々は、特定の色を表現するための1ドットに対応する。実際には、特定の色は、ピクセルに対応する照明装置によって出力されるべき光の色である。

図23は、それぞれのピクセルが生成されるドットアニメーションを構成するフレームに従って、それぞれのピクセルによって表現されるべき色を示す。

再び図20を参照して説明する。

プロセッサ1970は、生成したドットアニメーションに基づいて座席マップを構成する複数のピクセルに演出データを与える（S2005）。

具体的態様において、演出データは、対応するピクセルによって表現されるべき色、カラーパターン及びカラーパターンの出力期間の情報を含んでいてもよい。

光装置の視点から、情報は、照明装置の光源ユニット56によって出力されるべき光の色と光の出力パターンの情報であってもよい。

演出データは、ライブラリデータに含まれていてもよい。

以下、各ピクセルによって出力されるべきカラーパターンを検知する工程を詳細に説明する。

図24は、本明細書に開示する具体的態様に従う、照明装置により出力されるべき光のカラーパターンを検知する工程を説明するフローチャートである。

図24を参照すると、中央サーバ1900のプロセッサ1970は、動く画像のフレームをサンプリングし（S2401）、サンプリングしたフレームのためのフレーム画像を取得する（S2403）。

フレーム画像は、上述のドットアニメーションを構成していてもよい。

プロセッサ1970は、それぞれのフレーム画像から複数のピクセルを抽出し（S2405）、複数の抽出したピクセルのそれぞれの色を256色に変換する（S2407）。

プロセッサ1970は、この変換後の256色に基づいてピクセルのカラーパターンを検知する（S2409）。

具体的態様において、ピクセルのカラーパターンは、オン／オフパターン、点滅パターン、呼吸パターン及び明滅パターンのいずれか1つであってもよい。

点滅パターンは、2色が交互にかつ反復して出力されるパターンであってもよい。

呼吸パターンは、色の変遷の期間が反復して出力されるパターンであってもよい。

明滅パターンは、2色が交互にかつ反復して出力され、また、各色の出力間隔が点滅パターンのものよりも短いパターンを示していてもよい。

点滅パターン、呼吸パターン及び明滅パターンは、変遷パターンの下位概念のパターンであってもよい。

以下、ステップS2409におけるカラーパターンを検知する工程を詳細に説明する。

図25は、本明細書に開示する具体的態様に従う、ピクセルのカラーパターンを検知する工程を説明するフローチャートである。

図25は、図24のステップS2409を詳細に説明する模式図である。

中央サーバ1900のプロセッサ1970が、ピクセルの継続する色を抽出する（S2511）。

プロセッサ1970は、時間経過に従ってピクセルの同一色が継続的に検知されるか否かを判断してもよい。

これは図26及び図27を参照して説明する。

図26及び図27は、本明細書に開示する具体的態様に従う、ピクセルの色の継続性を抽出する工程を説明する模式図である。

図26を参照すると、動く画像から抽出されたフレーム画像2600が描かれている。

プロセッサ1970は、フレーム画像2600をドットアニメーション2610に変換してもよい。

変換されたドットアニメーション2610は、複数のピクセル群を含んでいてもよい。

複数のピクセル群は、それぞれ、上述の複数の照明群50-1～50-nに対応していてもよい。

プロセッサ1970は、ドットアニメーションを使って時間軸に従ってピクセルの色を抽出してもよい。

色の継続性は、ピクセル群2611に含まれる任意の1ピクセル2611に基づいて決定されてもよい。

図27は、時間軸に従って抽出されたピクセル2611aの色の実際の変化を示す第1の色変化図2710である。

プロセッサ1970は、ピクセル2611aの色を256色のいずれか1色に変換してもよい。プロセッサ1970は、256色の中から、最もその色との類似性が高い1色を選択してもよい。

第2の色変化図2730は、ピクセル2611aの色が256色のいずれか1色に変換されている状態を示す。

プロセッサ1970は、第2の色変化図2730を通して所定時間（例、1秒間）に同一色がいくつ検知されるかを決定してもよい。そのような方法を通して、色の継続性を決定してもよい。

ステップS2511は、継続する色の色データを圧縮するための第1の圧縮工程と名付けてもよい。

再び図25を参照して説明する。

その後、プロセッサ1970が、色の継続性を決定した後に、色が変遷するか否かを決定する（S2513）。

ステップS2513は、継続する色の変遷のデータを圧縮するための第2の圧縮工程と名付けてもよい。

さらに、具体的態様において、色の変遷を決定する工程は、ピクセルから抽出した色を256色のうち1色に変換する工程の前に実行してもよい。

具体的態様において、プロセッサ1970は、コサイン類似度技術を使って色が変遷するか否かを決定してもよい。コサイン類似度技術は、2つのベクトル間の角度のコサイン値を使って2つのベクトル間の類似性の程度を決定する技術であってもよい。

ここで、ベクトルは、ピクセルのRGB値に対応していてもよい。

コサイン類似度技術を使って色の変遷を決定する工程は、図28を参照して説明する。

図28は、本明細書に開示する具体的態様に従い、コサイン類似度技術を使って色の変遷を決定する工程を説明する模式図である。

図28を参照すると、ピクセル色群2810は時間経過に従うピクセルの色を示していてもよい。つまり、ピクセル色群2810は、時間経過に従って、フレーム画像の1ピクセルから抽出した色を示す。

ピクセル色群2810は、10フレーム画像における1ピクセルについての色の変化を示す。

色値群2830は、10色の各々に対応するR、G及びBの値を示す。

色の差分値群2850は、先の色のR値と次の色のR値の間の差を示す第1の値と、先の色のG値と次の色のG値の間の差を示す第2の値と、先の色のB値と次の色のB値の間の差を示す第3の値を含んでいてもよい。

上記第1、第2及び第3の値は、1つのベクトルを構成していてもよい。

コサイン類似度群2870は、先のベクトルと次のベクトルの間に形成される角度のコサイン値を使って計算したコサイン類似度を示す群である。

コサイン類似度は、コサイン類似度計算式2895によって計算されてもよい。

プロセッサ1970は、コサイン類似度の変化を使って、色の変遷が行われたか否かを決定してもよい。

コサイン類似度の値が参照値よりも小さい場合は、プロセッサ1970が、色の変遷が行われたと決定する。ここで、参照値は、色の変遷を決定するための基準値であり、0.9であってもよいが、これは単なる例示である。

第4の時間について計算したコサイン類似度の値が0.388の場合は、プロセッサ1970は、色の変遷が対応する時間に行われたと判断してもよい。

プロセッサ1970は、10色を第1の変遷群2891と第2の変遷群2893に分類してもよい。

時間経過に従い変化したピクセルの色の情報を保存するためには、大容量の保存スペースが必要である。

本明細書に開示する具体的態様に従えば、色の変遷は256色を使って決定されるので、色データのサイズを顕著に小さくすることができる。

再び図25を参照して説明する。

プロセッサ1970は、色の変遷が反復して出力される期間を取得する（S2515）。

具体的態様において、色の変遷の反復期間が、後でカラーパターンを決定するのに使用されてもよい。

色の変遷の反復期間は、図27の第2の色変化図2730を参照して説明する。

第2の色変化図2730を参照すると、赤が最初の1秒間検知され、そして黒が次の1秒間検知される。さらに、その赤が次の1秒間検知され、そしてその黒が次の1秒間検知される。

プロセッサ1970は、色の変遷が反復して出力される期間が2秒（T）であると決定してもよい。

その後、プロセッサ1970は、1取得期間における色彩比を取得する（S2517）。

色彩比は、1期間内に検知した色の全頻度に対する特定の色の頻度の比率を示していてもよい。

図27を参照すると、1期間内に、赤は10回抽出されていてもよく、また、黒は10回抽出されていてもよい。この場合、色彩比は1:1である。

プロセッサ1970は、取得した色彩比に基づいてカラーパターンを抽出する（S2519）。

S2515～S2519の動作は、カラーパターンのデータを圧縮するための第3の圧縮工程と名付けてもよい。

プロセッサ1970は、取得した色彩比に基づいて、点滅パターン、明滅パターン及び呼吸パターンのいずれか1つを抽出してもよい。

具体的には、プロセッサ1970は、色の変遷の反復期間と色彩比に基づいて、カラーパターンを抽出してもよい。

例えば、1反復期間内に第1の継続色が1回検知され、それ以外の継続色が9回検知された場合、つまり、色彩比が1:9の場合は、プロセッサ1970はカラーパターンが明滅パターンであると決定してもよい。

他の例として、1反復期間における10色が、5回の第1の継続色と5回のそれ以外の継続色を含む場合、つまり、色彩比が1:1の場合は、プロセッサ1970はカラーパターンが点滅パターンであると決定してもよい。

次に、抽出したカラーパターンを使って、デジタル色データをアナログ色データに変換する工程を説明する。

図29は、本明細書に開示する具体的態様に従い抽出したカラーパターンが呼吸パターンである場合のRGB値の変化を示すグラフあり、図30は、本明細書に開示する具体的態様に従い抽出したカラーパターンが点滅パターンである場合のRGB値の変化を示すグラフある。

図29を参照すると、第1のグラフ2910は、時間軸に従ったデジタルRGB値を示す。

第1のグラフ2910は、光出力パターンが呼吸パターンであることを示す。

プロセッサ1970は、デジタルRGB値をアナログRGB値に変換してもよい。第2のグラフ2930は、時間軸に従ったアナログRGB値を示す。

図30を参照すると、第3のグラフ3010は、時間軸に従ったデジタルRGB値を示す。

第3のグラフ3010は、光出力パターンが点滅パターンであることを示す。

プロセッサ1970は、デジタルRGB値をアナログRGB値に変換してもよい。第4のグラフ3030は、時間軸に従ったアナログRGB値を示す。

一方、プロセッサ1970は、エラーが発生するフレームのデジタル色データを修正してもよい。

図31は、本明細書に開示する具体的態様に従う、エラーが発生するフレームの色データを修正する工程を説明する模式図である。

図31は、抽出したカラーパターンが点滅パターンであると仮定して工程を説明する。

図31を参照すると、第5のグラフ3110は、時間軸に従うデジタルRGB値を示す。第5のグラフ3110において、G値が第1の部分3111から突き出す現象が発生し、また、R値が第2の部分3113から突き出す現象が発生している。

第1の部分3111または第2の部分3113に見られるように、隣接する色値と異なるパターンが発生する場合は、プロセッサ1970は、対応する部分を修正してもよい。

つまり、対応する色値が、決定したカラーパターンに従うことができない場合は、プロセッサ1970が対応する色値を修正して、対応する色値が決定したカラーパターンに従うようにしてもよい。そのような作業は、アップグレード作業と名付けてもよい。

修正結果に従って、アナログRGB値を示す第6のグラフ3130を取得してもよい。

図32は、本明細書に開示する具体的態様に従う、制御装置がシナリオまたはライブラリを編集するためのシナリオ編集画面を説明する模式図である。

図32は、図32のシナリオ編集画面3200が制御装置20によって表示される画面であると想定してシナリオ編集画面を説明するが、シナリオ編集画面は必ずしもこれに限られず、シナリオ編集画面は、中央サーバ1900によって表示され得る画面であってもよい。

シナリオ編集画面3200は、ライブラリリスト3210と、座席マップ3220と、プレイリスト3230と、複数のライブラリ3251、3253、3255、3257及び3259を含むシナリオ3250とを含んでいてもよい。

ライブラリリスト3210は、シナリオを構成するための複数のライブラリを含んでいてもよい。

ライブラリリスト3210は、固定項目3211とカスタム項目3213とを含んでいてもよい。

固定項目3211は、デフォルトとして構成されるライブラリを含んでいてもよい。

カスタム項目3213は、興行主の意図に従って設計されたライブラリを含んでいてもよい。例えば、カスタム項目3213は、文字列または歌手を示すロゴとして歌手の名前を実行するためのライブラリを含んでいてもよい。

座席マップ3220は、図20を参照して上述した通りに取得した座席マップである。

プレイリスト3230は、ライブラリリスト3210から選択される1以上のライブラリを再生するためのリストであってもよい。

プレイリスト3230には、実際の興行において照明装置によって実行されるべき1以上のライブラリが表示されていてもよい。

興行主は、プレイリスト3230内の任意の1ライブラリを再生するためのコマンドに従って、ライブラリを実行する工程をシミュレーションしてもよい。

さらに、具体的態様において、任意の1ライブラリがプレイリスト3230から選択された場合は、制御装置20は、選択したライブラリを実行するための制御メッセージを生成してもよい。生成された制御メッセージは、上述の通り、照明装置に送信されてもよい。

シナリオ3250は、1曲の歌の再生区間に対応していてもよい。シナリオ3250は、複数のライブラリ3251、3253、3255、3257及び3259を含んでいてもよい。

複数のライブラリがユーザーの入力に従って選択された場合は、制御装置20は、選択されたライブラリを組み合わせることによって1つのシナリオ3250を生成してもよい。

複数のライブラリ3251、3253、3255、3257及び3259の各々は、プレイリスト3230に含まれるライブラリであってもよい。

第1のライブラリ3251は、全ての照明装置の光源ユニット56が、歌の開始から1分間電源をオフすべきことを示していてもよい。

第2のライブラリ3253は、全ての照明装置の光源ユニット56が、第1のライブラリ3251の実行後2分間電源をオンにすべきことを示していてもよい。

第3のライブラリ3255は、全ての照明装置の光源ユニット56が、第2のライブラリ3253の実行後3分間明滅動作を実行すべきことを示していてもよい。

第4のライブラリ3257は、全ての照明装置の光源ユニット56が、第3のライブラリ3255の実行後5分間歌手のロゴを表現する光を出力すべきことを示していてもよい。

第5のライブラリ3259は、全ての照明装置の光源ユニット56が、第4のライブラリ3257の実行後1分間電源をオフにすべきことを示していてもよい。

上述の通り、1つのシナリオ3250は、第1～第5のライブラリ3251、3253、3255、3257及び3259の組合せを通して完成されてもよい。

一方、第3のライブラリ3255が選択された場合は、制御装置20は、第3のライブラリ3255の詳細情報を示すポップアップウィンドウ3270を表示してもよい。

ポップアップウィンドウ3270は、第3のライブラリ3255に関して、開始時間、終了時間、持続時間、光出力パターンの期間、出力光の色及び出力カラーパターンに関する1以上の情報を含んでいてもよい。

興行主は、シナリオ編集画面3200を通してシナリオの全ての事項を編集してもよい。

本明細書が開示する具体的態様を構成する全ての構成要素を組み合わせて1つにしたり、組み合わせて動作させたりすることを説明したが、本明細書の開示は、必ずしもそのような具体的態様に限定されるものではなく、本明細書の開示の目的の範囲内で全ての構成要素のうち1以上を選択的に組み合わせて動作させてもよいものである。

さらに、全ての構成要素の各々が1個の独立したハードウェアとして実施されてもよいが、構成要素の一部または全てを選択的に組み合わせて、1組以上のハードウェアの組合せの一部または全ての機能を実行するプログラムモジュールを有するコンピュータプログラムとして実行してもよい。コンピュータプログラムを構成するコード及びコードのセグメントは、本明細書の開示に関係する分野の当業者によって容易に推論し得るものである。

そのようなコンピュータプログラムは、コンピュータで読み取り可能な媒体（Computer Readable Media）に保存されてもよく、また、コンピュータによって読み出されかつ実行されて本明細書に開示する具体的態様を実施してもよい。コンピュータプログラムの保存媒体は、磁気記録媒体、光学記録媒体及び半導体記録装置を含む保存媒体を含む。さらに、本明細書に開示する具体的態様を実施するコンピュータプログラムは、現実の時間に外部装置を経由して送信されるプログラムモジュールを含む。

本明細書の開示は、本明細書に開示する具体的態様に言及して説明されているが、様々な改変や変更が通常の技術を有する技術者の水準で適用され得るものである。従って、そのような改変や変更は、本明細書の開示の精神および技術範囲から逸脱するのでない限り、本明細書に開示する技術範囲内に含まれることが理解されるであろう。

Claims (15)

1. 中央サーバであって、
   照明装置によって実行されるライブラリに対応するライブラリデータを保存するように構成されたデータベースと、
   前記ライブラリデータをユーザーのモバイル端末に送信するように構成されたコミュニケーションユニットと、
   興行ホールの座席マップを取得して、前記座席マップを構成する複数のピクセルの各々に、前記複数のピクセルの各々によって表現されるカラーパターンの情報を含む演出データを与えるように構成されたプロセッサとを有することを特徴とする、中央サーバ。
2. 前記プロセッサは、画像から抽出したフレーム画像の組合せであるドットアニメーションを生成して、生成した前記ドットアニメーションから前記ピクセルの色を抽出するように構成されていることを特徴とする、請求項１に記載の中央サーバ。
3. 前記プロセッサは、前記抽出した色を２５６色の中で前記抽出した色に最も似ている色に変換するように構成されていることを特徴とする、請求項２に記載の中央サーバ。
4. 前記プロセッサは、前記変換した色の継続性を決定し、かつ、前記色の前記継続性を決定した後に、前記継続した色の変遷が行われているか否かを決定するように構成されていることを特徴とする、請求項３に記載の中央サーバ。
5. 前記プロセッサは、コサイン類似度技術を使って、先の色のＲＧＢ値と次の色のＲＧＢ値の変遷が行われているか否かを決定するように構成されていることを特徴とする、請求項４に記載の中央サーバ。
6. 前記プロセッサは、前記色の前記変遷が反復して出力される期間と前記期間における色彩比を取得するように構成され、かつ、
   前記色彩比は、前記期間内に検知された色の全頻度に対する特定の色の頻度の比率を示すことを特徴とする、請求項５に記載の中央サーバ。
7. 前記プロセッサは、前記色の前記変遷が反復して出力される前記期間と前記色彩比に基づいて、前記カラーパターンを抽出するように構成されていることを特徴とする、請求項６に記載の中央サーバ。
8. 前記カラーパターンは、点滅パターン、明滅パターン及び呼吸パターンのうちのいずれか１つであることを特徴とする、請求項７に記載の中央サーバ。
9. 前記複数のピクセルは、それぞれ、複数の照明装置に対応し、各々が、前記カラーパターンに対応する光パターンを出力することを特徴とする、請求項１に記載の中央サーバ。
10. 前記ライブラリデータは、前記ライブラリを識別するためのライブラリ識別情報、光源ユニットによって出力される光の色または明るさを示す情報及び前記光源ユニットによって出力される光パターンの情報を有することを特徴とする、請求項１に記載の中央サーバ。
11. 興行システムであって、前記興行システムは、
    ライブラリを生成するように構成された中央サーバと、
    前記ライブラリの実行コマンドを示す制御メッセージを生成するように構成された制御装置と、
    生成された前記制御メッセージを送信するように構成された送信装置と、
    ブロードキャスト方式において、前記送信装置から受信した前記制御メッセージを伝達するように構成された複数の中継器と、
    前記ライブラリに対応するライブラリデータを保存し、かつ、前記中継器から受信した前記制御メッセージに従って、保存された前記ライブラリデータを使用して前記ライブラリを実行するように構成された複数の照明装置とを有するものであって、
    前記中央サーバは、興行ホールの座席マップを取得して、前記座席マップを構成する複数のピクセルの各々に、前記複数のピクセルの各々によって表現されるカラーパターンの情報を含む演出データを与えるように構成されていることを特徴とする、興行システム。
12. 前記中央サーバは、画像から抽出したフレーム画像の組合せであるドットアニメーションを生成し、かつ、生成された前記ドットアニメーションから前記ピクセルの色を抽出するように構成されていることを特徴とする、請求項１１に記載の興行システム。
13. 前記中央サーバは、前記抽出された色を２５６色の中で前記抽出した色に最も似ている色に変換するように構成されていることを特徴とする、請求項１２に記載の興行システム。
14. 前記中央サーバは、前記変換した色の継続性を決定し、かつ、前記色の前記継続性を決定した後に、前記継続した色の変遷が行われているか否かを決定するように構成されていることを特徴とする、請求項１３に記載の興行システム。
15. 前記中央サーバは、
    前記色の前記変遷が反復して出力される期間と前記期間における色彩比を取得するように構成され、かつ、
    前記色の前記変遷が反復して出力される前記期間と前記色彩比に基づいて、前記カラーパターンを抽出するように構成されていることを特徴とする、請求項１４に記載の興行システム。
    

Images