情報送信システム
【課題】遊園地等の施設において、乗り物・催事等に関する満空情報・待ち時間情報等をリアルタイムにユーザに供給する情報送信システムを提供する。
【解決手段】施設内の個別情報を収集して整理するサーバＳと、サーバが収集した施設内の個別情報を、携帯端末向けの地上デジタル放送波に変換して送信する送信装置３をもつ情報送信システム。
【解決手段】施設内の個別情報を収集して整理するサーバＳと、サーバが収集した施設内の個別情報を、携帯端末向けの地上デジタル放送波に変換して送信する送信装置３をもつ情報送信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、地上デジタル放送波等の一般的な電波方式による地域限定放送（エリア放送）を用いた情報送信システムに関する。
【背景技術】
【０００２】
従来、遊園地等の施設では多数の乗り物、催事、飲食店などのサービスが提供され、各提供サービスの混雑、満空情報、待ち時間情報が、各提供サービスごとに入口付近に設置された掲示板や従業員による口頭伝達で提供されている。
この方法によれば、来場者は各サービスの入口付近においては、これらの情報を入手することが可能となる。
【０００３】
しかし、この方法では、来場者が各提供サービスへ移動し、掲示板を探して確認するか、付近にいる従業員に問合せて確認する必要があるため、例えば来場者が混雑の少ないサービスを第１優先として希望している場合、１箇所ずつ移動して確認する必要があるため膨大な時間と労力がかかる問題があるとともに、全体の状況を比較検討して選択することは極めて困難である。
【０００４】
また来場者が断片的な情報しか知り得ないことにより、混雑の偏りが生じるとともに来場者の誘導など従業員の負担の増加や運営費用のコストアップにつながる問題がある。
また、本発明に関連する技術として、テーマパークにおいて無線放送手段からリアルタイム情報（時々刻々変化するアトラクションの待ち時間情報等）を送信する電子案内情報処理システム等が知られる（特許文献１参照）。
【０００５】
また、画像処理により来場特性情報を検出し、過去に検出した来場特性情報に基づいて（つまり学習により）待ち時間を予測する駐車待ち時間案内システムが知られる（特許文献２参照）。
また、迷子が迷子になる以前は迷子検索依頼者（例えば親）と一緒に行動していることを前提にし、迷子の検索の依頼があったとき、迷子検索依頼者自身の映像をもとに、本人の認証を行ない、記録情報を検索し、依頼者との関連において検索依頼があった迷子を検索する迷子検索・監視システムが知られる（特許文献３参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−１２３６４０号公報（第１９７段落）
【特許文献２】特開平１０−１５４２９９号公報
【特許文献３】特開２００４−１５１８２０号公報（第６段落）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、従来の情報送信システムでは、１箇所ずつ移動して確認する不便があったり、運営費用が増加したりするという問題がある。また、特許文献１に記載の電子案内情報処理システムにおいても、持参した携帯端末装置でデジタル地上波等の放送基盤から受信した情報を利用可能であるものの、簡単な操作手順で短時間に必要な情報にたどりつけるための十分な考慮がされていない。使い慣れた携帯電話等を用いるとしても、バッテリー切れを心配する入場者にとっては利用しがたいものがある。
【０００８】
本発明の実施形態は、遊園地等の施設において、乗り物・催事等に関する満空情報・待ち時間情報等をリアルタイムにユーザに提供することで、行列にならばなくともアトラクションを楽しめる情報送信システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
課題を解決するための一実施形態は、
施設内の個別情報を収集して整理するサーバＳと、サーバが収集した施設内の個別情報を、携帯端末向けの地上デジタル放送波に変換して送信する送信装置３をもつ情報送信システムである。
【発明の効果】
【００１０】
すなわちこの発明の実施形態によれば、遊園地等の施設において、乗り物・催事等に関する満空情報・待ち時間情報等を、地上デジタル放送等の信号に載せてリアルタイムにユーザに知らせることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態である情報送信システムの構成を示すブロック図。
【図２】同じく情報送信システムの情報提供エリアの一例を示す説明図。
【図３】同じく情報送信システムに含まれる番組編集装置の構成の一例を示す説明図。
【図４】同じく情報送信システムの周辺機器を含めた構成の一例を示す説明図。
【図５】同じく情報送信システムの乗物情報の画面表示の一例を示す説明図。
【図６】同じく情報送信システムの乗物情報の画面表示の一例を示す説明図。
【図７】同じく情報送信システムの飲食店情報の画面表示の一例を示す説明図。
【図８】同じく情報送信システムの総合案内情報の画面表示の一例を示す説明図。
【図９】同じく情報送信システムの情報送信処理の一例を示すフローチャート。
【発明を実施するための形態】
【００１２】
図１は、本発明の実施形態にかかる情報送信システムの全体構成図である。図１の情報送信システム１は、有線伝送路として光ファイバーを利用した場合の構成例を示しており、基本的には、「エリアワンセグ（エリア限定ワンセグ）」と呼ばれるものと同様である。
サーバＳは、サービスを提供している各所の情報をリアルタイムで処理及び集積し、アトラクションデータベース（アトラクションＤＢ）を参照して、番組として提供する情報データ（多くはテキストデータ）を生成する。各所の情報とは例えば、待っている人の行列に沿って所定間隔に設置される人感センサの信号、整理券（電子的に発行されるものも含む）の発券数及び実際にアトラクションに入場できた人数のカウンター数、等である。またアトラクションＤＢには、各アトラクションの容量（単位時間当たりに入場可能な人数）等が保持されている。既存の、イベント情報を管理するサーバ（ＤＢ）や、迷子・落し物情報を集約するサーバ等も、サーバＳの一部を構成しうる。大規模災害時の避難誘導用等、規定の内容の番組を予め保持する構成を備えても良い。
【００１３】
番組編集装置２は、サーバＳからの情報データを自動的に番組に編集する。本実施形態では、番組は後述するように６つあり、各番組は、映像信号、音声信号、字幕データ、ＢＭＬコンテンツ、等から構成され、これらが、番組特定情報（ＰＳＩ）と共に、ＡＲＩＢ ＳＴＤ−Ｂ３２等の規定に従い、一旦番組毎にＴＳ多重化される。それら６個のＴＳストリームを必要に応じ多重し、ＤＶＢ−ＡＳＩインタフェース、或いはＩＰパケットにカプセル化した上でEthernet（登録商標）インタフェースで出力する。
【００１４】
送信装置３は、番組編集装置２から入力されたＴＳストリームを、ＡＲＩＢ ＳＴＤ−Ｂ３１等の規定に従い、携帯端末向け地上デジタルテレビ放送波（ＩＳＤＢ−Ｔ方式）或いは地上デジタルラジオ放送波（ＩＳＤＢ−ＴＤＢ方式）の信号（高周波信号）に変換する。すなわち６／１４ＭＨｚ（約４２９ＭＨｚ）の帯域幅のＯＦＤＭセグメント（ワンセグ物理チャンネルと呼ぶ）を複数（望ましくは１３以下）個連結した帯域（物理チャンネル）を用いて、６番組を送信する。
【００１５】
その後、ヘッドアンプ４によりチャネル波形整形とレベルバランスを適宜整えて供給する。さらに、Ｅ／Ｏ（Electronic Optical）変換装置５によりアナログ変調光信号に変換し、光分配装置６により複数の伝送路７に供給する。サービスを提供している各所ではこれをＯ／Ｅ（Optical Electronic）変換装置８により高周波信号に変換し、電力増幅器９で増幅後、送信アンテナ１０より送信する。来場者は携帯端末により地上デジタル放送波を受信状態とし、専用チャネルを選択することで、情報提供を受けることができる。
【００１６】
図２は、情報提供エリアの構成の一例を示したもので、情報提供エリアは施設内での分類（地区、ゾーン）に対応させた複数のブロックとして構成する。図２では、ブロック毎に１つの送信アンテナを設置するように示してあるが、全ての送信アンテナから同一の放送波信号を送信しているので、送信アンテナの設置位置はブロックと無関係でよい。その代わり、各ブロックでは入場者自身がどのブロック内にいるのか認識できるような標識や、ブロック情報を発信する近距離通信機等を設置する。
【００１７】
図３は、番組編集装置２の内部構成図である。
ネットワークインタフェース（ネットＩ／Ｆ）１０１は、施設内ＬＡＮ或いはインターネットに接続するためのＩ／Ｆであり、サーバＳとの通信（ソケット通信）を実現する。
電子発言ＡＰＩ１０２は、インターネット上の電子発言サーバにアクセスするためのアプリケーション・プログラミング・インタフェースであり、例えばTwitter（登録商標）APIである。電子発言ＡＰＩ１０２は、施設運営者等のユーザ名（アトラクション毎に複数あってもよい）で電子発言サーバにログインし、定期的にタイムライン（過去の発言の一覧）を取得する。
【００１８】
番組生成部１０３は、番組編集装置２の全体的な制御をするアプリケーションソフトであり、サーバＳから取得した満空情報、待ち時間等のテキスト情報を並び替え等し、番組構成に従ったタイミングで字幕装置１０５等に展開する。また、他の番組編集装置等で制作された番組をネットワークを介して取得し、字幕装置１０５等に展開する。
【００１９】
字幕装置１０５は、図６乃至図８に示した各画面（動画像）を生成する装置であり、番組生成部１０３からのテキスト情報等を表として描画し、指示によってはスクロールさせながら、画面サイズ＝３２０×２４０（或いは３２０×１８０）、約１５フレーム／秒の映像として出力する。本実施形態の特徴として、スクロールの速さは１ピクセル／フレームに固定とし、スクロール時にはその旨を示す信号（スクロール量信号）も別途出力する。
【００２０】
音声合成部１０７は、番組生成部１０３から字幕データとして出力されたテキストを、合成音声により読み上げて、音声信号として出力する。字幕ＰＥＳ化部１０４は、番組生成部１０３からの字幕データをＰＥＳパケット化して出力する。
ＢＭＬ生成部１０９は、番組生成部１０３からのテキスト情報等に基づき、携帯端末で番組動画像と共に視聴（表示）可能なＢＭＬ（Broadcast Markup Language）コンテンツを生成し、それらをＤＳＭ−ＣＣデータカルーセル（及びイベントメッセージ）にして出力する。ＢＭＬは、基本的にはデータ放送運用規定Ｃプロファイルに従う。コンテンツは、電子発言ＡＰＩ１０２が取得した電子発言、或いは字幕装置１０５が描画する画面と同様の乗物情報等であり、これらが、４８０×２４０画素のデータ放送仮想プレーンに表示されることを想定してＢＭＬ化される。
【００２１】
記憶部１１１は、コンテンツの元データ（ＧＩＦファイル）を記憶しており、それら元データをＢＭＬ生成部１０９に提供する。
Ｈ．２６４エンコーダ１０６は、ＡＲＩＢ ＳＴＤ−Ｂ３２ 第１部付属３「低解像度映像サービスにおけるＭＰＥＧ−４ ＡＶＣ規格の運用ガイドライン」に従い、字幕装置１０５からの映像信号をなるべくリアルタイムで映像符号化し、さらにＰＥＳパケット化して出力する。出力ビットレートはピーク時でも２００ｋｂｐｓ程度である。本実施形態の特徴として、携帯端末での復号化処理を極限まで簡素化するために、エンコーダの動作を下記のように拘束する。
第１拘束：スクロール中信号がないときは、ＩＤＲピクチャに続く所定数のＰピクチャ以外のＰピクチャ（Ｐスライス）は全てスキップする。
第２拘束：Ｐピクチャで動き補償をするときは、その単位を１６×１６画素に固定する。
第３拘束：スクロール中信号がないときは動きベクトルを０に固定し、該信号があるときは１（下向き）に固定する。
第４拘束：デブロッキングフィルタは使用しない。
第５拘束：４×４画面内予測（Ｉ４ＭＢ）では、予測モード６〜８を使用しない、或いはなるべく使用しない。
【００２２】
上記した第１拘束については、ＩＤＲピクチャだけでは予測残差が完全に符号化できないため、所定数（０〜３程度）のＰピクチャは残すようにしたものである。
上記した第５拘束については、デブロッキングフィルタは、ブロックノイズをぼやかすものであり、不鮮明な文字を鮮明にする効果はほとんど無いので使用しない。
このように拘束することで、静止画時は実質の符号化（復号化）フレーム数自体が１／１０程度に減り、スクロール時においても復号処理の半分近くを占めるループ内フィルタを不要にできる。
【００２３】
ＭＰＥＧ２ＡＡＣエンコーダ１０８は、音声合成部１０７からの音声信号をなるべくリアルタイムで音声符号化し、更にＰＥＳパケット化して出力する。
カルーセル送出部１１０は、ＢＭＬ生成部から書き込まれたカルーセルデータをバッファし、それを順次セクション化して出力する。
ＰＳＩ・独立ＰＥＳ生成部１１２は、ＰＳＩ／ＳＩ（Program Specific Information／Service Information）、独立ＰＥＳ（タイムスタンプ等）等を生成し、ＰＳＩ／ＳＩはセクション化した上で出力する。
ＴＳ多重化部１１３は、字幕ＰＥＳ化部１０４、Ｈ．２６４エンコーダ１０６、ＭＰＥＧ２ＡＡＣエンコーダ１０８、カルーセル送出部１１０、ＰＳＩ・独立ＰＥＳ生成部１１２の出力を、１８８バイトのＴＳパケットへ多重化し、ＴＳとして出力する。なお、ＩＤＲピクチャ以外のタイミングではＨ．２６４エンコーダ１０６からのビットレートは非常に小さくなる。ＴＳ多重化部１１３からのＴＳを受け取った送信装置３では、所定のタイミングにＴＳが受け取れなかったときは、空の伝送ＴＳＰ（ＡＲＩＢ ＳＴＤ−Ｂ３１伝送方式で規定される２０４バイトのＴＳパケット）を挿入することになっている。
【００２４】
ＴＳインタフェース部１１４は、ＴＳ多重化部１１３からのＴＳを伝送装置３に出力するためのインタフェースであり、ＴＳをＲＦＣ３９５４に従いストリームとしてパケット化するか、或いはＴＳを所定単位でファイルとみなしてＦＴＰ等によりＩＰ伝送してもよく、放送用機器で一般的なＤＶＢ−ＡＳＩやＤＶＢ−ＳＰＩ等を用いても良い。
【００２５】
以上説明したように、本実施形態では番組映像の特性を利用して復号処理を削減できるように符号化して放送するので、番組視聴によるバッテリー切れの心配が軽減し、入場者が安心して視聴できる。
また、電子発言をデータ放送に含めて放送することで、入場者視点での情報を得ることができるようになる。なお、携帯端末９においてデータ放送用仮想プレーンや映像仮想プレーン、字幕仮想プレーンを画面（表示領域）上にどのように配置するかは任意であり、画面の大部分にデータ放送用仮想プレーンを配置して、鮮明な表示により乗物情報等を見ることもできる。
【００２６】
図４は、本実施形態の情報送信システムのサーバ部周辺の構成図である。後述する各装置が、互いに通信可能に構内ＬＡＮで接続されている。発券・入場管理サーバ２０１は、遊園地への入場券の予約状況や発券状況を把握するとともに、発券した入場券による入場状況を把握するサーバである。入場券は例えばＲＦ−ＩＤタグであり、券ごとにユニークなＩＤが付されており、発券・入場管理サーバ２０１はそのＩＤにより入場状況を管理したり、他の情報と関連付けて各種処理を行う。
【００２７】
入出園ゲート２０２は、入園者（客）、退園者の保持する入場券のＩＤを読み取り、発券・入場管理サーバ２０１に通知すると共に、発券・入場管理サーバ２０１からの応答に基づきゲートの開閉を制御する。アトラクションゲート２０４は、各アトラクション毎に、利用客、一般客ごとに設置され、アトラクション入場前の客の入場券のＩＤを読み取り、発券・入場管理サーバ２０１に通知するとともに、発券・入場管理サーバ２０１からの応答に応じて所定の顕示等を行う。
【００２８】
ＩＰカメラ２０５は、各アトラクションやレストラン、休憩場所、入出場ゲートの外、駐車場等に１乃至複数設置され、それらの映像を撮影し、圧縮して送出する。画像処理装置２０６は、ＩＰカメラ２０５からの圧縮映像を受信し、画像認識処理により客の混雑状況や、行列の人数等を検出する。
【００２９】
サーバＳは、図１のサーバＳに相当するものであり、本実施形態では主に以下の処理を行う。
第１処理：発券・入場管理サーバ２０１からの情報（予約数、実入園者数）、外部から取得した気象状況、暦、画像処理装置２０６からの混雑状況情報等と、過去統計データベースとから、その日の入園者数推移を時間別に予測する。予測は定期的に更新し、また実入園者数によりデータベースも更新する。
第２処理：予測入園者数と、遊園地容量とに基づき、入園者に勧めるべきアトラクション数の適正値を算出する。
第３処理：適正アトラクション数に基づき、モデルプランを複数生成し、入園者に提供するとともに、提供状況を管理する。モデルプランは、現時刻から閉園時刻までに搭乗するアトラクション、及びそれらの集合時刻が記載されており、提供状況は提供を受けた客の入場券ＩＤ毎に管理する。
第４処理：各アトラクション等の現在の一般客と利用客の混雑状況、及びプラン提供状況等に基づき、現在以降の各アトラクション待ち状態（待ち人数、待ち時間）の推移を、一般客と利用客それぞれについて予測する。これは入園者数の予測同様に行う。この結果、アトラクション待ち状況によってはモデルプランを修正、変更する。また各アトラクションに対して、興行１回当たりの一般客と利用客の望ましい比率を連絡する。
第５処理：モデルプラン提供状況に基づき、各利用客に対し、集合時刻の所定時間前に通知を行う。また、実際のアトラクションゲート２０４の通過時刻はモデルプランにおける時刻とずれてくるので、利用客個々に対して以降のプランを修正（カスタマイズ）して提供する。
【００３０】
図５は、送信情報の一実施形態を示すもので、全域情報とブロック情報の２つの情報区分とし、それぞれ乗物情報、飲食店情報、総合案内情報を提供するものであり、必要送信チャネル数は６となる。１セグメントに１チャネルを付与し、これらを束ねて６セグメントを送信する技術を用いて実現するか、１／２或いは１／３セグメントあたりに１チャネル（サブチャンネルと呼ぶ）を付与し、合計３或いは２セグメントを束ねて送信する技術等を用いて実現する。
【００３１】
携帯端末９は、上述のような構成のセグメントに対して物理チャンネルをチューニングでき、所望の番組のＴＳストリームを取り出して再生できる（多セグメント対応と称する）必要がある。必要に応じて、施設内チャネル専用の端末を貸し出すことで、情報提供の平等化を図ることができる。この貸与端末は、例えば特殊器具で無いと燃料補給できない燃料電池による駆動とし、入場者が持ち帰っても使えないようにするとよい。
【００３２】
また、ブロックごとの狭域エリア構成とすることにより、全域の情報を受け取ることができる他、来場者がブロック情報を受信すれば現在いる近隣の情報を即座に受け取ることが可能となる。すなわち、ブロック情報にはチャンネル設定情報も含まれており、それをＱＲコード（登録商標）リーダやＦｅｌｉｃａ（登録商標）の通信機能等により受信すると、（半）自動的にワンセグチューナを起動し、指定されたチャンネルにチューニングする。
【００３３】
図６は乗物情報の画面表示の一例である。図６の画面は全域情報（図中では「全域放送」と表記している）の場合のもので、施設内全体の乗り物について、乗物名と地図上の位置（地区地図番号）、待ち時間、優先搭乗券の発行時間の情報が、所定の並び、例えば待ち時間順に表示される。地区地図番号のアイウ…はブロックに１対１対応している。
【００３４】
図７は飲食店情報の画面表示の一例を示すもので、店名と提供内容、地図上の位置、満空情報、満席の場合の待ち時間の情報が表示される。図８は総合案内情報の画面表示の一例を示すもので、イベント開催状況と時間、地図上の位置、その他注意事項等が表示される他、迷子・落し物情報と預かり場所、地図上の位置が表示される。
【００３５】
これらの画面表示は情報量が多い場合にはリアルタイムのスクロールまたは、定時スクロールで表示される。
ブロック内情報については、全域情報と同様の情報が、ブロックごとに待ち時間順等にソートされ、ブロック毎に独立した情報として表示される。もし利用者が自分のいるブロックを指定する操作等を携帯端末に行うと、指定されたブロックの情報のみを繰り返し表示するようになる。
【００３６】
（第１実施形態）
本実施形態は、遊園地において、入場者にアトラクション等のプラニングを提供する機能を付加した情報送信システムの一形態を説明するものであり、送信部分の構成は先に説明した図１の情報送信システムと同様である。
遊園地では、客はより多くのアトラクションを楽しもうとして、常にどこかの待ち行列に並ぼうとする傾向がある。その結果、待ち時間が長くなり、入園時間の多くを行列に並ぶこと、或いは行列の短いアトラクションを探して彷徨うことに費やすようになる。
【００３７】
本実施形態では、並ばなくても乗れることを保証し、客が行列に並らばないように誘導することで待ち時間を短縮し、その分遊園地内の自由行動時間が増えることで顧客満足を向上でき、また客の密度が遊園地内で分散することで遊園地の容量を最大限まで高めることを目的とする。
【００３８】
なお本実施形態では、説明を簡単にするためにアトラクションは全て乗り物であるとして、アトラクションを利用することを「搭乗」と言うことにする。また本システムのプラニングを利用する客を利用客、利用しない客を一般客と呼ぶ。
次に、図９のフローチャートを用いて、本実施形態の情報送信システムの動作を、１人の利用客Ａに注目して説明する。
【００３９】
［ステップＳ１］入場券には、予約番号や期間契約者番号等を客が入力できるようにする入力部を有しており、予約番号等が入力されたときは、発券・入場管理サーバ２０１に問い合わせて照合し、発券を行う。入場券には、入場券ＩＤを数字（文字）化した一部か、入場券ＩＤを照合可能な文字列（例えば、入場券ＩＤを一方向性関数処理し、ＵＲＬエンコードして得られる文字列）の全部又は一部を印字する。印字される数字や文字列は、グループ客が同一プランを希望する操作のために用意され、ランダムでかつその日の入園客一人ひとりを特定するのに必要な桁数を有することが望ましい。
【００４０】
予約番号等の入力がされなかったときも、上記と同様であるが、更に、上記照合可能文字列を含むサーバＳのＵＲＩを表す２次元バーコードも入場券に印刷すると良い。
［ステップＳ２］利用客Ａが入出園ゲート２０２から入場すると、発券・入場管理サーバ２０１は、把握している実入園者数を１増やす。発券・入場管理サーバ２０１は、その日の実入園者数を推移を分単位で記録する。
【００４１】
［ステップＳ３］利用客Ａの入場と前後して、利用客Ａの携帯端末は、携帯電話パケット通信網を介してサーバＳへの（間接的な）アクセスを行う。この目的は、サーバＳが利用客Ａの携帯端末を特定するための識別子を取得すること、ならびに携帯端末に対して本実施形態の情報送信システムが放送しているワンセグのチャンネルを通知しチューナを起動させることである。端末識別子としては、ＨＴＴＰリクエストのＸ−ＤＣＭＧＵＩＤヘッダやＸ−ＵＰ−ＳＵＢＮＯヘッダにある情報が利用できる。
【００４２】
携帯端末は、２次元バーコード読み取り機能を用いて、サーバＳにアクセスする。或いは周知されたサーバＳのホームページにアクセス後、印字された照合可能文字を直接入力してもよい。
サーバＳは、入場券ＩＤの正当性（発券時刻から有効期間以内か等）を発券・入場管理サーバ２０１に適宜問い合わせて検査し、不当であれば携帯端末からのリクエストを無視し、正当であれば携帯端末に、メディア起動記述を含んだページ(ＨＴＭＬかＢＭＬ)を送付する。このページにＣプロファイル準拠のＢＭＬを使えば、Ｃプロファイルリンクコンテンツ或いは非リンクコンテンツとなる。これを受信した携帯端末は、ユーザの操作により或いは自動でチューナを起動し、メディア起動記述に記載された物理チャンネルにチューニングする。
【００４３】
［ステップＳ４］サーバＳは、メールアドレスの送信或いは（空の）メールの送信を求めるページ(ＨＴＭＬ)も携帯端末に送信する。携帯端末はそれに応答して送信を行う。事前の予約により、端末識別子に対応するメールアドレスが既知である場合などでは、このステップＳ４は行わない。
【００４４】
［ステップＳ５］サーバＳは、ステップＳ２〜Ｓ３で得た情報を、一旦利用客ＤＢに格納する。利用客ＤＢは、入場券ＩＤをキーとし、端末識別子、メールアドレス、プランデータ、要求不成功プラン情報、プラン実時刻データ、通知識別情報等を保持する。入場券ＩＤと端末識別子は１対１である必要は無く、複数人の客が１つの携帯端末を共用してもよい。
【００４５】
［ステップＳ６］サーバＳは、前述の第１処理に相当する処理を行う。つまり、外部から取得した気象状況、暦、発券・入場管理サーバ２０１から取得した当日の入園者数推移（実績）等に近いデータを、過去統計ＤＢから検索する。過去統計ＤＢには、過去の全営業日の或いは典型的な入園者数推移が、気象状況、暦等と共に保持されている。検索により見つかるデータは当日の実入園者数とは完全に一致しないので、検索データでの入園者数推移と実入園者数との比で補正する他、予約数や駐車場等の混雑状況情報、キャンペーンの効果等を考慮して検索データを補正することで、当日のこれからの予測入園者数推移として用いることができる。
【００４６】
［ステップＳ７］サーバＳは、前述の第２処理に相当する処理を行う。最も単純なモデルでは、各アトラクションの単位時間当たりの搭乗客数の合計を遊園地容量とし、（当日の現在以降の入園者数推移の平均値）×（当日の現在以降の営業時間）÷遊園地容量により、適正アトラクション数を算出する。
【００４７】
［ステップＳ８］サーバＳは、前述の第３処理に相当する処理を行う。遊園地の全アトラクション数をｎとし、そこからｍ個（ｍはｎ以下の整数）を選ぶ順列の総数はnＰmであり、搭乗アトラクション数ｍは利用客の好みに拠るから、順列の総数は莫大であり、これらの総数から所定数のモデルプランを選ぶ組み合わせ全てをシミュレーションするのは非現実的である。
【００４８】
従って、まず総数を数千程度に絞ったモデル候補群をｍ毎に準備する。このモデル候補群Ｇmは、含まれる各モデルの直交性（同じ時間にモデルＡが割り振るアトラクションとモデルＢが割り振るアトラクションが重複しないこと）が高くなるように、過去の客の傾向なども考慮しつつ設計する。これにより、似たような（冗長な）モデルが淘汰され、また、人気度の高いアトラクションを多く含むモデルほど、小さいｍのモデル候補群に集まる傾向になる。
【００４９】
そして、混雑状況情報や天候や当日のモデル提供状況に基づき、モデル候補群から提供すべき数１００〜数１０００パターンのモデルプランを決定する。これらのモデルプランは、希望アトラクション等乗数、希望必須アトラクション、年齢層、性別、歩く速度（歩ける量）、三半規管への刺激、天候を気にするか、等の条件（これら全て必須なわけでは無い）で分類したときに程よく分散すると共に、各モデルが想定される人気度で利用客に利用された状況のシミュレーションにより特定のアトラクションに客が極度に集中しないことを確認しながら、選ばれる。サーバＳは、このモデルプランの情報（各モデルを特定可能なＩＤ等を含む）を番組編集装置２に送信し、番組編集装置２はそれを１モジュールのＢＭＬコンテンツに編集する。一例として、ステップＳ６〜Ｓ８は５分毎に行われ、提供されるモデルプランも１０分毎に定期更新される。
【００５０】
［ステップＳ９］携帯端末は、ステップＳ３で起動したチューナの機能により、指定された物理チャンネルのワンセグ放送の視聴を行う。ワンセグ放送にはステップＳ８で作成されたモデル群のＢＭＬコンテンツが含まれており、利用者は上記条件に相当する質問に答えるだけで、数個程度に絞られた好適なモデルプランにたどり着ける。モデル群のＢＭＬコンテンツは数ＭＢかそれ以上の大きな容量であるが、一旦受信してしまえば、サーバとの交信なしに、条件の変更等の操作に対し瞬時に応答が得られるので、操作性が非常に良い。ＢＭＬコンテンツには有効期限や、１０分間隔で更新される次のコンテンツ（番組）の開始時刻等の情報が含まれており、一旦モジュールを受信した以降は、次の開始時刻まで表示以外のチューナ機能をオフできるようになっている。このような動作は、ＢＭＬコンテンツのＥＣＭＡＳｃｒｉｐｔで利用可能な放送用拡張関数（Browser擬似オブジェクトのメソッド）や、イベントメッセージを用いて実現できる。
【００５１】
［ステップＳ１０］携帯端末は、利用客Ａが選択したモデルプランの情報（モデルＩＤ）を、携帯端末のパケット通信機能によりサーバＳに送信する。この通信機能の開始には、放送用拡張関数を利用できる。送信するモデルＩＤは、１つでもよく、優先順位つきで複数あってもよく、また同伴者の入場券に印刷された照合可能文字列或いは２次元バーコード読み取り結果を１乃至複数指定して、これらの同伴者も同じモデルプランを選択した旨を送信することもできる。
【００５２】
［ステップＳ１１］サーバＳは、ステップＳ１０の選択モデルプラン情報を受信すると、一致する端末識別子があるか、プランデータが空か（選択済みではないか）等を、利用客ＤＢとの照合のよりチェックする。チェックで異常が無く、選択されたモデルＩＤが有効であれば、そのモデルプランに対応するタイムスケジュールを生成し、それらを携帯端末にＨＴＭＬ或いはメール形式して提供するとともに、利用客ＤＢにプランデータとして保存する。
【００５３】
タイムスケジュールは、第４処理で得られるアトラクション待ち状態推移等（特に待ち時間）に基づき、利用客個々に対して分単位のスケジュールとして生成される。また、個々の通知を特定できるようなユニークな通知識別情報も生成し、利用客ＤＢに格納する。携帯端末には、タイムスケジュールと共に、タイムスケジュールの変更等を受け付けるＷｅｂページ（サーバＳが提供する）等のＵＲＩ（通知識別情報を含む）も通知される。利用客ＤＢへのプランデータや通知識別情報の保存は、上記提供（送信）の成功を確認してから行うと良い。
【００５４】
一方、チェック異常や無効モデルＩＤの場合は、所定の応答（例えば上記変更受付ページの案内）をする。特に、利用客ＤＢにプランデータが既に保存されていた場合、プラン変更として扱うが、プラン変更の回数を制限するため、変更の履歴を要求不成功プラン情報に追記する。また特定のモデルプランの選択が極度に集中した場合等も要求不成功となり、要求不成功プラン情報に追記される。
【００５５】
［ステップＳ１２］サーバＳは、前述の第４処理に相当する処理を、ステップＳ６〜Ｓ８同様に５分毎に行う。一般客の待ち状態推移は、入園者数の予測同様に行うことができる。例えば、過去統計ＤＢには入園者数推移だけでなく個々のアトラクションの待ち状態推移も保持しておき、検索により見つかるデータを、実際に画像処理装置２０６が検出した混雑状況情報（行列の長さ、待ち時間）で若干補正して用いる。
【００５６】
一方、利用客の待ち状態推移は、利用客ＤＢ中の全利用客のタイムスケジュールを集計して求める。例えば、ある基準時刻以降の（次の）アトラクションがＡ１である利用客全てについて、基準時刻から、タイムスケジュール上での搭乗予定或いは集合時刻までの時間の平均が、その基準時刻におけるアトラクションＡ１の推定待ち時間である。つまり、本実施形態では利用客の待ち状態推移は、実際に列に並んで待つことではなく、任意の場所でタイムスケジュールに従い行動している利用客の状態を意味している。
【００５７】
ただし、特定のアトラクションＡ２で利用客の列だけが想定以上に長くなった場合に備え、利用客の列でも混雑状況情報の検出をし、ステップＳ８のモデル候補選定に反映させる（直近にＡ２を避けて選定する）ほか、近々にＡ２がスケジュールされている利用客のスケジュールを遅らせる（後述）こともある。
【００５８】
［ステップＳ１３］以下のステップＳ１３〜Ｓ１６は、第５処理にほぼ相当し、プランデータに応じて繰り返される。サーバＳは、利用客ＤＢに保存された各プランデータを１分単位で監視し、将来の直近のスケジュール（集合時刻）の所定時間前に、該当する利用客Ａのメールアドレス宛に、通知メールを送信する。
【００５９】
［ステップＳ１４］利用客は、提供されたプランデータ（タイムスケジュール）に基づき、最初のアトラクションＡ１へ行き、利用客専用の列に並ぶ。利用客専用の列及び一般客用の列の所定の位置にアトラクションゲート２０４がそれぞれ設置されており、サーバＳの第４処理により連絡された人数或いはその比率で、列の客が通過できるようにする。
【００６０】
列が進み、その利用客Ａがアトラクションゲート２０４に達すると、その利用客Ａの入場券を読み取り、通過情報としてサーバＳに通知する。
［ステップＳ１５］サーバＳは、受信した通過情報の利用客ＩＤにより利用客ＤＢのプランデータを参照し、アトラクションＡ１がプランでの未来直近のアトラクションと一致しない場合、或いは、通過時刻がプランより第１所定時間（例えば３０分）以上早く、且つアトラクションＡ１の一般客の待ち時間が第２所定時間（例えば９０分）以上の場合には、その利用客のアトラクションゲート２０４の通過を認めない旨の信号をアトラクションゲート２０４に送信するとともに、通過情報を不許可の旨と共にプラン実時刻データに追記する。またこのタイミングで、この利用客のスケジュールを早めても公平性が損なわれないかどうか、各アトラクションの混雑状況や待ち状態推移を考慮して判定し、問題なければスケジュールを早める修正を行い、修正後のスケジュールを含む通知メールを利用客に送信する。
【００６１】
それ以外の場合は、通過を認める信号をアトラクションゲート２０４に送信し、通過情報をプラン実時刻データに追記し、実際の通過時刻に応じて以降のスケジュールを早めたり遅くしたりして修正する。修正量に関しては、利用客と一般客の公平性が考慮される。公平性としては、不許可の通過情報の記録の回数が所定数に達したときに、スケジュールの前倒し修正を行わないことで実現する方法も考えられる。
【００６２】
このように本実施形態では、プランからどんなに遅れて集合してもプランにそのアトラクションが修正されずに残っている限り、利用客としてそのアトラクションに搭乗できるようになっている。
［ステップＳ１６］アトラクションゲート２０４は、通過を認めない旨の信号を受けると表示、鳴動、ゲートの閉鎖等の所定の動作を行う。それを受けて係員は、例えば、該信号を受けた利用客に対し、利用客の列に並び直すように誘導する。スケジュールを早める修正が行われていれば、利用客は通知メールを受け取り、状況を理解できる。このように、本実施形態ではスケジュールの自動修正は、各利用客の行動に変化があった（アトラクションゲート２０４通過等）ことを契機に行われ、それ以外には、利用客の意志を尊重し自動修正は行わない。また、搭乗後の利用客の管理も特に行わない。
【００６３】
ここで、ステップＳ１１で言及したタイムスケジュールの変更等を受け付けるＷｅｂページを利用したと仮定して、説明を続ける。
［ステップＳ１７］携帯端末は、ステップＳ１１或いはＳ１５で届いた通知メールに記載のＵＲＩに基づき、パケット通信機能を用いてサーバＳにアクセスする。
【００６４】
［ステップＳ１８］サーバＳは、携帯端末からのリクエストに含まれる通知識別情報、端末識別子等を利用客ＤＢと照合する。一致する利用客ＩＤが見つかれば、その利用客ＩＤのプランデータのタイムスケジュールを読み出し、そのタイムスケジュールを操作可能に表示するＷｅｂページのデータを携帯端末に送信する。
【００６５】
［ステップＳ１９］携帯端末は、受信したＷｅｂページを表示し、利用客からの操作を受け付け、最後にその結果をサーバＳに送信する。操作の一例として、現在以降のタイムスケジュールから１つのアトラクションを選び、それを別のアトラクションに変更するような操作が考えられる。変更先のアトラクションの選び方としては、混雑しているアトラクションは抽選方式にしたり、タイムスケジュールの他のアトラクションのキャンセルを要件にしたりする方法が考えられる。
【００６６】
［ステップＳ２０］サーバＳは、混雑状況情報等に基づき、変更が可能か判定し、可能な場合は、その利用客のプランデータを変更して利用客ＤＢに保存するとともに、利用客に変更した旨の通知メールを送信する。
以上説明したステップの中で、セキュリティ上の検討を要するのは、入場券に印字された照合可能文字を用いた利用登録の扱いである。すなわち客自身が登録する前に、第３者が照合可能文字を総当りすることで客に成りすまして登録できないようにする必要がある。一例として、（照合可能文字が長くなってしまうが、）同一の端末識別子の端末からの不正な登録試行に上限を設け、照合可能文字の照合力（正当な値にたどり着ける平均試行数）をその上限より十分高くする方法がある。また、登録前にサーバＳから乱数、及びＧＰＳ等の位置情報取得要求を携帯端末に送り、その乱数と遊園地に相当する位置情報が所定時間内に携帯端末から送り返されたことを以って登録を許可するようにしてもよい。位置情報取得要求は、本システムからＢＭＬで供給する際はX_DPA_getCurPos()、パケット通信網から要求する際は各通信事業者の規定の方法を用いる。
【００６７】
（第２実施形態）
本実施形態の情報送信システムは、上述した実施形態のシステムに、図示しない広告ＰＥＳ生成部を追加して、その出力を図３のＴＳ多重化部１１３に供給し、デジタルサイネージも行うようにしたものである。すなわち、広告ＰＥＳ生成部は、高精細のＪＰＥＧ或いはＰＮＧ画像ファイルや、米国アドビ社のアニメーション形式であるＦｌａｓｈファイル等をＰＥＳ化して出力する。この際ストリームＩＤとしては秘密の（ＰＳＩ／ＳＩからは辿れない）ものを用い、またビットレートは十分抑えられる。ＴＳ多重化部１１３は、広告ＰＥＳ生成部の出力するＰＥＳも多重化する。
【００６８】
大型表示端末は、ワンセグチューナ等を備えた表示装置であり、物理チャンネルや上記秘密のＰＥＳを指定しておけば、送信された画像等を、液晶画面或いは電子ペーパー上に再生表示することができる。大型表示端末での受信環境は安定していると考えられるので、本実施形態ではＰＥＳ多重送出としたが、カルーセル伝送方式を用いてもよい。
【００６９】
（第３実施形態）
本実施形態の情報送信システムは、先の第２実施形態のシステムを、災害時の安否確認に利用したものである。サーバＳは、連絡が取れない肉親等（尋ね人）の携帯電話番号等の登録を受付ける画面のＨＴＭＬを保持しており、災害時時にそれを番組編集装置２に出力して、ＢＭＬコンテンツとして本システムから放送させる。登録する情報は、電話番号のほか、名前、概略的な住所、顔写真等、基本的には尋ね人の情報であるが、登録者の情報でも良い（後述）。そのＢＭＬコンテンツには、そのようにして登録された携帯電話番号のリストを有し、受信した携帯端末がリストから自己の電話番号と一致するものを検索するようなＢＭＬのスクリプト（例えばＥＣＭＡＳｃｒｉｐｔ）やアプリ（例えばＭＩＤＰ等の携帯電話事業者固有のもの）を含んでいる。また携帯端末がこの放送を受信できるよう、避難所などでチャンネル番号や放送時間を掲示等しておく。
【００７０】
携帯端末は、ＢＭＬコンテンツを受信し、操作に応じて電話番号登録画面を表示し、またスクリプト等も実行する。ＢＭＬのスクリプトのみで実現する場合、自己の電話番号は、拡張関数X_DPA_getIRDID()の引き数に１〜３を試行しながら、戻り値の文字列に電話番号らしい文字列（１１桁の数字）が発見できた場合、それを採用する。そしてリストから自己の電話番号を検索し、一致するものがあれば、メール送信の準備として、メール本文の作成及び保存と、X_DPA_getRevCond()による通信機能の状態取得を行う。そして、メール送新可能な通信状態であれば、X_DPA_mailTo()により、指定の宛先（登録者が登録したメールアドレス、或いはサーバＳ）にパケット通信網によりメールが（半）自動的に送信される。メールの本文には、X_DPA_getCurPos()で取得した位置情報や、携帯端末の所有者がその場で撮影した自身の画像、任意のメッセージ等を格納させることもできる。
【００７１】
一方、携帯電話アプリを用いる場合、ＣプロファイルのＢＭＬからはアプリを直接起動できない、アプリでも自己の電話番号は取得できない、等の難しさがあるが、逆に携帯電話の発信履歴やアドレス帳等にアクセスできる利点がある。そこで、リストには登録者の電話番号や氏名を載せ、アプリはそれらと一致するものが発信履歴やアドレス帳にあるか検索し、あったときに、メール自動送信等の所定の動作をするようにする。これにより、登録者は自身に縁のある人の所在等をまとめて知ることができる。
【００７２】
アプリ起動に関しては、ＢＭＬのスクリプトにより、受信した各事業者用のアプリのうち、自己の携帯端末の事業者に一致するものを見つけ、携帯電話のアプリとして保存した後、事業者毎に定めるＵＲＩにあるＨＴＭＬをlaunchExApp()により通信事業者仕様ブラウザで開き、そのＨＴＭＬからアプリを起動するようにする。或いは、ＢＭＬコンテンツにおいて、手動で起動するように促す表示を行う。このアプリには、上記の他、災害時に役立つ種種の機能を持たせることもできる。
【００７３】
サーバＳはまた、登録された尋ね人の情報を番組編集装置２に提供し、番組編集装置２は、提供された尋ね人情報を順次表示するような番組を作成する。この番組は、避難所に設置された大型表示端末や携帯端末で視聴される。尋ね人から応答のメール等があったときは、その旨も番組上で表示し、所定時間後には登録自体を削除する。
【００７４】
（第４実施形態）
本実施形態の情報送信システムは、先の第２実施形態のシステムを、遊園地の乗り物ではなく実際の交通機関に利用した、交通遅延表示システムである。例えば鉄道では、需要予測と運行（遅延）状況がわかれば、乗客にどの程度の影響（足止め時間）が生ずるかが予測でき、またどの振替路線に誘導すべきかの判断材料になる。本実施形態の交通遅延表示システムでは、電子発言サーバはインターネット上ではない独自サーバとし、駅員の業務連絡等に利用する。また、駅員等のためのコンテンツは、限定受信により一般客には視聴できないようにする。一般客へは、遅延情報、振替乗車の案内等の情報を提供する。望ましくは、各鉄道会社の情報を、関東、中部等の地域で１番組に集約して提供する。
【００７５】
（第５実施形態）
本実施形態の情報送信システムは、先の第１実施形態のシステムに、特許文献３のような迷子探索機能を追加したものである。すなわち画像処理装置２０６は顔検知を備え、映像に人が映るとベストショットの顔或いは全身像を抽出し、ＳＩＦＴ特徴量（多次元ベクトルである）等を求めて、サーバＳに送信する。サーバＳは、受信した特徴量（及び抽出画像）を一定期間、画像ＤＢに蓄積する。迷子の関係者（親）が、迷子の特徴を連絡または画像をセンタのサーバＳに提供すると、サーバＳは、提供画像から同様に特徴量を求めるか或いは連絡された特徴（言語で表現される）を特徴量に変換し、特徴量が一致するものを画像ＤＢやカメラのライブ映像から探索する。なお画像として記録収集すると客がプライバシの不安を感じるので、画像処理装置は画像を出力せず、画像ＤＢには特徴量のみ蓄積することが望ましい。
【００７６】
（第６実施形態）
本実施形態の情報送信システムは、先の第５実施形態のシステムに、不審者探索機（連れ去り防止）を追加したものである。画像ＤＢには、不審者の画像或いはその特徴量を登録しておき、特徴量比較により不審者と認識されたら、行動がわかる様追跡する。
【００７７】
また、入出園ゲート２０２等の夫々にＩＰカメラ２０５を設け、入場券を入れて入園する客一人ひとりの画像を取得しておき、入場時と違う人（特に不審者）と一緒に退場しようとした場合には連れ去りと判断してアラーム通知する。判断には幅を持たせて、入場時に一緒にいる前後数名や、大人と子供の組み合わせに限定等の条件を持たせる。
【００７８】
なお、この発明は上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００７９】
Ｓ…サーバ、１…情報送信システム、２…番組編集装置、３…送信装置、４…ヘッドアンプ、５…Ｅ／Ｏ変換装置、６…分配器、７…電力増幅器、８…送信アンテナ、９…携帯端末、１０…送信アンテナ。
【技術分野】
【０００１】
本発明は、地上デジタル放送波等の一般的な電波方式による地域限定放送（エリア放送）を用いた情報送信システムに関する。
【背景技術】
【０００２】
従来、遊園地等の施設では多数の乗り物、催事、飲食店などのサービスが提供され、各提供サービスの混雑、満空情報、待ち時間情報が、各提供サービスごとに入口付近に設置された掲示板や従業員による口頭伝達で提供されている。
この方法によれば、来場者は各サービスの入口付近においては、これらの情報を入手することが可能となる。
【０００３】
しかし、この方法では、来場者が各提供サービスへ移動し、掲示板を探して確認するか、付近にいる従業員に問合せて確認する必要があるため、例えば来場者が混雑の少ないサービスを第１優先として希望している場合、１箇所ずつ移動して確認する必要があるため膨大な時間と労力がかかる問題があるとともに、全体の状況を比較検討して選択することは極めて困難である。
【０００４】
また来場者が断片的な情報しか知り得ないことにより、混雑の偏りが生じるとともに来場者の誘導など従業員の負担の増加や運営費用のコストアップにつながる問題がある。
また、本発明に関連する技術として、テーマパークにおいて無線放送手段からリアルタイム情報（時々刻々変化するアトラクションの待ち時間情報等）を送信する電子案内情報処理システム等が知られる（特許文献１参照）。
【０００５】
また、画像処理により来場特性情報を検出し、過去に検出した来場特性情報に基づいて（つまり学習により）待ち時間を予測する駐車待ち時間案内システムが知られる（特許文献２参照）。
また、迷子が迷子になる以前は迷子検索依頼者（例えば親）と一緒に行動していることを前提にし、迷子の検索の依頼があったとき、迷子検索依頼者自身の映像をもとに、本人の認証を行ない、記録情報を検索し、依頼者との関連において検索依頼があった迷子を検索する迷子検索・監視システムが知られる（特許文献３参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−１２３６４０号公報（第１９７段落）
【特許文献２】特開平１０−１５４２９９号公報
【特許文献３】特開２００４−１５１８２０号公報（第６段落）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、従来の情報送信システムでは、１箇所ずつ移動して確認する不便があったり、運営費用が増加したりするという問題がある。また、特許文献１に記載の電子案内情報処理システムにおいても、持参した携帯端末装置でデジタル地上波等の放送基盤から受信した情報を利用可能であるものの、簡単な操作手順で短時間に必要な情報にたどりつけるための十分な考慮がされていない。使い慣れた携帯電話等を用いるとしても、バッテリー切れを心配する入場者にとっては利用しがたいものがある。
【０００８】
本発明の実施形態は、遊園地等の施設において、乗り物・催事等に関する満空情報・待ち時間情報等をリアルタイムにユーザに提供することで、行列にならばなくともアトラクションを楽しめる情報送信システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
課題を解決するための一実施形態は、
施設内の個別情報を収集して整理するサーバＳと、サーバが収集した施設内の個別情報を、携帯端末向けの地上デジタル放送波に変換して送信する送信装置３をもつ情報送信システムである。
【発明の効果】
【００１０】
すなわちこの発明の実施形態によれば、遊園地等の施設において、乗り物・催事等に関する満空情報・待ち時間情報等を、地上デジタル放送等の信号に載せてリアルタイムにユーザに知らせることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態である情報送信システムの構成を示すブロック図。
【図２】同じく情報送信システムの情報提供エリアの一例を示す説明図。
【図３】同じく情報送信システムに含まれる番組編集装置の構成の一例を示す説明図。
【図４】同じく情報送信システムの周辺機器を含めた構成の一例を示す説明図。
【図５】同じく情報送信システムの乗物情報の画面表示の一例を示す説明図。
【図６】同じく情報送信システムの乗物情報の画面表示の一例を示す説明図。
【図７】同じく情報送信システムの飲食店情報の画面表示の一例を示す説明図。
【図８】同じく情報送信システムの総合案内情報の画面表示の一例を示す説明図。
【図９】同じく情報送信システムの情報送信処理の一例を示すフローチャート。
【発明を実施するための形態】
【００１２】
図１は、本発明の実施形態にかかる情報送信システムの全体構成図である。図１の情報送信システム１は、有線伝送路として光ファイバーを利用した場合の構成例を示しており、基本的には、「エリアワンセグ（エリア限定ワンセグ）」と呼ばれるものと同様である。
サーバＳは、サービスを提供している各所の情報をリアルタイムで処理及び集積し、アトラクションデータベース（アトラクションＤＢ）を参照して、番組として提供する情報データ（多くはテキストデータ）を生成する。各所の情報とは例えば、待っている人の行列に沿って所定間隔に設置される人感センサの信号、整理券（電子的に発行されるものも含む）の発券数及び実際にアトラクションに入場できた人数のカウンター数、等である。またアトラクションＤＢには、各アトラクションの容量（単位時間当たりに入場可能な人数）等が保持されている。既存の、イベント情報を管理するサーバ（ＤＢ）や、迷子・落し物情報を集約するサーバ等も、サーバＳの一部を構成しうる。大規模災害時の避難誘導用等、規定の内容の番組を予め保持する構成を備えても良い。
【００１３】
番組編集装置２は、サーバＳからの情報データを自動的に番組に編集する。本実施形態では、番組は後述するように６つあり、各番組は、映像信号、音声信号、字幕データ、ＢＭＬコンテンツ、等から構成され、これらが、番組特定情報（ＰＳＩ）と共に、ＡＲＩＢ ＳＴＤ−Ｂ３２等の規定に従い、一旦番組毎にＴＳ多重化される。それら６個のＴＳストリームを必要に応じ多重し、ＤＶＢ−ＡＳＩインタフェース、或いはＩＰパケットにカプセル化した上でEthernet（登録商標）インタフェースで出力する。
【００１４】
送信装置３は、番組編集装置２から入力されたＴＳストリームを、ＡＲＩＢ ＳＴＤ−Ｂ３１等の規定に従い、携帯端末向け地上デジタルテレビ放送波（ＩＳＤＢ−Ｔ方式）或いは地上デジタルラジオ放送波（ＩＳＤＢ−ＴＤＢ方式）の信号（高周波信号）に変換する。すなわち６／１４ＭＨｚ（約４２９ＭＨｚ）の帯域幅のＯＦＤＭセグメント（ワンセグ物理チャンネルと呼ぶ）を複数（望ましくは１３以下）個連結した帯域（物理チャンネル）を用いて、６番組を送信する。
【００１５】
その後、ヘッドアンプ４によりチャネル波形整形とレベルバランスを適宜整えて供給する。さらに、Ｅ／Ｏ（Electronic Optical）変換装置５によりアナログ変調光信号に変換し、光分配装置６により複数の伝送路７に供給する。サービスを提供している各所ではこれをＯ／Ｅ（Optical Electronic）変換装置８により高周波信号に変換し、電力増幅器９で増幅後、送信アンテナ１０より送信する。来場者は携帯端末により地上デジタル放送波を受信状態とし、専用チャネルを選択することで、情報提供を受けることができる。
【００１６】
図２は、情報提供エリアの構成の一例を示したもので、情報提供エリアは施設内での分類（地区、ゾーン）に対応させた複数のブロックとして構成する。図２では、ブロック毎に１つの送信アンテナを設置するように示してあるが、全ての送信アンテナから同一の放送波信号を送信しているので、送信アンテナの設置位置はブロックと無関係でよい。その代わり、各ブロックでは入場者自身がどのブロック内にいるのか認識できるような標識や、ブロック情報を発信する近距離通信機等を設置する。
【００１７】
図３は、番組編集装置２の内部構成図である。
ネットワークインタフェース（ネットＩ／Ｆ）１０１は、施設内ＬＡＮ或いはインターネットに接続するためのＩ／Ｆであり、サーバＳとの通信（ソケット通信）を実現する。
電子発言ＡＰＩ１０２は、インターネット上の電子発言サーバにアクセスするためのアプリケーション・プログラミング・インタフェースであり、例えばTwitter（登録商標）APIである。電子発言ＡＰＩ１０２は、施設運営者等のユーザ名（アトラクション毎に複数あってもよい）で電子発言サーバにログインし、定期的にタイムライン（過去の発言の一覧）を取得する。
【００１８】
番組生成部１０３は、番組編集装置２の全体的な制御をするアプリケーションソフトであり、サーバＳから取得した満空情報、待ち時間等のテキスト情報を並び替え等し、番組構成に従ったタイミングで字幕装置１０５等に展開する。また、他の番組編集装置等で制作された番組をネットワークを介して取得し、字幕装置１０５等に展開する。
【００１９】
字幕装置１０５は、図６乃至図８に示した各画面（動画像）を生成する装置であり、番組生成部１０３からのテキスト情報等を表として描画し、指示によってはスクロールさせながら、画面サイズ＝３２０×２４０（或いは３２０×１８０）、約１５フレーム／秒の映像として出力する。本実施形態の特徴として、スクロールの速さは１ピクセル／フレームに固定とし、スクロール時にはその旨を示す信号（スクロール量信号）も別途出力する。
【００２０】
音声合成部１０７は、番組生成部１０３から字幕データとして出力されたテキストを、合成音声により読み上げて、音声信号として出力する。字幕ＰＥＳ化部１０４は、番組生成部１０３からの字幕データをＰＥＳパケット化して出力する。
ＢＭＬ生成部１０９は、番組生成部１０３からのテキスト情報等に基づき、携帯端末で番組動画像と共に視聴（表示）可能なＢＭＬ（Broadcast Markup Language）コンテンツを生成し、それらをＤＳＭ−ＣＣデータカルーセル（及びイベントメッセージ）にして出力する。ＢＭＬは、基本的にはデータ放送運用規定Ｃプロファイルに従う。コンテンツは、電子発言ＡＰＩ１０２が取得した電子発言、或いは字幕装置１０５が描画する画面と同様の乗物情報等であり、これらが、４８０×２４０画素のデータ放送仮想プレーンに表示されることを想定してＢＭＬ化される。
【００２１】
記憶部１１１は、コンテンツの元データ（ＧＩＦファイル）を記憶しており、それら元データをＢＭＬ生成部１０９に提供する。
Ｈ．２６４エンコーダ１０６は、ＡＲＩＢ ＳＴＤ−Ｂ３２ 第１部付属３「低解像度映像サービスにおけるＭＰＥＧ−４ ＡＶＣ規格の運用ガイドライン」に従い、字幕装置１０５からの映像信号をなるべくリアルタイムで映像符号化し、さらにＰＥＳパケット化して出力する。出力ビットレートはピーク時でも２００ｋｂｐｓ程度である。本実施形態の特徴として、携帯端末での復号化処理を極限まで簡素化するために、エンコーダの動作を下記のように拘束する。
第１拘束：スクロール中信号がないときは、ＩＤＲピクチャに続く所定数のＰピクチャ以外のＰピクチャ（Ｐスライス）は全てスキップする。
第２拘束：Ｐピクチャで動き補償をするときは、その単位を１６×１６画素に固定する。
第３拘束：スクロール中信号がないときは動きベクトルを０に固定し、該信号があるときは１（下向き）に固定する。
第４拘束：デブロッキングフィルタは使用しない。
第５拘束：４×４画面内予測（Ｉ４ＭＢ）では、予測モード６〜８を使用しない、或いはなるべく使用しない。
【００２２】
上記した第１拘束については、ＩＤＲピクチャだけでは予測残差が完全に符号化できないため、所定数（０〜３程度）のＰピクチャは残すようにしたものである。
上記した第５拘束については、デブロッキングフィルタは、ブロックノイズをぼやかすものであり、不鮮明な文字を鮮明にする効果はほとんど無いので使用しない。
このように拘束することで、静止画時は実質の符号化（復号化）フレーム数自体が１／１０程度に減り、スクロール時においても復号処理の半分近くを占めるループ内フィルタを不要にできる。
【００２３】
ＭＰＥＧ２ＡＡＣエンコーダ１０８は、音声合成部１０７からの音声信号をなるべくリアルタイムで音声符号化し、更にＰＥＳパケット化して出力する。
カルーセル送出部１１０は、ＢＭＬ生成部から書き込まれたカルーセルデータをバッファし、それを順次セクション化して出力する。
ＰＳＩ・独立ＰＥＳ生成部１１２は、ＰＳＩ／ＳＩ（Program Specific Information／Service Information）、独立ＰＥＳ（タイムスタンプ等）等を生成し、ＰＳＩ／ＳＩはセクション化した上で出力する。
ＴＳ多重化部１１３は、字幕ＰＥＳ化部１０４、Ｈ．２６４エンコーダ１０６、ＭＰＥＧ２ＡＡＣエンコーダ１０８、カルーセル送出部１１０、ＰＳＩ・独立ＰＥＳ生成部１１２の出力を、１８８バイトのＴＳパケットへ多重化し、ＴＳとして出力する。なお、ＩＤＲピクチャ以外のタイミングではＨ．２６４エンコーダ１０６からのビットレートは非常に小さくなる。ＴＳ多重化部１１３からのＴＳを受け取った送信装置３では、所定のタイミングにＴＳが受け取れなかったときは、空の伝送ＴＳＰ（ＡＲＩＢ ＳＴＤ−Ｂ３１伝送方式で規定される２０４バイトのＴＳパケット）を挿入することになっている。
【００２４】
ＴＳインタフェース部１１４は、ＴＳ多重化部１１３からのＴＳを伝送装置３に出力するためのインタフェースであり、ＴＳをＲＦＣ３９５４に従いストリームとしてパケット化するか、或いはＴＳを所定単位でファイルとみなしてＦＴＰ等によりＩＰ伝送してもよく、放送用機器で一般的なＤＶＢ−ＡＳＩやＤＶＢ−ＳＰＩ等を用いても良い。
【００２５】
以上説明したように、本実施形態では番組映像の特性を利用して復号処理を削減できるように符号化して放送するので、番組視聴によるバッテリー切れの心配が軽減し、入場者が安心して視聴できる。
また、電子発言をデータ放送に含めて放送することで、入場者視点での情報を得ることができるようになる。なお、携帯端末９においてデータ放送用仮想プレーンや映像仮想プレーン、字幕仮想プレーンを画面（表示領域）上にどのように配置するかは任意であり、画面の大部分にデータ放送用仮想プレーンを配置して、鮮明な表示により乗物情報等を見ることもできる。
【００２６】
図４は、本実施形態の情報送信システムのサーバ部周辺の構成図である。後述する各装置が、互いに通信可能に構内ＬＡＮで接続されている。発券・入場管理サーバ２０１は、遊園地への入場券の予約状況や発券状況を把握するとともに、発券した入場券による入場状況を把握するサーバである。入場券は例えばＲＦ−ＩＤタグであり、券ごとにユニークなＩＤが付されており、発券・入場管理サーバ２０１はそのＩＤにより入場状況を管理したり、他の情報と関連付けて各種処理を行う。
【００２７】
入出園ゲート２０２は、入園者（客）、退園者の保持する入場券のＩＤを読み取り、発券・入場管理サーバ２０１に通知すると共に、発券・入場管理サーバ２０１からの応答に基づきゲートの開閉を制御する。アトラクションゲート２０４は、各アトラクション毎に、利用客、一般客ごとに設置され、アトラクション入場前の客の入場券のＩＤを読み取り、発券・入場管理サーバ２０１に通知するとともに、発券・入場管理サーバ２０１からの応答に応じて所定の顕示等を行う。
【００２８】
ＩＰカメラ２０５は、各アトラクションやレストラン、休憩場所、入出場ゲートの外、駐車場等に１乃至複数設置され、それらの映像を撮影し、圧縮して送出する。画像処理装置２０６は、ＩＰカメラ２０５からの圧縮映像を受信し、画像認識処理により客の混雑状況や、行列の人数等を検出する。
【００２９】
サーバＳは、図１のサーバＳに相当するものであり、本実施形態では主に以下の処理を行う。
第１処理：発券・入場管理サーバ２０１からの情報（予約数、実入園者数）、外部から取得した気象状況、暦、画像処理装置２０６からの混雑状況情報等と、過去統計データベースとから、その日の入園者数推移を時間別に予測する。予測は定期的に更新し、また実入園者数によりデータベースも更新する。
第２処理：予測入園者数と、遊園地容量とに基づき、入園者に勧めるべきアトラクション数の適正値を算出する。
第３処理：適正アトラクション数に基づき、モデルプランを複数生成し、入園者に提供するとともに、提供状況を管理する。モデルプランは、現時刻から閉園時刻までに搭乗するアトラクション、及びそれらの集合時刻が記載されており、提供状況は提供を受けた客の入場券ＩＤ毎に管理する。
第４処理：各アトラクション等の現在の一般客と利用客の混雑状況、及びプラン提供状況等に基づき、現在以降の各アトラクション待ち状態（待ち人数、待ち時間）の推移を、一般客と利用客それぞれについて予測する。これは入園者数の予測同様に行う。この結果、アトラクション待ち状況によってはモデルプランを修正、変更する。また各アトラクションに対して、興行１回当たりの一般客と利用客の望ましい比率を連絡する。
第５処理：モデルプラン提供状況に基づき、各利用客に対し、集合時刻の所定時間前に通知を行う。また、実際のアトラクションゲート２０４の通過時刻はモデルプランにおける時刻とずれてくるので、利用客個々に対して以降のプランを修正（カスタマイズ）して提供する。
【００３０】
図５は、送信情報の一実施形態を示すもので、全域情報とブロック情報の２つの情報区分とし、それぞれ乗物情報、飲食店情報、総合案内情報を提供するものであり、必要送信チャネル数は６となる。１セグメントに１チャネルを付与し、これらを束ねて６セグメントを送信する技術を用いて実現するか、１／２或いは１／３セグメントあたりに１チャネル（サブチャンネルと呼ぶ）を付与し、合計３或いは２セグメントを束ねて送信する技術等を用いて実現する。
【００３１】
携帯端末９は、上述のような構成のセグメントに対して物理チャンネルをチューニングでき、所望の番組のＴＳストリームを取り出して再生できる（多セグメント対応と称する）必要がある。必要に応じて、施設内チャネル専用の端末を貸し出すことで、情報提供の平等化を図ることができる。この貸与端末は、例えば特殊器具で無いと燃料補給できない燃料電池による駆動とし、入場者が持ち帰っても使えないようにするとよい。
【００３２】
また、ブロックごとの狭域エリア構成とすることにより、全域の情報を受け取ることができる他、来場者がブロック情報を受信すれば現在いる近隣の情報を即座に受け取ることが可能となる。すなわち、ブロック情報にはチャンネル設定情報も含まれており、それをＱＲコード（登録商標）リーダやＦｅｌｉｃａ（登録商標）の通信機能等により受信すると、（半）自動的にワンセグチューナを起動し、指定されたチャンネルにチューニングする。
【００３３】
図６は乗物情報の画面表示の一例である。図６の画面は全域情報（図中では「全域放送」と表記している）の場合のもので、施設内全体の乗り物について、乗物名と地図上の位置（地区地図番号）、待ち時間、優先搭乗券の発行時間の情報が、所定の並び、例えば待ち時間順に表示される。地区地図番号のアイウ…はブロックに１対１対応している。
【００３４】
図７は飲食店情報の画面表示の一例を示すもので、店名と提供内容、地図上の位置、満空情報、満席の場合の待ち時間の情報が表示される。図８は総合案内情報の画面表示の一例を示すもので、イベント開催状況と時間、地図上の位置、その他注意事項等が表示される他、迷子・落し物情報と預かり場所、地図上の位置が表示される。
【００３５】
これらの画面表示は情報量が多い場合にはリアルタイムのスクロールまたは、定時スクロールで表示される。
ブロック内情報については、全域情報と同様の情報が、ブロックごとに待ち時間順等にソートされ、ブロック毎に独立した情報として表示される。もし利用者が自分のいるブロックを指定する操作等を携帯端末に行うと、指定されたブロックの情報のみを繰り返し表示するようになる。
【００３６】
（第１実施形態）
本実施形態は、遊園地において、入場者にアトラクション等のプラニングを提供する機能を付加した情報送信システムの一形態を説明するものであり、送信部分の構成は先に説明した図１の情報送信システムと同様である。
遊園地では、客はより多くのアトラクションを楽しもうとして、常にどこかの待ち行列に並ぼうとする傾向がある。その結果、待ち時間が長くなり、入園時間の多くを行列に並ぶこと、或いは行列の短いアトラクションを探して彷徨うことに費やすようになる。
【００３７】
本実施形態では、並ばなくても乗れることを保証し、客が行列に並らばないように誘導することで待ち時間を短縮し、その分遊園地内の自由行動時間が増えることで顧客満足を向上でき、また客の密度が遊園地内で分散することで遊園地の容量を最大限まで高めることを目的とする。
【００３８】
なお本実施形態では、説明を簡単にするためにアトラクションは全て乗り物であるとして、アトラクションを利用することを「搭乗」と言うことにする。また本システムのプラニングを利用する客を利用客、利用しない客を一般客と呼ぶ。
次に、図９のフローチャートを用いて、本実施形態の情報送信システムの動作を、１人の利用客Ａに注目して説明する。
【００３９】
［ステップＳ１］入場券には、予約番号や期間契約者番号等を客が入力できるようにする入力部を有しており、予約番号等が入力されたときは、発券・入場管理サーバ２０１に問い合わせて照合し、発券を行う。入場券には、入場券ＩＤを数字（文字）化した一部か、入場券ＩＤを照合可能な文字列（例えば、入場券ＩＤを一方向性関数処理し、ＵＲＬエンコードして得られる文字列）の全部又は一部を印字する。印字される数字や文字列は、グループ客が同一プランを希望する操作のために用意され、ランダムでかつその日の入園客一人ひとりを特定するのに必要な桁数を有することが望ましい。
【００４０】
予約番号等の入力がされなかったときも、上記と同様であるが、更に、上記照合可能文字列を含むサーバＳのＵＲＩを表す２次元バーコードも入場券に印刷すると良い。
［ステップＳ２］利用客Ａが入出園ゲート２０２から入場すると、発券・入場管理サーバ２０１は、把握している実入園者数を１増やす。発券・入場管理サーバ２０１は、その日の実入園者数を推移を分単位で記録する。
【００４１】
［ステップＳ３］利用客Ａの入場と前後して、利用客Ａの携帯端末は、携帯電話パケット通信網を介してサーバＳへの（間接的な）アクセスを行う。この目的は、サーバＳが利用客Ａの携帯端末を特定するための識別子を取得すること、ならびに携帯端末に対して本実施形態の情報送信システムが放送しているワンセグのチャンネルを通知しチューナを起動させることである。端末識別子としては、ＨＴＴＰリクエストのＸ−ＤＣＭＧＵＩＤヘッダやＸ−ＵＰ−ＳＵＢＮＯヘッダにある情報が利用できる。
【００４２】
携帯端末は、２次元バーコード読み取り機能を用いて、サーバＳにアクセスする。或いは周知されたサーバＳのホームページにアクセス後、印字された照合可能文字を直接入力してもよい。
サーバＳは、入場券ＩＤの正当性（発券時刻から有効期間以内か等）を発券・入場管理サーバ２０１に適宜問い合わせて検査し、不当であれば携帯端末からのリクエストを無視し、正当であれば携帯端末に、メディア起動記述を含んだページ(ＨＴＭＬかＢＭＬ)を送付する。このページにＣプロファイル準拠のＢＭＬを使えば、Ｃプロファイルリンクコンテンツ或いは非リンクコンテンツとなる。これを受信した携帯端末は、ユーザの操作により或いは自動でチューナを起動し、メディア起動記述に記載された物理チャンネルにチューニングする。
【００４３】
［ステップＳ４］サーバＳは、メールアドレスの送信或いは（空の）メールの送信を求めるページ(ＨＴＭＬ)も携帯端末に送信する。携帯端末はそれに応答して送信を行う。事前の予約により、端末識別子に対応するメールアドレスが既知である場合などでは、このステップＳ４は行わない。
【００４４】
［ステップＳ５］サーバＳは、ステップＳ２〜Ｓ３で得た情報を、一旦利用客ＤＢに格納する。利用客ＤＢは、入場券ＩＤをキーとし、端末識別子、メールアドレス、プランデータ、要求不成功プラン情報、プラン実時刻データ、通知識別情報等を保持する。入場券ＩＤと端末識別子は１対１である必要は無く、複数人の客が１つの携帯端末を共用してもよい。
【００４５】
［ステップＳ６］サーバＳは、前述の第１処理に相当する処理を行う。つまり、外部から取得した気象状況、暦、発券・入場管理サーバ２０１から取得した当日の入園者数推移（実績）等に近いデータを、過去統計ＤＢから検索する。過去統計ＤＢには、過去の全営業日の或いは典型的な入園者数推移が、気象状況、暦等と共に保持されている。検索により見つかるデータは当日の実入園者数とは完全に一致しないので、検索データでの入園者数推移と実入園者数との比で補正する他、予約数や駐車場等の混雑状況情報、キャンペーンの効果等を考慮して検索データを補正することで、当日のこれからの予測入園者数推移として用いることができる。
【００４６】
［ステップＳ７］サーバＳは、前述の第２処理に相当する処理を行う。最も単純なモデルでは、各アトラクションの単位時間当たりの搭乗客数の合計を遊園地容量とし、（当日の現在以降の入園者数推移の平均値）×（当日の現在以降の営業時間）÷遊園地容量により、適正アトラクション数を算出する。
【００４７】
［ステップＳ８］サーバＳは、前述の第３処理に相当する処理を行う。遊園地の全アトラクション数をｎとし、そこからｍ個（ｍはｎ以下の整数）を選ぶ順列の総数はnＰmであり、搭乗アトラクション数ｍは利用客の好みに拠るから、順列の総数は莫大であり、これらの総数から所定数のモデルプランを選ぶ組み合わせ全てをシミュレーションするのは非現実的である。
【００４８】
従って、まず総数を数千程度に絞ったモデル候補群をｍ毎に準備する。このモデル候補群Ｇmは、含まれる各モデルの直交性（同じ時間にモデルＡが割り振るアトラクションとモデルＢが割り振るアトラクションが重複しないこと）が高くなるように、過去の客の傾向なども考慮しつつ設計する。これにより、似たような（冗長な）モデルが淘汰され、また、人気度の高いアトラクションを多く含むモデルほど、小さいｍのモデル候補群に集まる傾向になる。
【００４９】
そして、混雑状況情報や天候や当日のモデル提供状況に基づき、モデル候補群から提供すべき数１００〜数１０００パターンのモデルプランを決定する。これらのモデルプランは、希望アトラクション等乗数、希望必須アトラクション、年齢層、性別、歩く速度（歩ける量）、三半規管への刺激、天候を気にするか、等の条件（これら全て必須なわけでは無い）で分類したときに程よく分散すると共に、各モデルが想定される人気度で利用客に利用された状況のシミュレーションにより特定のアトラクションに客が極度に集中しないことを確認しながら、選ばれる。サーバＳは、このモデルプランの情報（各モデルを特定可能なＩＤ等を含む）を番組編集装置２に送信し、番組編集装置２はそれを１モジュールのＢＭＬコンテンツに編集する。一例として、ステップＳ６〜Ｓ８は５分毎に行われ、提供されるモデルプランも１０分毎に定期更新される。
【００５０】
［ステップＳ９］携帯端末は、ステップＳ３で起動したチューナの機能により、指定された物理チャンネルのワンセグ放送の視聴を行う。ワンセグ放送にはステップＳ８で作成されたモデル群のＢＭＬコンテンツが含まれており、利用者は上記条件に相当する質問に答えるだけで、数個程度に絞られた好適なモデルプランにたどり着ける。モデル群のＢＭＬコンテンツは数ＭＢかそれ以上の大きな容量であるが、一旦受信してしまえば、サーバとの交信なしに、条件の変更等の操作に対し瞬時に応答が得られるので、操作性が非常に良い。ＢＭＬコンテンツには有効期限や、１０分間隔で更新される次のコンテンツ（番組）の開始時刻等の情報が含まれており、一旦モジュールを受信した以降は、次の開始時刻まで表示以外のチューナ機能をオフできるようになっている。このような動作は、ＢＭＬコンテンツのＥＣＭＡＳｃｒｉｐｔで利用可能な放送用拡張関数（Browser擬似オブジェクトのメソッド）や、イベントメッセージを用いて実現できる。
【００５１】
［ステップＳ１０］携帯端末は、利用客Ａが選択したモデルプランの情報（モデルＩＤ）を、携帯端末のパケット通信機能によりサーバＳに送信する。この通信機能の開始には、放送用拡張関数を利用できる。送信するモデルＩＤは、１つでもよく、優先順位つきで複数あってもよく、また同伴者の入場券に印刷された照合可能文字列或いは２次元バーコード読み取り結果を１乃至複数指定して、これらの同伴者も同じモデルプランを選択した旨を送信することもできる。
【００５２】
［ステップＳ１１］サーバＳは、ステップＳ１０の選択モデルプラン情報を受信すると、一致する端末識別子があるか、プランデータが空か（選択済みではないか）等を、利用客ＤＢとの照合のよりチェックする。チェックで異常が無く、選択されたモデルＩＤが有効であれば、そのモデルプランに対応するタイムスケジュールを生成し、それらを携帯端末にＨＴＭＬ或いはメール形式して提供するとともに、利用客ＤＢにプランデータとして保存する。
【００５３】
タイムスケジュールは、第４処理で得られるアトラクション待ち状態推移等（特に待ち時間）に基づき、利用客個々に対して分単位のスケジュールとして生成される。また、個々の通知を特定できるようなユニークな通知識別情報も生成し、利用客ＤＢに格納する。携帯端末には、タイムスケジュールと共に、タイムスケジュールの変更等を受け付けるＷｅｂページ（サーバＳが提供する）等のＵＲＩ（通知識別情報を含む）も通知される。利用客ＤＢへのプランデータや通知識別情報の保存は、上記提供（送信）の成功を確認してから行うと良い。
【００５４】
一方、チェック異常や無効モデルＩＤの場合は、所定の応答（例えば上記変更受付ページの案内）をする。特に、利用客ＤＢにプランデータが既に保存されていた場合、プラン変更として扱うが、プラン変更の回数を制限するため、変更の履歴を要求不成功プラン情報に追記する。また特定のモデルプランの選択が極度に集中した場合等も要求不成功となり、要求不成功プラン情報に追記される。
【００５５】
［ステップＳ１２］サーバＳは、前述の第４処理に相当する処理を、ステップＳ６〜Ｓ８同様に５分毎に行う。一般客の待ち状態推移は、入園者数の予測同様に行うことができる。例えば、過去統計ＤＢには入園者数推移だけでなく個々のアトラクションの待ち状態推移も保持しておき、検索により見つかるデータを、実際に画像処理装置２０６が検出した混雑状況情報（行列の長さ、待ち時間）で若干補正して用いる。
【００５６】
一方、利用客の待ち状態推移は、利用客ＤＢ中の全利用客のタイムスケジュールを集計して求める。例えば、ある基準時刻以降の（次の）アトラクションがＡ１である利用客全てについて、基準時刻から、タイムスケジュール上での搭乗予定或いは集合時刻までの時間の平均が、その基準時刻におけるアトラクションＡ１の推定待ち時間である。つまり、本実施形態では利用客の待ち状態推移は、実際に列に並んで待つことではなく、任意の場所でタイムスケジュールに従い行動している利用客の状態を意味している。
【００５７】
ただし、特定のアトラクションＡ２で利用客の列だけが想定以上に長くなった場合に備え、利用客の列でも混雑状況情報の検出をし、ステップＳ８のモデル候補選定に反映させる（直近にＡ２を避けて選定する）ほか、近々にＡ２がスケジュールされている利用客のスケジュールを遅らせる（後述）こともある。
【００５８】
［ステップＳ１３］以下のステップＳ１３〜Ｓ１６は、第５処理にほぼ相当し、プランデータに応じて繰り返される。サーバＳは、利用客ＤＢに保存された各プランデータを１分単位で監視し、将来の直近のスケジュール（集合時刻）の所定時間前に、該当する利用客Ａのメールアドレス宛に、通知メールを送信する。
【００５９】
［ステップＳ１４］利用客は、提供されたプランデータ（タイムスケジュール）に基づき、最初のアトラクションＡ１へ行き、利用客専用の列に並ぶ。利用客専用の列及び一般客用の列の所定の位置にアトラクションゲート２０４がそれぞれ設置されており、サーバＳの第４処理により連絡された人数或いはその比率で、列の客が通過できるようにする。
【００６０】
列が進み、その利用客Ａがアトラクションゲート２０４に達すると、その利用客Ａの入場券を読み取り、通過情報としてサーバＳに通知する。
［ステップＳ１５］サーバＳは、受信した通過情報の利用客ＩＤにより利用客ＤＢのプランデータを参照し、アトラクションＡ１がプランでの未来直近のアトラクションと一致しない場合、或いは、通過時刻がプランより第１所定時間（例えば３０分）以上早く、且つアトラクションＡ１の一般客の待ち時間が第２所定時間（例えば９０分）以上の場合には、その利用客のアトラクションゲート２０４の通過を認めない旨の信号をアトラクションゲート２０４に送信するとともに、通過情報を不許可の旨と共にプラン実時刻データに追記する。またこのタイミングで、この利用客のスケジュールを早めても公平性が損なわれないかどうか、各アトラクションの混雑状況や待ち状態推移を考慮して判定し、問題なければスケジュールを早める修正を行い、修正後のスケジュールを含む通知メールを利用客に送信する。
【００６１】
それ以外の場合は、通過を認める信号をアトラクションゲート２０４に送信し、通過情報をプラン実時刻データに追記し、実際の通過時刻に応じて以降のスケジュールを早めたり遅くしたりして修正する。修正量に関しては、利用客と一般客の公平性が考慮される。公平性としては、不許可の通過情報の記録の回数が所定数に達したときに、スケジュールの前倒し修正を行わないことで実現する方法も考えられる。
【００６２】
このように本実施形態では、プランからどんなに遅れて集合してもプランにそのアトラクションが修正されずに残っている限り、利用客としてそのアトラクションに搭乗できるようになっている。
［ステップＳ１６］アトラクションゲート２０４は、通過を認めない旨の信号を受けると表示、鳴動、ゲートの閉鎖等の所定の動作を行う。それを受けて係員は、例えば、該信号を受けた利用客に対し、利用客の列に並び直すように誘導する。スケジュールを早める修正が行われていれば、利用客は通知メールを受け取り、状況を理解できる。このように、本実施形態ではスケジュールの自動修正は、各利用客の行動に変化があった（アトラクションゲート２０４通過等）ことを契機に行われ、それ以外には、利用客の意志を尊重し自動修正は行わない。また、搭乗後の利用客の管理も特に行わない。
【００６３】
ここで、ステップＳ１１で言及したタイムスケジュールの変更等を受け付けるＷｅｂページを利用したと仮定して、説明を続ける。
［ステップＳ１７］携帯端末は、ステップＳ１１或いはＳ１５で届いた通知メールに記載のＵＲＩに基づき、パケット通信機能を用いてサーバＳにアクセスする。
【００６４】
［ステップＳ１８］サーバＳは、携帯端末からのリクエストに含まれる通知識別情報、端末識別子等を利用客ＤＢと照合する。一致する利用客ＩＤが見つかれば、その利用客ＩＤのプランデータのタイムスケジュールを読み出し、そのタイムスケジュールを操作可能に表示するＷｅｂページのデータを携帯端末に送信する。
【００６５】
［ステップＳ１９］携帯端末は、受信したＷｅｂページを表示し、利用客からの操作を受け付け、最後にその結果をサーバＳに送信する。操作の一例として、現在以降のタイムスケジュールから１つのアトラクションを選び、それを別のアトラクションに変更するような操作が考えられる。変更先のアトラクションの選び方としては、混雑しているアトラクションは抽選方式にしたり、タイムスケジュールの他のアトラクションのキャンセルを要件にしたりする方法が考えられる。
【００６６】
［ステップＳ２０］サーバＳは、混雑状況情報等に基づき、変更が可能か判定し、可能な場合は、その利用客のプランデータを変更して利用客ＤＢに保存するとともに、利用客に変更した旨の通知メールを送信する。
以上説明したステップの中で、セキュリティ上の検討を要するのは、入場券に印字された照合可能文字を用いた利用登録の扱いである。すなわち客自身が登録する前に、第３者が照合可能文字を総当りすることで客に成りすまして登録できないようにする必要がある。一例として、（照合可能文字が長くなってしまうが、）同一の端末識別子の端末からの不正な登録試行に上限を設け、照合可能文字の照合力（正当な値にたどり着ける平均試行数）をその上限より十分高くする方法がある。また、登録前にサーバＳから乱数、及びＧＰＳ等の位置情報取得要求を携帯端末に送り、その乱数と遊園地に相当する位置情報が所定時間内に携帯端末から送り返されたことを以って登録を許可するようにしてもよい。位置情報取得要求は、本システムからＢＭＬで供給する際はX_DPA_getCurPos()、パケット通信網から要求する際は各通信事業者の規定の方法を用いる。
【００６７】
（第２実施形態）
本実施形態の情報送信システムは、上述した実施形態のシステムに、図示しない広告ＰＥＳ生成部を追加して、その出力を図３のＴＳ多重化部１１３に供給し、デジタルサイネージも行うようにしたものである。すなわち、広告ＰＥＳ生成部は、高精細のＪＰＥＧ或いはＰＮＧ画像ファイルや、米国アドビ社のアニメーション形式であるＦｌａｓｈファイル等をＰＥＳ化して出力する。この際ストリームＩＤとしては秘密の（ＰＳＩ／ＳＩからは辿れない）ものを用い、またビットレートは十分抑えられる。ＴＳ多重化部１１３は、広告ＰＥＳ生成部の出力するＰＥＳも多重化する。
【００６８】
大型表示端末は、ワンセグチューナ等を備えた表示装置であり、物理チャンネルや上記秘密のＰＥＳを指定しておけば、送信された画像等を、液晶画面或いは電子ペーパー上に再生表示することができる。大型表示端末での受信環境は安定していると考えられるので、本実施形態ではＰＥＳ多重送出としたが、カルーセル伝送方式を用いてもよい。
【００６９】
（第３実施形態）
本実施形態の情報送信システムは、先の第２実施形態のシステムを、災害時の安否確認に利用したものである。サーバＳは、連絡が取れない肉親等（尋ね人）の携帯電話番号等の登録を受付ける画面のＨＴＭＬを保持しており、災害時時にそれを番組編集装置２に出力して、ＢＭＬコンテンツとして本システムから放送させる。登録する情報は、電話番号のほか、名前、概略的な住所、顔写真等、基本的には尋ね人の情報であるが、登録者の情報でも良い（後述）。そのＢＭＬコンテンツには、そのようにして登録された携帯電話番号のリストを有し、受信した携帯端末がリストから自己の電話番号と一致するものを検索するようなＢＭＬのスクリプト（例えばＥＣＭＡＳｃｒｉｐｔ）やアプリ（例えばＭＩＤＰ等の携帯電話事業者固有のもの）を含んでいる。また携帯端末がこの放送を受信できるよう、避難所などでチャンネル番号や放送時間を掲示等しておく。
【００７０】
携帯端末は、ＢＭＬコンテンツを受信し、操作に応じて電話番号登録画面を表示し、またスクリプト等も実行する。ＢＭＬのスクリプトのみで実現する場合、自己の電話番号は、拡張関数X_DPA_getIRDID()の引き数に１〜３を試行しながら、戻り値の文字列に電話番号らしい文字列（１１桁の数字）が発見できた場合、それを採用する。そしてリストから自己の電話番号を検索し、一致するものがあれば、メール送信の準備として、メール本文の作成及び保存と、X_DPA_getRevCond()による通信機能の状態取得を行う。そして、メール送新可能な通信状態であれば、X_DPA_mailTo()により、指定の宛先（登録者が登録したメールアドレス、或いはサーバＳ）にパケット通信網によりメールが（半）自動的に送信される。メールの本文には、X_DPA_getCurPos()で取得した位置情報や、携帯端末の所有者がその場で撮影した自身の画像、任意のメッセージ等を格納させることもできる。
【００７１】
一方、携帯電話アプリを用いる場合、ＣプロファイルのＢＭＬからはアプリを直接起動できない、アプリでも自己の電話番号は取得できない、等の難しさがあるが、逆に携帯電話の発信履歴やアドレス帳等にアクセスできる利点がある。そこで、リストには登録者の電話番号や氏名を載せ、アプリはそれらと一致するものが発信履歴やアドレス帳にあるか検索し、あったときに、メール自動送信等の所定の動作をするようにする。これにより、登録者は自身に縁のある人の所在等をまとめて知ることができる。
【００７２】
アプリ起動に関しては、ＢＭＬのスクリプトにより、受信した各事業者用のアプリのうち、自己の携帯端末の事業者に一致するものを見つけ、携帯電話のアプリとして保存した後、事業者毎に定めるＵＲＩにあるＨＴＭＬをlaunchExApp()により通信事業者仕様ブラウザで開き、そのＨＴＭＬからアプリを起動するようにする。或いは、ＢＭＬコンテンツにおいて、手動で起動するように促す表示を行う。このアプリには、上記の他、災害時に役立つ種種の機能を持たせることもできる。
【００７３】
サーバＳはまた、登録された尋ね人の情報を番組編集装置２に提供し、番組編集装置２は、提供された尋ね人情報を順次表示するような番組を作成する。この番組は、避難所に設置された大型表示端末や携帯端末で視聴される。尋ね人から応答のメール等があったときは、その旨も番組上で表示し、所定時間後には登録自体を削除する。
【００７４】
（第４実施形態）
本実施形態の情報送信システムは、先の第２実施形態のシステムを、遊園地の乗り物ではなく実際の交通機関に利用した、交通遅延表示システムである。例えば鉄道では、需要予測と運行（遅延）状況がわかれば、乗客にどの程度の影響（足止め時間）が生ずるかが予測でき、またどの振替路線に誘導すべきかの判断材料になる。本実施形態の交通遅延表示システムでは、電子発言サーバはインターネット上ではない独自サーバとし、駅員の業務連絡等に利用する。また、駅員等のためのコンテンツは、限定受信により一般客には視聴できないようにする。一般客へは、遅延情報、振替乗車の案内等の情報を提供する。望ましくは、各鉄道会社の情報を、関東、中部等の地域で１番組に集約して提供する。
【００７５】
（第５実施形態）
本実施形態の情報送信システムは、先の第１実施形態のシステムに、特許文献３のような迷子探索機能を追加したものである。すなわち画像処理装置２０６は顔検知を備え、映像に人が映るとベストショットの顔或いは全身像を抽出し、ＳＩＦＴ特徴量（多次元ベクトルである）等を求めて、サーバＳに送信する。サーバＳは、受信した特徴量（及び抽出画像）を一定期間、画像ＤＢに蓄積する。迷子の関係者（親）が、迷子の特徴を連絡または画像をセンタのサーバＳに提供すると、サーバＳは、提供画像から同様に特徴量を求めるか或いは連絡された特徴（言語で表現される）を特徴量に変換し、特徴量が一致するものを画像ＤＢやカメラのライブ映像から探索する。なお画像として記録収集すると客がプライバシの不安を感じるので、画像処理装置は画像を出力せず、画像ＤＢには特徴量のみ蓄積することが望ましい。
【００７６】
（第６実施形態）
本実施形態の情報送信システムは、先の第５実施形態のシステムに、不審者探索機（連れ去り防止）を追加したものである。画像ＤＢには、不審者の画像或いはその特徴量を登録しておき、特徴量比較により不審者と認識されたら、行動がわかる様追跡する。
【００７７】
また、入出園ゲート２０２等の夫々にＩＰカメラ２０５を設け、入場券を入れて入園する客一人ひとりの画像を取得しておき、入場時と違う人（特に不審者）と一緒に退場しようとした場合には連れ去りと判断してアラーム通知する。判断には幅を持たせて、入場時に一緒にいる前後数名や、大人と子供の組み合わせに限定等の条件を持たせる。
【００７８】
なお、この発明は上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００７９】
Ｓ…サーバ、１…情報送信システム、２…番組編集装置、３…送信装置、４…ヘッドアンプ、５…Ｅ／Ｏ変換装置、６…分配器、７…電力増幅器、８…送信アンテナ、９…携帯端末、１０…送信アンテナ。
【特許請求の範囲】
【請求項１】
施設内の個別情報を収集して整理するサーバと、
前記サーバが収集した施設内の個別情報を、携帯端末向けの地上デジタル放送波に変換して送信する送信装置と、を具備することを特徴とする情報送信システム。
【請求項２】
前記サーバが収集した個別情報に基づき、前記施設への入園者数を予測し、この入園者数の予測に基づいて前記施設で行われる複数のアトラクションからどのアトラクションを選択して利用するかを提案するための情報を生成する装置をさらに有しており、前記送信装置により前記生成情報を携帯端末向けの地上デジタル放送波に変換して送信することを特徴とする請求項１記載の情報送信システム。
【請求項３】
前記サーバが収集した個別情報に基づき、前記施設で行われるアトラクションの待ち状態を示す情報を生成し、前記アトラクションの集合時間の所定時間前に時刻が来たことを知らせるための情報を生成する装置をさらに有しており、前記送信装置により前記生成情報を携帯端末向けの地上デジタル放送波に変換して送信することを特徴とする請求項１記載の情報送信システム。
【請求項１】
施設内の個別情報を収集して整理するサーバと、
前記サーバが収集した施設内の個別情報を、携帯端末向けの地上デジタル放送波に変換して送信する送信装置と、を具備することを特徴とする情報送信システム。
【請求項２】
前記サーバが収集した個別情報に基づき、前記施設への入園者数を予測し、この入園者数の予測に基づいて前記施設で行われる複数のアトラクションからどのアトラクションを選択して利用するかを提案するための情報を生成する装置をさらに有しており、前記送信装置により前記生成情報を携帯端末向けの地上デジタル放送波に変換して送信することを特徴とする請求項１記載の情報送信システム。
【請求項３】
前記サーバが収集した個別情報に基づき、前記施設で行われるアトラクションの待ち状態を示す情報を生成し、前記アトラクションの集合時間の所定時間前に時刻が来たことを知らせるための情報を生成する装置をさらに有しており、前記送信装置により前記生成情報を携帯端末向けの地上デジタル放送波に変換して送信することを特徴とする請求項１記載の情報送信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−８５０１２（Ｐ２０１２−８５０１２Ａ）
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願番号】特願２０１０−２２７８７５（Ｐ２０１０−２２７８７５）
【出願日】平成２２年１０月７日（２０１０．１０．７）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【出願人】（５０４３７８８１４）八木アンテナ株式会社 (190)
【Ｆターム（参考）】
【公開日】平成２４年４月２６日（２０１２．４．２６）
【国際特許分類】
【出願日】平成２２年１０月７日（２０１０．１０．７）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【出願人】（５０４３７８８１４）八木アンテナ株式会社 (190)
【Ｆターム（参考）】
[ Back to top ]