JP5302375B2

JP5302375B2 - エレベータに使用する情報配信システム

Info

Publication number: JP5302375B2
Application number: JP2011246941A
Authority: JP
Inventors: エイ．ニューヴィル、トッド; ダブリュ．デュアルテ、ショーン
Original assignee: Gannett Satellite Information Network Inc
Current assignee: Gannett Satellite Information Network Inc
Priority date: 1999-12-21
Filing date: 2011-11-10
Publication date: 2013-10-02
Anticipated expiration: 2020-12-21
Also published as: CA2395354A1; US20030102190A1; US20080028306A1; EP1252085A1; EP1252085A4; WO2001046057A1; US6349797B1; US20110321101A1; US8230981B2; US7278518B2; JP2012071992A; AU779508B2; CA2395354C; WO2001046057A9; US20060144647A1; JP2003523002A; AU2449301A; EP1252085B1; JP4927283B2; HK1051026A1

Description

（発明の背景）
本発明は、エレベータおよび他のこのような人員輸送車両に情報を提供することに関する。

摩天楼やその他の高層構造を建築する原動力は、不動産をより効率的に使用することにあり、特に不動産の価値が非常に高い都市地域ではそうである。このような構造における主な輸送形態はエレベータであり、特に多くの階を有する建物ではそうである。

エレベータ内で提供される目視情報は、通常、階情報および緊急時の、または補助が必要な場合の乗員への指示に限られる。エレベータは、その日のプレゼントとその位置を掲示する静止掲示も含むことができる。

本発明は、メッセージの順番を定義するプレイ・リストにしたがって、エレベータの乗員にビデオ情報を表示するシステムを特徴とする。ビデオ情報のメッセージは、ディジタル広告、「リアルタイム」の一般情報、さらに建物関連の情報の組合せを含むことができる。

本発明の１つの態様では、システムは、ビデオ情報を乗員に表示するディスプレイ・モニタを有するエレベータ・ディスプレイ・ユニット、およびデータ通信路上でビデオ情報に伴うスケジューリング情報を受信し、スケジューリング情報にしたがって、エレベータのディスプレイ・ユニットでの表示に使用するプレイ・リストを生成するローカル・サーバを含む。

本発明の別の態様では、一般情報および商業情報をエレベータ内に提供する方法は、ａ）ローカル・サーバに、表示されるビデオ情報に関連するスケジューリング情報を提供するステップと、ｂ）スケジューリング情報から、ビデオ情報に関連するプレイ・リストを生成するステップと、ｃ）エレベータ内のエレベータ・ディスプレイ・ユニットで、スケジューリング情報に従う所定の時間にビデオ情報を見るためにディスプレイを生成するステップとを含む。

さらに別の態様では、本発明は、建物内に配置されたエレベータ内のディスプレイ・モニタにビデオ情報を提供する方法である。該方法は、ビデオ情報のカテゴリを定義する第１のデータを受信することと、ビデオ情報のカテゴリに関連し、少なくとも１つのビデオ情報源を定義する第２のデータを受信することと、情報源からデータ通信路上で、および第１のデータおよび第２のデータに基づいて、エレベータ内のモニタに表示されるべきビデオ情報を検索することとを含む。本発明は、この方法でビデオ情報を提供するシステムにも拡張する。

「ビデオ情報」とは、一般情報、商業情報、および建物関連の情報の全ての組合せを意味する。「商業情報」とは、広告を含む商業および取引に関する情報を意味する。「一般
情報」は、本明細書では、ニュース（最近の出来事、スポーツ、娯楽など）および天候を含む一般的関心の情報を意味する。一般情報は、エレベータがその一部となっている建物に関連する情報も含むことができ、例えば１）建物に関連する事象、２）交通、３）輸送スケジュール（例えば、列車／シャトル・サービス）である。「建物関連の情報」とは、そのエレベータが建物の居住者、所有者、および訪問者を輸送する特定の建物に特に関連する情報を意味する。建物関連の情報は、建物内、または建物の地元のビジネス広告（例えば、コーヒー、店舗、駐車場、花屋）、さらに建物内の使用可能な空間に関する建物管理者からの告知など、特定のタイプの商業情報を含むことができる。建物関連の情報は、一般情報、特に建物およびエレベータ乗員に関連する情報も含むことができる。例えば、このような情報は、建物の活動（例えば、休日の行事、火災報知器のテスト）、公共放送／緊急メッセージ、交通情報、およびエレベータ乗員にとって重要な他の情報を含むことができる。対して、建物関連の情報は、情報のタイプより地理に制限される。

このシステムでは、広告主、オンライン・コンテンツ・プロバイダ、および建物の管理者／所有者は、エレベータという乗員が往々にして完全な他人とともに閉じこめられることに不安を感じる状況で、特定の明確に定義された標的となる観衆と対話することができる。エレベータ乗員は往々にして、無限に続くよう感じられ、苛々する時間の間、同乗者と目を合わせない方法を求めている。乗員はもはや当てもなく床や天井を見つめる必要はなく、見るべき情報媒体源を有する。

高層オフィス・ビルの占有者は通常、十分理解された関心および購買傾向を有するビジネスマンである。その人々は、標的を定めたコンテンツおよび広告の理想的な受容者である。システムによって、コンテンツ・プロバイダ（例えば、地元および国のニュース・ソース）および広告主が、建物、市、地域、ビジネス区分などの人口統計に基づいて観衆を選択的に標的にすることができる。同様に、国、地域および地元のオンライン・コンテンツ・プロバイダには、エレベータの乗員の一般的関心のある情報を提供する機会がある。システムは、建物の所有者および管理者に、テナントおよび建物の訪問者に特に関係があり、有用なビデオ情報を提供する能力も提供する。

本発明のこれらの態様の実施形態は、以下の特徴を１つまたは複数含むことができる。
ローカル・サーバは、データ通信網（例えば、インターネット）でプロダクション・サーバからスケジューリング情報を受信する。

システムは、一般情報および商業情報に関連するスケジューリング情報を生成するプロダクション・サーバも含む。したがって、プロダクション・サーバは中央分配サイトとして働き、ここでは特にスケジューリング情報（例えば、建物のプレイ・リストまたはスクリプト）が生成される。プロダクション・サーバは、建物関連のデータ、一般情報関連のデータ、および商業情報関連のデータを記憶するプロダクション・サーバ・データベースを含む。このデータベースは、例えば建物の特徴付けデータ、さらにデータ通信路上で一般情報および商業情報を検索することができるアドレスを含む。

プロダクション・サーバはスケジューリング・モジュールを含み、これはプロダクション・サーバ・データベースからデータを検索して、スケジューリング情報および建物ローダ・インタフェースを生成し、これを通してデータがプロダクション・サーバとローカル・サーバ間で渡される。建物のローダ・インタフェースは、プロダクション・サーバとローカル・サーバ間で渡されるデータを暗号化し、ローカル・サーバがシステムに関連するサーバであることを認証する。

プロダクション・サーバは課金モジュールを含み、これはエレベータのディスプレイ・ユニットで一般情報および商業情報を表示した継続時間に関する文書を作成する。データ
ベース保守モジュールもプロダクション・サーバに含まれ、時間の関数としてエレベータ占有率に関する情報でプロダクション・センタ・データベースを更新する。

ローカル・サーバは、スケジューリング情報パーサを含むローカル・エリア・ネットワークを介して、ローカルおよび一般情報データベースをエレベータ・ディスプレイ・ユニットと通信する。データ通信路で検索した一般情報および商業情報は、ローカルおよび一般情報データベースのそれぞれにキャッシュされる。スケジューリング情報パーサは、プロダクション・サーバから検索したスケジューリング情報からローカル建物プレイ・リストを作成する。

ローカル・エリア・ネットワークは、エレベータのディスプレイ・ユニットと接続するためのイーサネット路を含む。エレベータのディスプレイ・ユニットは、さらに、所定の間隔で特定のエレベータに乗っている占有者の数を判別する占有率検出器を含む。

エレベータ・プレイ・リストの作成は、グラフィカル・ユーザ・インタフェースで実行される。
ＢＯＭインタフェースでは、ビデオ情報はテキスト・メッセージ（例えば、ＨＴＭＬのフォーマット）を含み、プレイ・リストは、テキスト・メッセージがディスプレイ・モニタに表示される開始日、テキスト・メッセージがディスプレイ・モニタに表示される最終日、および１日のうちテキスト・メッセージがディスプレイ・モニタに表示される部分を示す日区画を含む。

ユーザ・インタフェースは、前記ローカル・サーバから遠隔で、インターネット、ダイアルアップ・モデム、またはローカル・エリア・ネットワークなどのデータ通信路を介して前記ローカル・サーバと通信する。プレイ・リストは、建物の運転プレイ・リストで、建物の運転に関する建物運転プレイ・リストを作成するためのビデオ情報およびスケジューリング情報を伴う。

ローカル・サーバは、さらに、データ通信網を介して前記ローカル・サーバから遠隔のプロダクション・サーバからプロダクション・サーバ・プレイ・リストを受信し、前記プロダクション・サーバ・プレイ・リストは、ディスプレイ・ユニットに表示するための一般および商業情報を伴う。ローカル・サーバはパーサを含み、これはプロダクション・サーバ・プレイ・リストおよび建物運転プレイからローカル建物プレイ・リストを作成する。

本発明の他の特徴は、以下の説明および特許請求の範囲から明らかになるだろう。

本発明の情報配信システムのブロック図。小地域人口統計の概念。図１の情報配信システムの建物サブシステム部分のブロック図。図３のディスプレイ・モニタのディスプレイ・スクリーンの例。図１のプロダクション・センタのブロック図。プロダクション・センタのスケジューラ・モジュールのオペレーションの流れ図。プレイ・リストのフォーマット。図３の建物サブシステム部分の建物サーバの機能的ブロック図。建物のサーバと配信チャネル間の広域インタフェースの機能的ブロック図。ディスプレイ・ゼネレータＬＡＮインタフェースの機能的ブロック図。ディスプレイ・サーバ・アーキテクチャの機能的ブロック図。本発明の情報配信システムのＢＯＭインタフェースを示すブロック図。メッセージを作成するためにＢＯＭインタフェースが使用するメッセージ・テンプレートの例。ＢＯＭプレイ・リストのフォーマット。図１２の建物サブシステム部分の建物サーバの機能的ブロック図。ＢＯＭインタフェースのパース機能のオペレーションを示す流れ図。ローカル建物プレイ・リストのフォーマット。ディスプレイ・サーバ・アーキテクチャの機能的ブロック図。本発明の情報配信システムのブロック図。本発明の方法のコンテンツ検索手順の機能的ブロック図。本発明の方法の確認手順を示す流れ図。本発明の方法の更新手順を示す流れ図。本発明の方法のローカル・プレイ・リスト開発手順の機能的ブロック図。本発明のプロセスの包括的プレイ・リスト拡張手順の図。本発明の情報配信システムのＢＯＭインタフェースの代替実施形態を示すブロック図。

（好ましい実施形態の説明）
図１について説明すると、情報配信システム１は、高層オフィス・ビル１４（点線のボックスで図示）のエレベータ１２に搭載したエレベータ・ディスプレイ・ユニット１０に、ディジタル広告とともに一般情報を配信する媒体出口を提供する。システム１はプロダクション・センタ２０を含み、これは以下で説明する他の重要なタスクの中でも特に、広告を「リアルタイム」の一般情報とマージすることによってエレベータ・ディスプレイ・データを作成し、配信する。一般情報が「リアルタイム」と見なされるのは、システム１が人間の介入がない状態で情報を収集し、フォーマット化して表示する状態で、情報が比較的現在のものだからである（規定された間隔でリフレッシュされる）。一般情報は、配信チャネル、つまり本発明ではインターネット２４を介して接続された任意の数のソース２２（例えば、ウェブサイト）によって提供される。

各建物１４は建物サーバ２８を含み、これはインターネット２４を介してプロダクション・センタ２０とインタフェースをとり、エレベータのディスプレイ・ユニットに提示すべきマージされた広告および一般情報の提示を展開する。以下でさらに詳細に説明するように、各建物サーバは、ローカル・エリア・ネットワーク（ＬＡＮ）３０を介して関連のエレベータ１２の各エレベータ・ディスプレイ・ユニット１０に一般および広告情報を提供する。

情報配信システム１は、「小地域人口統計」と呼ばれる概念を使用し、これによって広告主およびオンライン・プロバイダは高度に望ましい人口統計、ビジネス人口に標的を絞ることができる。特定の広告主またはオンライン・プロバイダが標的とする所望の観衆は、多種多様であり、幾つかの要素によって決定される。以下で検討するように、システム１は、特定の建物およびその建物の占有者に関連する人口統計を収集するか、その他の方法で判別する。したがって、建物の地理的位置およびエレベータの交通パターン、および建物占有者のビジネスの性質が、プロダクション・センタ２０によって判別されて、記憶され、したがって広告および一般（「リアルタイム」）コンテンツの建物に関するスクリプトまたはプレイ・リスト６８（図５）を建物と一致させることができる。

図２について説明すると、建物１４は、特定の地理的地域に属することを示すために、円で囲んで図示されている。より小さい円で囲んだグループ７ａ〜７ｆは、例えば市（例えば、ボストン）内の建物１４を表し、市も、より大きい地理的地域８ａ〜８ｂ（例えば
、ニューイングランド）によって円で囲んで図示されている。地理は、一般に非常に重要な人口統計の要素であるが、標的とする特定のビジネス区分も同様に重要である。したがって、異なる地理的地域にあるが、同じビジネス区分の母集団（例えば、金融）に関連する幾つかの建物１４ａ〜１４ｃをまとめることができる（網掛け部分で境界を区切って図示）。地理とビジネス区分との両方で人口統計を分割する能力は、コンテンツ・プロバイダおよび広告主に多大な価値を提供する。

システムの１つの用途の例では、広告主が、米国の北東地域にある金融社会を特に標的とする広告を配信したいものとする。広告は、午前中のプライム・タイムの時間に２週間表示する必要がある。プロダクション・センタ２０は、標的の人口統計を表すこの関連情報を捕捉するための自動化した要求入力プロセスを広告主に提供する。プロダクション・センタ２０は、標的の人口統計から、広告にとって可能性がある建物の候補の建物プレイ・リスト６８を作成し、広告を表示すべき時間に関して可能な実行時間スロットを定義する。幾つの建物が候補になるか、およびどの時間スロットが使用可能であるかに影響を与える要素は、次のように幾つかある。つまり標的の人口統計（例えば、米国北東部の金融社会）、広告インプレッション数（つまり広告を見る回数）、広告の開始および終了日（例えば、２週間の開始および終了）、プライム・タイムの要件（つまりプライム・タイムの朝）、広告のフォーマット（２８０×９０のアニメＧＩＦファイル）、および広告ロケータ（ＧＩＦファイルの配置場所）である。広告の時間スロットが識別されたら、プロダクション・センタ２０は、オンライン・プロバイダによって提供され、マージして広告と一緒に表示すべき一般情報（例えば、ニュース項目、天候の更新）を決定する。建物のプレイ・リスト６８は、刻々、エレベータ・ディスプレイのフォーマットおよびコンテンツを示している。したがって、例ではプロダクション・センタ２０が、９：００ａ．ｍ．と１５秒に地元のニュース項目と同時に１つの建物プレイ・リストで広告を表示し、同じ広告を８：１５ａ．ｍ．と０秒に別の建物のプレイ・リストで天候の更新とともに表示するようスケジュールする。建物のプレイ・リスト６８は、何をいつ表示するか定義するが、実際の表示内容は含まないことに留意されたい。代わりに、建物のプレイ・リスト６８は、インターネット２４で情報を獲得するためのポインタを提供する。

広告に関する情報を建物のプレイ・リストに埋め込んだ状態で、プロダクション・センタ２０は広告をエレベータの占有者に提示しなければならない。建物のサーバ２８は、プロダクション・センタ２０から建物のプレイ・リストをダウンロードし、インターネット２４で特定の広告および一般情報を検索して、その後、エレベータのディスプレイ・ユニット１０で見るべきディスプレイ内に広告および情報をアセンブルし、配信することを担当する。建物サーバ２８は、プレイ・リスト６８のポインタを使用して、コンテンツを検索し、それを特定の建物１４にローカルに記憶させる。これによって、建物サーバ２８は建物１４内に非常に高い性能のブロードキャスト・チャネルを作成することができる。この例では、建物サーバ２８がプレイ・リスト６８に埋め込まれた広告ロケータを使用して、広告のアニメＧＩＦファイルをローカルに検索して記憶する。コンテンツがローカルに記憶された状態で、建物サーバ２８はプレイ・リスト６８を読み取り、リストによって指示された時間でディスプレイをアセンブリし、それを個々のエレベータ１２に配信する。したがって、この例では９：００ａ．ｍ．と１５秒で建物サーバ２８が広告を指定のローカル・ニュースとアセンブルし、これをエレベータ１２に表示する。

情報配信システム１の主要なコンポーネントに関する詳細は以下の通りである。
図３について説明すると、エレベータ・ディスプレイ・ユニット（ＥＤＵ）１０は、建物サーバ２８によって提供されたデータを受信して処理し、ディスプレイ・プレゼンテーションを作成する。エレベータ・ディスプレイ・ユニット１０は、シングル・ボード・コンピュータ３４およびネットワーク・インタフェース・カード（ＮＩＣ）３６によって制御されたディスプレイ１３を含む。ディスプレイ１３はＬＣＤコントローラ、バックライ
ト・アセンブリ、電力変換器、およびフラット・パネル・ディスプレイ（いずれも図示せず）を含む。コンピュータ３４は、システムの設定およびモニタリング、ネットワーク・オーバヘッド、ディスプレイ・データのルーチン、およびエレベータの占有率を含め、エレベータ・ディスプレイ・ユニット１０のオペレーションを管理する。ネットワーク・インタフェース・カード３６はローカル・エリア・ネットワーク３０と対話し、システム設定中にコンピュータ３４によって構成される。建物のサーバ２８からエレベータ・ディスプレイ・ユニット１０へと下流にブロードキャストされるディスプレイ・データは、ネットワーク・トラヒックの大部分を表す。下流方向（建物のサーバ２８からエレベータ・ディスプレイ・ユニット１０へ）では、ネットワーク・トラヒックが主にディスプレイ・ブロードキャスト・データで構成される。下流方向には制限された量の制御情報があるが、これは無視することができる。ネットワーク・インタフェース・カード３６は、ディスプレイ・データを直接ディスプレイ１３へと経路指示する。制御情報は、サービスを要求するようコンピュータ３４への割り込みを作成する。上流方向（エレベータ・ディスプレイ・ユニット１０から建物のサーバ２８へ）では、ネットワーク・トラヒックは占有率情報およびシステム・モニタリング・データを含む。上流へのデータは全て、コンピュータ３４によって作成され、送信するためにネットワーク・インタフェース・カード３６に渡される。

建物サーバ２８からのデータは、ローカル・エリア・ネットワーク３０（点線で囲んで図示）を介して各エレベータ・ディスプレイ・ユニット１０へ送信される。特に、データはデータ・フローを管理するために、イーサネット・ネットワーク・スイッチ４０を介して銅の撚り線対ライン３８を通して送信される。

まだ検討していないシステム５の重要な特徴の１つは、閉ループの性質である。広告はインプレッション（つまり広告を見る回数）に基づき測定される。システム１によって送付されたインプレッションの数を定量化するには、エレベータ占有率の測定を使用して作成されるシステムのフィードバックが必要である。

システム１にフィードバックを提供するには、各エレベータ・ディスプレイ・ユニット１０が、所定の間隔（例えば、５秒ごと）で一日中特定のエレベータの占有者数を判別するため、占有率検出器４２を含む。この情報は、建物ごとに要約され、１日に１回、通常は停止期間中に建物サーバ２８を介してプロダクション・センタ２０へとアップロードされる。プロダクション・センタ２０は、プロダクション・センタ・データベース６０（図５）の課金および保守のためにフィードバックを使用する。特に、このフィードバックは、まだ表示される広告のインプレッションを更新し、各建物の統計的トラヒック情報を作成するために使用される。このデータは、スケジューリングおよび広告販売のプロセスには非常に重要である。

占有率検出器４２は、乗員がエレベータを出入りする時に１対のパルスを生成するセンサ（図示せず）を使用する。センサは、例えばエレベータのドアに埋め込まれる。センサのパルス特性は、乗員がエレベータに乗り込むのか、出るのかを規定する。占有率検出器４２は、これらのセンサに基づいて占有率のカウントを維持する。コンピュータ３４は、定期的に占有率カウントのサンプルをとる。したがって、各エレベータ・ディスプレイ・ユニット１０は、広告課金プロセスに使用する日毎の占有率履歴を作成する。

図４について説明すると、建物サーバ２８の制御下で、ディスプレイ１３は、特定のタイプの情報がディスプレイの特定の領域に表示されるよう区分化される。ディスプレイ１３は、広告および他の商業情報を表示する広告バナー・セクション４４、および一般情報を見る「リアルタイム」コンテンツ・セクション４６を含む。「リアルタイム」コンテンツ・セクション４８は、他のセクションに分割し、例えばストーリーの抜粋５０、抜粋に
関する１つまたは複数のピクチャ５２、およびピクチャ５４の記述を呈する。例えば、本明細書で示すように、エレベータの乗員には、バナー・セクション４４で、例えば建物１４の１階にあるカフェからその日の朝食スペシャル・メニューが提供される。同時に、一般的関心があるニュース・テキストが、関連のピクチャ５４とともにストーリー抜粋５０内に表示される。

上述したように、プロダクション・センタ２０の主な機能は、エレベータ・ディスプレイ・データを作成し、配信することである。エレベータ・ディスプレイ・データの作成は、ニュース、情報および広告をマージして建物固有のプレイ・リスト６８を生成することを含む。プレイ・リストの配信は、インターネット２４を介した接続性を使用して達成される。

プロダクション・センタ２０の別の重要な機能は、システム１のウェブサイトの管理および保守である。ウェブサイトは、建物１４およびセントラル・ロケーションの管理を提供し、ここで潜在的広告主はシステム上の広告に関する情報を要求することができる。エレベータの占有者も、表示された「リアルタイム」情報またはエレベータ１２のディスプレイ１３で見た広告情報に関連する追加情報のため、ウェブサイトにアクセスすることができる。例えば、ある占有者が特定の広告の詳細（例えば、建物の食事施設のいずれかにおける今日のスペシャル・メニュー）について覚えていないことや、「リアルタイム」コンテンツ・セクション４８で表示されたニュース・ストーリーの中断に関してさらに知りたいことがある。
プロダクション・センタ図５について説明すると、プロダクション・センタ２０はプロダクション・センタ・データベース６０、スケジューリング・モジュール６２、建物ローダ６４、および課金およびデータベース保守モジュール６６を含む。一般に、プロダクション・センタ・データベース６０は、広告、「リアルタイム」コンテンツ、および建物パラメータに関するデータを記憶する。

スケジューリング・モジュール６２は、このデータを使用して各建物１４のプレイ・リスト６８を作成する。上記で検討したように、建物プレイ・リスト６８（図５）は、建物サーバ２８が使用するレシピとして働き、一日中提示されるディスプレイ・プレゼンテーションを作成する。スケジューリング・モジュール６２は、課金およびデータベース保守モジュール６６に広告およびコンテンツの使用情報も提供し、各広告主および「リアルタイム」コンテンツの供給業者に対する課金要約およびインボイス７０を作成する。課金要約およびインボイス７０は、後に検索するためにプロダクション・センタ・データベース６０にも記憶される。
プロダクション・センタ・データベース
プロダクション・センタ・データベース６０は３つの基本的タイプのデータを含む。つまり１）建物の特徴付け、２）「リアルタイム」コンテンツ、および３）広告コンテンツである。

建物の特徴付けデータは、特定の建物の小地域人口統計プロフィールを確立するために作成される。小地域人口統計の作成は、建物の特徴付けプロセスから開始する。建物の特徴付けプロセスは３つの要素で構成される。つまり１）建物の地理−建物はどこにあるか（市、州、地域など）、２）ビジネス区分−建物の人口をビジネス区分にカテゴライズする（銀行、保険、金融サービス、法律、広告、不動産など）、３）自己学習−インストールされると、システムは建物の特徴付けを学習することができる。ピークの移動期間（プライム・タイム期間を確立するために使用）およびエレベータの平均占有率（スケジューリングに重要）が、自己学習された特徴付けの例である。

特徴付けプロセスの結果は、スケジューリング・プロセスに使用するためにプロダクシ
ョン・センタ・データベース６０に建物の特徴付けデータとして記憶され、以下の表Ｉに挙げる情報を含む。

特徴付けプロセスの結果は、プロダクション・センタ・データベース６０に記憶される。このデータのフォーマットは、建物の特徴付けデータの項目で説明する。オンライン・コンテンツ・プロバイダおよび広告主は、観衆の小地域人口統計を指定することにより、その標的となる観衆と建物の間を関連付けることができる。広告主の小地域人口統計の選択肢は、表Ｉに示す建物の特徴付けカテゴリと１対１でマップされ、したがって関連付けを確実にする。以下で説明するように、スケジューリング・モジュールは、これらの関連付けを介して建物の広告をマップする。

上述したように、「リアルタイム」情報（一般情報）は、エレベータ・ディスプレイ・データを作成するために広告データとマージされるデータである。それを遂行するために、「リアルタイム」情報の内容を特定のフォーマット準拠させねばならず、フォーマットはディスプレイ１３のセグメント・セクション４４、４６を表し、そのセグメント（図４）に含まれる内容５０、５２、５４を記述する。

例えば、各「リアルタイム」コンテンツのソース２２（図１）ごとに、プロダクション・センタ・データベース６０は、フォーマットのタイプおよびそのフォーマット内における各コンテンツ・セグメントの位置を記述する項目を含む。フォーマットは、項目ごとにセグメント数を決定する。位置はユニバーサル・リソース・ロケータ（ＵＲＬ）を使用し
て記述される。各「リアルタイム」コンテンツ・ソースに維持されたデータベース・パラメータを、下記の表ＩＩに示す。

広告コンテンツのデータは２つの要素で構成される。第１の要素は、広告を実行する時間、実行する場所、およびその継続時間を定義する。第２の要素は、広告の検索先、およびディスプレイへの挿入方法を記述する。まず実行パラメータについて考えてみる。広告主は、システムの広告時間をインプレッション１０００回当たりのコスト（ＣＰＭ）単位で購入する。広告主は、さらに、広告を全国、地方、地域または特定のビジネス区分に配信するよう要求することによって、特定の人口統計に標的を絞ることができる。また、広告キャンペーンは時間パラメータも有する可能性が高い。例えば、キャンペーンを２週間だけ実行し、毎日１０：００ＡＭと１：００ＰＭの間に露出を要求することができる。これらの事柄は広告実行パラメータを構成する。同様に重要なのは、実際の広告内容およびそれをシステムに統合して表示する方法である。この情報を記述するパラメータは、広告ロケータおよびフォーマット・タイプを含むコンテンツ・パラメータである。広告コンテンツ・ソースごとに維持されるデータベース・パラメータを、下記の表ＩＩＩに示す。

スケジューリング・モジュール
スケジューリング・モジュール６２は、プロダクション・センタ・データベース６０からの広告および「リアルタイム」コンテンツの両方を作成し、次にコンテンツをマージすることにより、建物のプレイ・リストを作成するという１次機能を有する。

図６について説明すると、スケジューリング・モジュール６２は、プロダクション・センタ・データベース６０にある各広告の標的となる可能性がある建物はどれかを決定するという第１のパース・ステップ（１００）を実行する。スケジューリング・モジュール６２は、自動化した要求入力プロセスで広告主から提供された情報を使用し、相互に対にすることができる建物と広告の初期リスト７２を作成する。入力プロセスは、広告主がプロダクション・センタのウェブサイトを使用して利用することができ、このウェブサイトは、標的となる人口統計、ビジネス人口に見せるために広告のスケジュールを立てるのに必要な情報を、広告主が入力することができる電子入力フォームを提供する。あるいは、広告主は電話でのインタビュー、申込用紙、または第三者の代理人を通して関連情報を提供してもよい。初期リスト７２は、さらに第２のパース・ステップ（１０２）で、広告開始／終了日、プライム・タイムの要件、送付時間、およびインプレッション・パラメータなどの第２の基準を使用して剪定する。この対にするステップの結果、広告、およびその広告を表示できる可能性がある時間間隔を指示する建物固有の広告リスト６８が作成される。

次に、スケジューラ・モジュール６２は、建物（１０４）に関連した建物の特徴付けデータ（表Ｉ参照）によって記述された各建物の「リアルタイム」コンテンツの優先度を考慮する。この情報を使用して、「リアルタイム」コンテンツの建物固有の「リアルタイム」リスト７６が作成される。

特定の建物について指定された広告コンテンツおよび「リアルタイム」コンテンツの両方で、スケジューラ・モジュール６２はリスト７４および７６をマージし、建物プレイ・リスト６８（１０６）を提供する。特に、各建物１４の広告および「リアルタイム」コンテンツをマージする場合、スケジューラ・モジュール６２はコンテンツのフォーマット、時間間隔、および広告の配信を考慮する。時間間隔および広告の配信を最初に考慮する。何故なら、これが広告の表示時間、およびそれに付随する「リアルタイム」コンテンツを決定するからである。「リアルタイム」コンテンツは固定の間隔（例えば、３０秒ごと）で提示される。その結果、スケジューラ・モジュール６２は「リアルタイム」コンテンツを最初に配置する。

広告の配置は、配信および占有率の考慮事項にも依存する。ネットワークの観衆の通信パターンは常に、特定の広告を効果的に配信する上で重要な配信の考慮事項である。例えば、大部分の人は、毎日、同じ時刻から３０分以内に職場に到着し、昼食をとって、退社する。したがって、スケジューラ・モジュール６２は、同じ広告が任意の建物で前日に実行した時刻から３０分以内に実行されないことを確実にする。その結果、建物の人口統計内で、より均一に広告が配信される。広告の占有率も重要な考慮事項である。広告は迅速に（例えば、１５秒ごとに）回転することができる。しかし、十分に埋まった広告スケジュールがない場合、システム１は同じ広告を、または限られたセットの広告を絶えず回転させる。これは、エレベータの乗員にとって魅力的でなく、不快感を与える可能性がある。このような不快感を解消するために、スケジューラ・モジュール６２は各広告の表示期間を延長し、遷移を目立たなくする。

各時間スロットについて、広告および「リアルタイム」コンテンツが定義されたら、スケジューラ・モジュール６２はディスプレイを作成する。広告および「リアルタイム」コンテンツのフォーマットは重要である。何故なら、多様なテンプレートのうちどれを選択
して全体的なディスプレイを作成するか、決定するのはこのフォーマットだからである。前述したように、広告および「リアルタイム」コンテンツは、所定のフォーマットのセットいずれかに準拠しなければならない。両方を相互にマージする場合は、これをフレームに入れる。フレームは、最終的ディスプレイを作成する元となるテンプレートを表す。コンテンツのフォーマットは変化することがあるので、スケジューラ・モジュール６２は、それをマージするための適切なフレーム・タイプを選択する。コンテンツ・フォーマットの数は、マージ・プロセスを単純にするため、意図的に制限される。時間スロットおよびフレーム・タイプの情報が定義されたら、スケジューラ・モジュール６２は建物のプレイ・リスト６８を構築することができる。

図７について説明すると、「リアルタイム」コンテンツ・データと広告コンテンツ両方のアセンブリを管理するために使用する建物プレイ・リスト６８が図示されている。プレイ・リスト７８は「リアルタイム」コンテンツ・セクション８０を含み、これはプロダクション・センタ・データベース６０内の「リアルタイム」データから直接作成され、「リアルタイム」コンテンツのリフレッシュ期間を定義する。プレイ・リスト７８は、広告コンテンツに使用する時間およびフレーム・タイプを定義する広告コンテンツ・セクション８２も含む。

再び図５について説明すると、プロダクション・センタ２０は、プロダクション・センタ２０とシステム１内の建物１４とのインタフェースをとる働きをする建物のローダ６４も含む。建物との通信はインターネット２４で実行されるので、安価ではあるが広域の配信機構が提供される。残念ながら、インターネット２４は、システムを破壊する可能性があることにもなる。この危険を考慮して、システム１は、各建物サーバ２８がプロダクション・センタ２０のブロードキャスト・データを有するのではなく、プロダクション・センタ２０からの情報を要求する必要があるよう設計される。建物ローダ６４は、建物がプレイ・リストを要求するごとに、その要求がシステム１に関連し、それに認識されたサーバから送られていることを確実にする認証手順を実行する。建物ローダ６４は、配信する前にプレイ・リストを暗号化して、潜在的な破壊から情報をさらに保護する。
課金およびデータベース保守モジュール
課金およびデータベース保守も、システム１の閉ループの性質にとって非常に重要である。上記で検討したように、スケジューリング・モジュール６２は、小地域人口統計パラメータ、および特定の建物で所与の時間に広告インプレッションが作成される数という統計的確率に基づいて建物プレイ・リストを作成する。システムのループを閉じるには、エレベータ占有率の情報を１日単位で１４の建物ごとに累積する。これによってシステム１は、建物の特徴に合わせて変化し、広告およびコンテンツの配信が向上するような構成にすることができる。課金およびデータベース保守モジュール６６を使用して、このフィードバックをシステム１に提供する。この２つのオペレーション、つまり課金とデータベース保守は、同じプロセスに影響を与えるが、異なる出力を送付する。フィードバック・プロセスは、建物プレイ・リスト６８を建物占有率の数字に重ねる。このプロセスから、広告ごとに実際のインプレッション数を計算することができる。課金オペレーションは、情報を使用して広告主へのレポートおよびインボイス７０を作成する。データベース保守オペレーションは、このデータを使用し、まだ配信されていない各広告のインプレッションでプロダクション・センタ・データベース６０を更新する。つまり、「未配信インプレッション」（表ＩＩＩ参照）の数を更新する。また、課金およびデータベース保守モジュール６６は、さらに、建物占有率の数字を変更して建物の特徴付けデータを更新する。例えば、課金およびデータベース保守モジュール６６は、「建物時間」、「プライム・タイム期間」、および「エレベータの平均占有率」（表Ｉ参照）とラベルを付けたフィールドを更新することができる。ここで重要なフィードバックは、デッド・ゾーン（エレベータの乗員が少ない時間）、ピーク視聴期間、およびエレベータの平均占有率を定義することである。これらは、スケジューリング・モジュール６２がスケジューリング・プロセスで使
用する重要なパラメータである。
建物サーバ
一般に、建物サーバ２８はプロダクション・センタ２０とインタフェースをとり、広告および「リアルタイム」コンテンツをキャッシュし、エレベータのディスプレイを発展させて、ローカル・エリア・ネットワーク３０を管理する。

図８について説明すると、建物サーバ２８は、プロダクション・センタ２０およびインターネット２４との通信を担当するプロダクション・センタ／ＷＡＮ（ＰＣＷＡＮ）インタフェース９０を含む。前述したように、各建物１４はプロダクション・センタ２０からプレイ・リスト６８を受信し、これはディスプレイ・コンテンツおよびディスプレイ・コンテンツを提示する時間間隔を定義する。インターネット２４は、「リアルタイム」コンテンツを捕捉して広告情報を移送するために使用される。インタフェース９０からの「リアルタイム」出力はローカル「リアルタイム」データベース９２に預けられ、インターネット２４から受信した広告出力は広告データベース９４にキャッシュされる。これは、インターネットを介して検索した情報のローカル・コピーを表す。ローカル・コピーは、待ち時間の問題を回避するために維持される。これは、例えば、アニメーション、ストリーミング・ビデオ、およびムービー・エフェクトなど、高性能のディスプレイ提示の作成を現実的に阻止する。データベースの更新は、建物プレイ・リストによって定義されたとおり、必要に応じて実行される。

コンテンツのアセンブリおよび表示は、建物プレイ・リスト６８を解釈して、指定されたコンテンツをアセンブルするディスプレイ・ゼネレータ／ＬＡＮ（ＤＧＬＡＮ）インタフェース９６によって実行される。結果はＨＴＭＬファイルで、ローカル・エリア・ネットワーク３０を介して各エレベータ・ディスプレイ・ユニット１０へと送られる。

建物サーバ２８は、建物の個々のエレベータ１２の占有率に関する情報を記憶する占有率データベース９８も含む。
プロダクション・センタ／ＷＡＮインタフェース
図９について説明すると、ＰＣＷＡＮインタフェース９０は、インターネット２４との対話を管理する。ワイド・エリア・ネットワーク（ＷＡＮ）との対話は一般に、システム内のセキュリティを向上させるために建物から開始する。ＰＣＷＡＮインタフェース９０はプレイ・リスト・パーサ１１０を含み、これは広告および「リアルタイム」コンテンツのローカル・リファレンスを作成するための翻訳を実行する。翻訳が必要であるのは、建物１４内で表示される全コンテンツがデータベース９２、９４内でローカルにキャッシュされるからである。したがって、元のプレイ・リストに含まれるＷＡＮベースのＵＲＬが無効になる。パーサ１１０は、広告コンテンツ累算器１１２とも対話する。広告は建物にローカルで記憶されるので、累算プロセスを実行し、このローカル記憶を作成しなければならない。パーサ１１０は、プレイ・リストが、広告コンテンツ・データベースで現在使用可能でない広告を含むと判断した場合に、広告累算を開始する。累算器の機能は、ＷＡＮとインタフェースをとって失われたコンテンツを検索し、それをデータベースに記憶する。広告のローカルＵＲＬが返され、これをパーサがローカル建物プレイ・リストに書き込む。「リアルタイム」コンテンツでも同様のオペレーションを実行する。しかし、この場合は、リフレッシュ期間に基づいて更新を実行する。「リアルタイム」コンテンツのリフレッシュ期間は、建物プレイ・リストで定義される。プレイ・リスト・パーサ１１０は、リフレッシュ期間、ＷＡＮベースのＵＲＬ、および「リアルタイム」データベース・アドレスを「リアルタイム」プロキシ・モジュール１１６に渡す。プロキシ・モジュール１１６は、リフレッシュ・サイクルのスケジュールを作成し、ＷＡＮインタフェース・コントロール１０９とインタフェースをとって、「リアルタイム」コンテンツを検索する。コンテンツは、パーサ１１０が提供するロケータに基づいて記憶される。
ディスプレイ・ゼネレータ／ＬＡＮインタフェース
図１０について説明すると、ディスプレイ・ゼネレータ／ＬＡＮ（ＤＧＬＡＮ）インタフェース９６は２つの別個のオペレーション、つまり１）ディスプレイのアセンブルおよび転送、および２）占有率データの収集を実行する。

この第２のオペレーションに関して、占有率の計算はシステムの非常に重要な役割を果たす。広告は、インプレッション１０００回当たりのコスト（ＣＰＭ）の増分で測定される。インプレッションは、広告に露出される人と定義される。システム１では、広告露出はエレベータ１２で生じる。システム１を使用して表示される広告インプレッションの数を定量化するため、エレベータ占有率を測定する方法が必要である。ＤＧＬＡＮインタフェース９６は、各エレベータで測定した情報を累算し、各建物１４の占有率データベース９８を作成する。占有率累算器１３０は、システムの停止中に（通常は１日の最後に）各エレベータから測定データを抽出する。この情報は、１日中、一定間隔でエレベータ占有率を提供する。占有率累算器１３０はこの情報を要約して１つのリストにし、これを課金のためにプロダクション・センタ２０に渡す。

ディスプレイのアセンブルおよび転送は、ＤＧＬＡＮインタフェース９６の主な機能である。ディスプレイ・アセンブリはローカル建物プレイ・リスト１１４に命令され、これは図５の建物プレイ・リスト６８と同じフォーマットを使用するが、「リアルタイム」制御パラメータが削除され、全てのコンテンツ・ロケータ（例えば、ＵＲＬ）がローカルの同等品に置換されている。ＤＧＬＡＮインタフェース９６は、ディスプレイ・フォーマット・パーサ１２０およびディスプレイ・アセンブラ１２２を含む。ディスプレイ・フォーマット・パーサ１２０は、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）を使用してディスプレイのフレームワークを構築する。ＨＴＭＬは、インターネット２４で専用に使用されて表示情報を展開し、現代のブラウザ・テクノロジーによって容易に理解される。ディスプレイ・フォーマット・パーサ１２０は、一杯になったら実際のディスプレイを作成するために使用されるＨＴＭＬテンプレートを作成する。ローカル建物プレイ・リスト１１４はフレームのタイプを定義する。ディスプレイ・パーサ１２０は、フレームのタイプを解釈してＨＴＭＬファイルを作成し、ディスプレイの物理属性を指定する。これらの属性には、各コンテンツ・セグメントの絶対位置、サイズおよび定義が含まれる。テンプレートにないのは、これらのコンテンツ・セグメントへのポインタである。コンテンツ・セグメント・ポインタは、ディスプレイ・アセンブラ１２２によって作成される。

ディスプレイ・アセンブリ１２２は、ディスプレイ作成サイクルの最終ステップで使用される。ディスプレイ・アセンブリは、プレイ・リストで定義された時間間隔に基づいて開始される。各ディスプレイは、その時間インジケータの定義に従ってアセンブルされ、ディスプレイ・サーバ１２４に渡される。ディスプレイ・アセンブラ１２２は、ディスプレイ・フォーマット・パーサ１２０によって作成されたＨＴＭＬテンプレートをパースし、コンテンツ・セグメントの定義を見つける。テンプレートは、プレイ・リスト１１４で指定されたコンテンツ・セグメントの定義と一致する。その結果、ディスプレイ・アセンブラ１２２は、各コンテンツ・セグメントの位置ポインタを挿入する。各コンテンツ・セグメント・ポインタが挿入されると、ＨＴＭＬファイルはいつでもエレベータ・ディスプレイ・ユニット１０に渡すことができる。

エレベータ・ディスプレイ・ユニット１０は、ローカル・エリア・ネットワーク３０を介して建物のサーバ２８に接続される。ディスプレイ・サーバ１２４は、ＨＴＭＬによって指定された「リアルタイム」および広告コンテンツとともにディスプレイ・アセンブラ１２２からＨＴＭＬファイルを検索することにより、ローカル・エリア・ネットワーク３０を管理する。次に、ディスプレイ・サーバ１２４は、このデータを翻訳して、エレベータ・ディスプレイ・ユニット１０に適合するディスプレイ・フォーマットにし、転送プロトコルで翻訳済みデータをカプセル化して、カプセル化したデータを放送のためにネット
ワーク・スイッチ４０（図３）に渡す。ディスプレイ・アセンブラ１２２からデータを検索するタスクは、エレベータ・ディスプレイ・ユニット１１から別個の建物サーバ２８への距離が大きい（例えば、＞１５００フィート）ことによって、さらに困難になる。

図１１について説明すると、ディスプレイ・サーバ１２４およびエレベータ・ディスプレイ・ユニット１０が、ネットワーク接続されたホスト／ディスプレイのペアを形成し、エレベータ・ディスプレイ１３は、サーバ・ディスプレイの延長にすぎない。ＨＴＭＬファイルはブラウザ１３６（例えば、インターネット・エクスプローラ４．０、ＭｉｃｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎ（登録商標）の製品）、ブラウザ１３６によって、建物サーバ２８が使用するオペレーティング・システム（例えば、ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓＮＴ、ＭｉｃｒｏｓｏｆｔＣｏｒｐｏｒａｔｉｏｎ（登録商標）の製品）内で解釈され、ディスプレイ・ドライバ１３８とインタフェースをとって、ディスプレイ１３に関連するハードウェアと通信する。表示データは、翻訳機１４０によって抽出され、これはデータの標的をエレベータ・ディスプレイ・ユニット１０およびディスプレイ１３に変更する。このデータは、ローカルでサーバ２８にキャッシュされ、ブラウザのリフレッシュ遅延の効果を軽減する。ネットワーク・プロトコル・カプセル化ソフトウェア・モジュール１４２は、キャッシュからデータを抽出し、ＴＣＰ／ＩＰ通信レイヤを追加する。カプセル化したデータはネットワーク・インタフェースに渡され、ネットワーク・スイッチ３０（図３）を通してＬＡＮに送信される。

他の実施形態は、特許請求の範囲によって支持される。例えば、上述した情報配信システム１が使用する配信チャネルはインターネット２４である。インターネット、つまり「ウェブ」は、情報を獲得し、コンピュータ間の通信を確立するために、増大する既存のインフラを提供する。しかし、情報配信システム１は、ケーブル・モデム、衛星、ＸＤＳＬなど、他の通信チャネルを使用して実装することもできる。

図４に関連して上記で検討した撚り線対ライン３８を、光ファイバ、同軸ライン、ＲＦ送信など、他の移送媒体の形態で置換することができる。さらに、特定の用途では、非対称ディジタル加入者回線（ＡＤＳＬ）を、図３のローカル・エリア・ネットワーク３０のイーサネット接続を置換してもよい。
建物所有者管理プログラム（ＢＯＭ）インタフェース
図１に示す情報配信システム１は、上記では、建物サーバ２８とインタフェースをとって、エレベータ・ディスプレイ・ユニット１０で表示するためにマージされた広告および一般情報の提示を展開するプロダクション・センタ２０を含むよう説明してきた。上述したように、システム１は、建物の所有者および管理者に、その建物に居住するテナントと通信する能力を提供することができる。直後で説明するように、この能力は、建物所有者管理プログラム（ＢＯＭ）インタフェースを通して建物の管理者に提供される。

例えば図１２について説明すると、ＢＯＭインタフェース２００は、配信チャネル２４を介して１つまたは複数の建物サブシステム２０４と通信するＢＯＭインタフェース（ＢＯＭＧＵＩ）２０２を含むよう図示されている。建物サブシステム２０４は、建物サーバ２８、建物ＬＡＮ３０、およびエレベータ１２に装着されたエレベータ・ディスプレイ・ユニット１０を含む建物ディスプレイ・ユニット２０６を含むよう図示されている。配信チャネル２４は、図１に示すよう、例えば、インターネットで表される。この場合、配信チャネル２４は、公衆建物ＬＡＮ２０８、ダイアルアップ・モデム２１０、さらにインターネット・サービス・プロバイダ２０９を介した直接または間接接続など、他の相互接続方法を含むよう図示されている。公衆建物ＬＡＮ２０８と建物サブシステム２０４の建物ＬＡＮ３０を区別することが重要である。特に、公衆建物ＬＡＮ２０８は、オフィス間通信用の建物の管理者自身のローカル・エリア・ネットワークを表す。これに対して建物ＬＡＮ３０は、専ら情報配信システム１に使用する専用ローカル・エリア・ネットワークで
ある。

一般に、ＢＯＭインタフェース２００によって、建物の管理者はメッセージを建物のテナントに配信することができ、テナントは、エレベータ１２に装着されたディスプレイ・ユニット１０、および建物中に配置された他のディスプレイ２０６上でメッセージを見ることができる。ＢＯＭＧＵＩ２００を使用して作成したメッセージは、プロダクション・センタ２０からの対話がない状態で、建物サーバでマージされる。したがって、建物の管理者は、メッセージの作成を管理し、メッセージを迅速に展開して、変更することができる。

ＢＯＭインタフェース２００を使用して配信可能な多種多様なメッセージ・タイプの例は以下を含む。
・火災報知器のテスト、駐車場の閉鎖、建物時間の変更、建物固有の交通情報を含む時間が重要なメッセージ。
・休日の行事、建物の活動など、特殊な行事。
・ヘルス・クラブ、カフェテリア施設、駐車場、コーヒー・ショップ、花屋など、建物の新しい機能／サービス。
・故障したエレベータの乗員、暴風雨の警告、火災情報など、公共放送／緊急メッセージ。
・使用可能なスペースの告知、管理機構とその機能の記述など、広告メッセージ。
ＢＯＭユーザ・インタフェース（ＢＯＭＧＵＩ）
ＢＯＭＧＵＩ２００は、建物の管理者がメッセージを作成し、変更して、文字通り世界中のどこからでも、多種多様な相互接続手段のいずれかを介してディスプレイ・ユニットからディスプレイ・ユニットへと送信するための環境を提供するためのＢＯＭインタフェース２００のユーザ部分を表す。

図１３について説明すると、ＢＯＭＧＵＩ２０２はテンプレート２１２を使用して、メッセージ構造およびフォーマットを定義する。テンプレート２１２はＨＴＭＬに基づき、したがって展開のために柔軟で豊富な環境を提供する。１つの実施形態では、テンプレート２１２は６４０×４８０ピクセルのフォーマットに適合し、メッセージ情報を配置すべき場所に挿入されるコメント・フィールド＜！−メッセージ・テキスト−＞を使用する。選択されたテンプレートを埋めるメッセージ・テキストは、ＢＯＭＧＵＩ２０２を使用して入力する。プレーンなテキスト情報とともにタブ、改行復帰およびスペースを可能にするテキスト入力フィールドが提供される。

ＢＯＭＧＵＩ２０２は、既に完了したｈｔｍｌファイルをインポートすることもできる。これによって、建物の所有者および管理者は、直前に検討したテンプレート構造を使用せずに、特殊な告知を作成して、これを情報システムに表示することができる。
１．１．１メッセージ作成
メッセージ作成プロセスでは、テンプレートの各フィールドを埋める必要がある。ＢＯＭＧＵＩ２０２内で、これは２つのうち１つの方法で達成される。第１の方法は、メッセージ作成ウィザードを使用する。これは、各フィールドを埋めるにつれ、必要な入力を求めてプロンプトを出すことによって、ユーザをメッセージ作成プロセスの各ステップに連れてゆくユーザ・フレンドリなプログラムである。第２の方法は、ウィザードが以前に作成し、メッセージ作成のパターンとしてサーバに予め記憶されたメッセージ入力フォームを使用する。このフォームは、ユーザが埋めなければならない全てのメッセージ・フィールドを含み、通常は、既存のメッセージの編集に使用される。いずれの方法を使用しても、入力プロセスの結果、システムに表示できる有効メッセージになる。ＢＯＭＧＵＩ２０２は、情報をテンプレート２１２からファイルに変換し、これはシステムのディスプレイ・ユニット上で読み、表示することができる。

以下で説明するように、ＢＯＭＧＵＩ２０２は、選択されたテンプレート・ファイルをパースするパーサを含む。第１のグループのパーサは、コメント・フィールド＜！−メッセージ・テキスト−＞を検索する。このフィールドの位置を突き止めると、第２のグループのパーサがメッセージ・テキスト上で作動して、この情報をＨＴＭＬフォーマットに変換する。その結果、＜メッセージ名＞．ｈｔｍの名前が付いたＨＴＭＬ出力ファイルが生成される。このファイルは、システムに表示するために建物サーバ２８に提出される。ＢＯＭＧＵＩ２０２によって、管理者は、エレベータまたは建物の他のディスプレイで表示する前にメッセージを予め見ることもできる。このプロセスは、ＢＯＭＧＵＩ２０２が作成した各メッセージで繰り返される。
１．１．２ＢＯＭプレイ・リストの作成
ＢＯＭＧＵＩ２０２によって、建物の管理者は建物で表示する複数のメッセージを作成することができる。このメッセージは、同時に、または週／月／年を通して配信するようプログラムすることができる。

図１４について説明すると、ＢＯＭプレイ・リスト２２０は一連の建物メッセージ２２１を含みこれはそれぞれ幾つかの要素、つまり開始日、停止日、時間、メッセージ・テンプレート、およびメッセージ・テキストで構成される。開始日および停止日は、システムがいつ最初にメッセージを表示し、いつシステムから除去されるか決定する。メッセージを表示できる時間もＢＯＭＧＵＩ２０２内で選択可能である。１つの実施形態では、１日を４つのセグメントに分割する。つまりＡＭセグメント、昼食時（ＬＴ）セグメント、ＰＭセグメント、および就寝（ＳＬＰ）セグメントである。これらは１日の時間スロットを表し、システムでプログラム可能である。例えば、ＡＭセグメントは、毎日６：００ＡＭから１１：００ＡＭと定義することができる。建物の管理者は、メッセージを流す特定の時間を選択するか、メッセージを１日中流すよう選択することができる。したがって、ＢＯＭプレイ・リスト２２０は、各メッセージを表示する時刻およびその長さ（例えば、月、年）という時間を定義する。ＢＯＭプレイ・リスト２２０のフォーマットは、図５−図９に関連して上述したプロダクション・センタ２０によって作成された建物プレイ・リスト６８に似ている。しかし、ＢＯＭプレイ・リスト２１０は追加の開始および停止フィールドを含む。

ＢＯＭプレイ・リスト２２０は、ＢＯＭＧＵＩ２２０を使用して作成し、各ＨＴＭＬ出力ファイル・メッセージのステップを個別に辿り、時間および開始日および停止日を決定することによって生成される。時間は、どの時間セグメントにメッセージが表示されるか定義する。開始日および停止日は、ＢＯＭプレイ・リスト・フォーマットに直接変換される。例えば、図１４のサンプルのＢＯＭプレイ・リストは、ｂｏｍ＿ｍｅｓｓａｇｅ１．ｈｔｍを、１９９８年６月１２日から１９９８年６月１３日のＡＭセグメントのみ流すようプログラムし、ｂｏｍ＿ｍｅｓｓａｇｅ２．ｈｔｍを、１９９８年６月１２日から１９９８年６月１４日まで終日流すようプログラムすることを示す。

上述したように、ＢＯＭＧＵＩ２０２によって、建物の管理者は、文字通り世界中からディスプレイにメッセージを送信することができる。これは、今日の大部分のコンピュータで使用可能な既製のＬＡＮおよびＷＡＮテクノロジーを使用して達成される。ＢＯＭＧＵＩ２０２は接続設定メニューを含む。接続設定メニューによって、ユーザは、配信チャネル２４を通して建物のサブシステムと対話する方法を定義することができる。ユーザは、設定メニューを使用して、建物サブシステム２０４にメッセージを送信する複数の路を作成することができる。例えば、建物に居住している場合、建物の管理者は、公共建物ＬＡＮ２０８を介してメッセージを送信することができる。この同じ建物の管理者は、遠隔地からダイアルアップ・モデム２１０接続またはインターネット・サービス・プロバイダ（ＩＳＰ）２０９を介してシステムにメッセージを送信するために、ＢＯＭインタフェー
ス２００を使用する必要があることもある。いずれの場合も、建物の管理者は、ＢＯＭＧＵＩ２０２内で接続情報を定義し、それを保存して、次にメッセージを送信する度に適切な接続設定を選択するだけである。ＢＯＭＧＵＩ２０２は、自動的に接続を確立し、メッセージ情報を送信して、メッセージが提出される度に接続を使用不能にすることになる。１．２建物サブシステム
ＢＯＭインタフェース２００は、ＢＯＭプレイ・リスト・パーサを使用して、図９に関連して上述したように建物プレイ・リスト６８をパースするためにプレイ・リスト・パーサ１１０が使用するのと同様の方法で、ＢＯＭプレイ・リスト２２０をパースする。特に、プレイ・リスト・パーサは、ＢＯＭプレイ・リスト２２０を翻訳して、広告または「リアルタイム」コンテンツのローカル・リファレンスを作成する。

ＢＯＭインタフェース２００は、建物の所有者および建物の管理者がメッセージを作成して、建物のサーバ２８および建物のＬＡＮ３０を通して特定の１つまたは複数のエレベータ・ディスプレイ・ユニット１０にこれを配信できるようにも構成される。この融通性は、例えば故障したエレベータ内のエレベータ乗員に指示を提供するために特に有用である。その結果、建物の管理者は、他のエレベータにいる乗員に警告を発することなく、故障したエレベータの乗員との通信を維持することができる。

幾つかの実施形態では、ＢＯＭインタフェースは、図９に関連して上述したプロダクション・センタ／ＷＡＮインタフェース９０と協力して働く。
１．２．１プレイ・リストのパース／展開
図１５について説明すると、この場合は、建物サーバ２８のローカル建物プレイ・リスト・パース機能を、プロダクション・センタ２０とＢＯＭプレイ・リスト２２０によってアセンブルされたプレイ・リスト両方からメッセージを受信するよう変更しなければならない。

図９に関連して上述したように、ＢＯＭインタフェースがないプレイ・リスト・パーサ１１０のオペレーションは、ＵＲＬを建物データベースにマップし直すことであった。ＢＯＭインタフェースが追加されると、プレイ・リスト・パーサ２２２は、今度は再マップとインタリーブ・オペレーションとの両方を実行しなければならない。

図１６について説明すると、プレイ・リスト・パーサ２２２は、プロダクション・センタ（ＰＣ）建物プレイ・リスト６８またはＢＯＭプレイ・リスト（２３２）を更新することによって開始される（２３０）。いずれもプレイ・リストも更新されていない場合、パーサ２２２は所定の時間だけ待ち、次にプレイ・リストの更新状態に変化があるか判断するようポーリングする。これに対して、いずれかのプレイ・リストが更新されている場合、パーサ２２２はＰＣプレイ・リスト６８が更新されたか照会する（２３４）。ＰＣ建物プレイ・リスト６８は、ローカル建物プレイ・リスト１１４のベースライン・バージョンを表す。つまり、ローカル建物プレイ・リスト１１４は、ＰＣ建物プレイ・リスト６８から作成された開始点から導かれる。建物ＰＣプレイ・リストが更新されている場合、パーサ２２２は、図９に関して上述したＵＲＬ再マップを実行する（２３６）。ＵＲＬＮ再マップの後、パーサ２２２は第２のパスを実行して、ＢＯＭプレイ・リスト２２０からの情報を、更新したＰＣ建物プレイ・リスト６８にインタリーブする（２３８）。

他の用途では、ＢＯＭインタフェース２００は、プロダクション・センタと対話することなくテナントと通信する手段として、建物の管理者が別個に使用する。この用途では、ＢＯＭプレイ・リストをインタリーブするＰＣプレイ・リストはない。したがって、図１６について説明すると、プレイ・リスト２２２は単に、ＢＯＭプレイ・リストが更新されているか判断し（２３２）、ＢＯＭプレイ・リスト２２０のみからローカル建物プレイ・リスト１１４を導く。

インタリーブ機能の目的は、ラウンドロビン優先順位スキームを使用して、指定された期間中に毎分、プログラムされた数の建物管理プログラム・メッセージを挿入する。１分当たり挿入されるメッセージの数は、０から使用可能な全スロットまでプログラムすることができる。言うまでもなく、メッセージを挿入する前に、パーサ２２２は現在の日付および時刻がメッセージの開始／停止日および期間パラメータに入ることを検証する。

例を挙げると、パーサ２２２が機能する方法を示すのに役立つ。建物の管理者がＢＯＭＧＵＩ（２０２）を介して図１４に示すＢＯＭプレイ・リストを作成し、ダウンロードしたものとする。現在の日付が１９９８年６月１２日で、１分当たりのスロットが１に設定されている場合、パラメータは図１７に示すローカル建物プレイ・リスト１１４を作成する。

ＡＭセグメントの間、ｂｏｍ＿ｍｅｓｓａｇｅ１．ｈｔｍとｂｏｍ＿ｍｅｓｓａｇｅ２．ｈｔｍが両方ともＰＣ建物プレイ・リスト６８にインタリーブされることに留意されたい。これらのメッセージは、ＡＴ時間セグメント内で「ラウンドロビン」方式で交互になる。ＬＴ、ＰＭおよびＳＬＰ期間の間は、ｂｏｍ＿ｍｅｓｓａｇｅ２．ｈｔｍのみが表示される。これらの時間セグメントでは、このメッセージが毎分表示される。
１．２．２メッセージの記憶／送信
図１０に関連して上述したコンテンツ・アセンブリのプロダクション・センタとは異なり、ＢＯＭＧＵＩ２０２が作成したページは、建物サブシステムで変更する必要がない。しかし、ページの広告コンポーネントは、建物内の自動アセンブリに従う。

図１８について説明すると、ＢＯＭＧＵＩ２０２はメッセージ・ファイルをＢＯＭメッセージ記憶装置２４０に預ける。ディスプレイ・アセンブラ１２２は、ローカル建物プレイ・リスト１１４を解釈するにつれ、ＢＯＭメッセージ記憶装置２４０で全建物メッセージを探す。メッセージに関連する広告はプレイ・リストによって定義され、ディスプレイ・サーバ１２４に渡される前にディスプレイ・アセンブラ１２２によって挿入される。

建物サブシステム２０４がプロダクション・センタ２０とインタフェースをとる実施形態では、通常はダイアルアップ・モデル接続を使用して接続を確立する。ＢＯＭインタフェース２００の機能を追加するために、システム１には専用建物ＬＡＮ３０との対話を可能にするネットワーク・カードを装備する必要があることもある。ＢＯＭインタフェースの物理的相互接続が、ダイアルアップ・モデム２１０またはＩＳＰ２０９を介して実行される場合は、単一のモデム・インタフェースで十分である。これは、ＢＯＭＧＵＩ２０２上で実行されるソフトウェアおよび再試行を実行してデータの多重化を可能にするプロダクション・センタ２０を介して達成される。その結果、ハードウェアのインプリメンテーションが最小に抑えられる。
１．３ＢＯＭインタフェースのセキュリティ
ＢＯＭインタフェース２００は、情報システム１への直接パスを表す。したがって、このインタフェースのセキュリティは、不適切な使用または無許可の使用を確実に不可能にするために重要である。システムのセキュリティ手順は３つのレベルで実行される。つまりＢＯＭＧＵＩパスワードの保護、確実な接続、および建物サブシステムにおけるパスワード／アクセス保護である。ＢＯＭＧＵＩ２０２は、ユーザ・インタフェースを呼び出す前にユーザ名およびパスワードのチェック手順を実行する。パスワードおよびユーザ名が暗号化され、保護されたファイルに記憶される。ルート特権を有する個人のみが、この情報を操作することができる。物理的相互接続レベルでは、パス名およびダイアルアップ・プロパティを暗号化し、これは許可された人のみがアクセス可能である。最後に、建物サブシステム２０４が２層の保護を提供する。第１に、システムへのメッセージ要求毎にユーザ名およびパスワードの検証を実行する。これによって、システム１のセキュリティ・
モニタが、ライセンスを有する全ユーザに気づくことが確実にされる。第２に、ＢＯＭメッセージ情報が建物サーバ２８の別個の区画に維持される。これによって、システムの無許可のユーザがシステムに関連していない他の機能へのアクセスから確実に除外される。この３段階のアプローチによって、システムへの無許可のアクセスが発生することが非常に困難になる。

図１３〜１８に関連して上述した実施形態では、ＢＯＭインタフェース２００によって建物の所有者および管理者が、メッセージを作成し、建物中のエレベータ（または他のディスプレイ）に装着したディスプレイ・ユニット１０にこれを送信することができた。特に、ＢＯＧＵＩ２０２は、所有者および管理者が文字通り世界中のどこでもメッセージを作成し、変更して、ディスプレイ・ユニットに送信できるためのインタフェースのユーザ部分を表した。

図２５について説明すると、本明細書では「スクリーン・センタ・インタフェース」と呼ぶＢＯＭインタフェース６００の他の実施形態では、任意の数の異なる市販の標準的デスクトップ・パブリッシング・ツール（例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）のＰｏｗｅｒＰｏｉｎｔ、Ａｄｏｂｅ（登録商標）のＰｈｏｔｏｓｈｏｐ）を使用して、スクリーン・センタのユーザ６０２がメッセージを作成することができる。特に、システムの高度にスケーラブルで柔軟性がある性質をサポートするために、スクリーン・センタ・インタフェースはプリンタ・ドライバ６０４を含み、これはデスクトップ・パブリッシング・ツール６０５を使用して作成したデスクトップ・イメージを、情報配信システム１と合致するファイル・フォーマットに翻訳する。これで、プリンタ・ドライバ６０４は、セキュリティ保護されたソケット層（ＳＳＬ）パス６０８を介してウェブを遠隔ウェブ・サーバ６０６に接続させる。ウェブ・ブラウザ６１０によって、ユーザはメッセージをスケジューリングし、メッセージが表示される建物を決定することができる。いずれの場合も、所与のユーザが使用可能な建物はユーザＩＤおよびパスワード保護によって厳密に制御される。メッセージがスケジューリングされたら、ウェブ・サーバ６０６はメッセージの標的となる建物毎に、ＦＴＰサーバ６１２のＦＴＰサイト・ディレクトリにメッセージを入れ、スクリーン・センタ・プレイ・リストを再作成する。次の検索サイクル中、建物はスクリーン・センタ・プレイ・リストおよびメッセージを収集し、これをローカル・プレイ・リストに構築する。

このアーキテクチャの重要な要素は、システムが所与の建物について複数のメッセージ・ソースを有することができることである。プロダクトはウェブ・ベースであるので、複数の資産の所有者は、地元の建物の管理者、地方の管理者またはマーケティング・グループにそれぞれ、建物内のメッセージング機能にアクセスを許可することができる。ユーザＩＤおよびパスワード保護は、個人ベースのアクセスを制限し、グループによって使用可能なメッセージ・インベントリの共有量を増減させることができる。建物のインテリジェント・サーバは、複数のメッセージ・ソースのインタリーブ、おおびインベントリへの適切なアクセスの提供を扱う。
＜包括的プレイ・リストおよびコンテンツの選択＞
上述した本発明の実施形態では、ローカル建物プレイ・リストが、建物のプログラミングの各スロットで使用するコンテンツを指定する。コンテンツは、既知のソースから建物サーバのセントラル・ロケーションへと検索される。このコンテンツ情報は、ローカル建物プレイ・リストに基づいてエレベータ・ディスプレイに提供される。本発明の方法およびシステムの他の実施形態を使用して、建物の所有者に対して、コンテンツの選択および建物で表示される情報の混合における融通性を向上させることができる。このアプローチでは、情報は依然としてコンテンツのマッピングにより既知のソースから検索される。しかし、検索されたファイルを、例えば建物サーバなどの建物のプロセッサに配信する場合、仮想階層が追加される。この階層の理由は２つある。最初に、情報はカテゴリごとに管
理され、１つのカテゴリのコンテンツ・マッピング・ファイルにあるソース・ディレクトリに、複数の情報ソースがあることもある。その結果、建物サーバは、コンテンツ・マッピング・ファイルのソース・ディレクトリからの複数のソースを１つのカテゴリに圧縮し、特定の建物のローカル・プレイ・リストを作成する。第２に、建物サーバは、特定のカテゴリに関するコンテンツ・マッピング・ファイルのソース・ディレクトリから、循環する反復シリーズ（本明細書ではラウンドロビンと呼ぶ）情報をリストに挿入することによって、ローカル・プレイ・リストを作成する。

この実施形態は、高層建物のエレベータとの通信というダイナミクスに対応するため、別のプロトコル層を提供する。
図１９について説明すると、建物サブシステム３１４のエレベータ・ディスプレイ・ユニット３１０にビデオ情報を配信する媒体出口を提供する情報配信システム３０１が図示されている。上述したように、送信されるビデオ情報は、一般情報、商業情報および建物関連の情報を任意に組み合わせたものを含むことができる。システム３０１は、建物３１４ごとに包括的プレイ・リスト３２１を作成するネットワーク・オペレーション・センタ（ＮＯＣ）３２５を有するプロダクション・センタ３２０を含む。

包括的プレイ・リスト３２１は、全国ニュース、地元のスポーツ、行事、天候、交通など、エレベータ・ディスプレイ・ユニット３１０で表示されるビデオ情報３２３のカテゴリを定義する。包括的プレイ・リスト３２１は、表示される情報のカテゴリまたはタイプを定義するが、そのカテゴリにある情報のコンテンツ・ソース３２２が、配信チャネル（本明細書ではインターネット３２４）を介して検索されることを指定していない。建物のプロセッサ、つまりこの実施形態では建物サーバ３２８が、コンテンツ・マッピング・ファイル３２９を使用して、包括的プレイ・リスト３２１の情報のカテゴリによって指定された情報３２２の実際のソースを定義する。コンテンツ・マッピング・ファイルにアクセスする建物のプロセッサは、建物サーバに制限されず、例えばエレベータまたは電子ディスプレイ・ユニット３１０内の十分に強力なコンピュータ・システムを含んでもよい。これで、建物の所有者は、プロセッサがローカル建物コンテンツ・プレイ・リスト３６８を作成して、例えば建物のＬＡＮ３３０などを介してエレベータ・ディスプレイ・ユニット３１０に配信できるよう、建物所有者管理（ＢＯＭ）プレイ・リスト３３１から任意選択で建物の情報を追加することができる。
＜包括的プレイ・リスト＞
包括的プレイ・リスト３２１は、建物のエレベータに表示される情報の密度を定義し、ローカル建物プレイ・リスト３６８を展開するために使用するスクリプトを提供する。上述したように、包括的プレイ・リスト３２１の要素は情報のカテゴリである。これらのカテゴリは、最終的にローカル・プレイ・リスト３６８の各要素を満たすことになる情報のタイプを定義する。上述した本発明の実施形態のコンテンツ・プレイ・リストとは異なり、包括的プレイ・リスト３２１は、情報のソースを指定するファイルに特定のポインタを提供せず、情報のカテゴリのみを含む。したがって、エレベータの乗員が、包括的プレイ・リストのスロットと同じ名前を有するスクリーンを見ることはない。包括的プレイ・リストの例を、以下の表ＩＶに示す。
AMS,world_news
AMS,national_news
AMS,local_news
AMS,weather
AMS,national_sports
AMS,local_sports
AMS,local_restaurant

LTS,national_business LTS,traffic
LTS,weather
LTS,local_business

PMS,local_news
PMS,local_events
PMS,local_places
PMS,traffic
PMS,weather

SLP,world_news
SLP,national_news
SLP,national_sports
表ＩＶ
上記の図６で示したコンテンツ・プレイ・リストと同様に、包括的プレイ・リスト３２１のフォーマットは１日の諸部分、つまり情報（ｌｏｃａｌ＿ｎｅｗｓ、ｎａｔｉｏｎａｌ＿ｎｅｗｓ、ｔｒａｆｆｉｃ、ｗｅａｔｈｅｒなど）のカテゴリを有するセグメント（ＡＭＳ、ＬＴＳ、ＰＭＳ、ＳＬＰ）と合致し、プログラミング・マネージャがネットワーク・スケジュールを開発するのに最大の融通性を提供する。表ＩＶで記述した包括的プレイ・リスト・フォーマットは、プログラミング・マネージャが特定の視聴者を標的とする包括的プレイ・リスト３２３を開発することも可能にする。例えば、金融業界の建物を標的とする包括的プレイ・リストは、主に医療または法律業界を主な母集団とする建物を標的とする包括的プレイ・リストより、金融およびマーケット情報の密度を高くすることができる。包括的プレイ・リスト・フォーマットの利点は、標的とするプレイ・リストを複数の市場に適用できることである。これは、コンテンツ・マッピング・ファイル３２９を使用して特定の市場または建物に包括的プレイ・リスト３２３の標的を絞ることによって達成される。
＜コンテンツ・マッピング・ファイル＞
コンテンツ・マッピング・ファイル３２９は、包括的プレイ・リスト３２１で指定された情報３２２のソースを定義する。コンテンツ・マッピング・ファイル３２９によって、建物の所有者／管理者は、包括的プレイ・リスト３２１の情報カテゴリ内で特定の情報３２２のソースを選択し、個々の建物内で独特の視聴環境を生成することができる。例えば、コンテンツ・マップによって、建物Ａは包括的プレイ・リストの世界ニュース・カテゴリの世界ニュースのソースとしてＣＮＮを選択することができ、建物Ｂは、そのカテゴリ内の世界ニュースのソースとしてロイターを選択し、建物Ｃは、世界ニュースのソースとしてＣＮＮ、ニューヨーク・タイムズ、およびロイターを選択することができる。このアプローチによって、建物の所有者／管理者には最大限の融通性が得られる一方、プロダクション・センタ３２０で必要が追加のオーバヘッドは非常に少なくなる。

コンテンツ・マッピング・ファイルのフォーマットの一例を、以下の表Ｖに示す。
<category>,<information path>,<refresh cycle>
world_news,ftp::/cnn.com/captivatenetwork/news,4320
world_news,ftp::/reuters.com/captivatenetwork/worldnews,4320
weather,ftp::/captivatenetwork.com/weather/boston,40
national_news,http::/boston.com/captivatenetwork/news,1440
表Ｖ
表Ｖに示すコンテンツ・マッピング・ファイル３２９の第１の要素、つまり＜ｃａｔｅｇｏｒｙ＞は、マッピングされる包括的プレイ・リストのカテゴリを識別する。上記の例では、１行目は世界ニュース・カテゴリへの１つのマッピング、つまりｗｏｒｌｄ＿ｎｅｗｓを示す。しかし、どのカテゴリも１つのマッピングに制限されるものではなく、複数のマッピングを含むことができる。第２の要素、つまり＜ｉｎｆｏｒｍａｔｉｏｎｐａ
ｔｈ＞は情報パスを識別し、これはコンテンツ・マッピング・ファイル３２９が実行するマッピングである。下記のコンテンツ検索プロセスの間、建物サーバ３２８は情報パス指定を使用して、ＦＴＰまたはＨＴＴＰ要求を提出し、指定されたカテゴリのデータ・ソースの実際のファイルを検索する。コンテンツ・マッピング・ファイル３２９の最後の要素、つまり＜ｒｅｆｒｅｓｈｃｙｃｌｅ＞は、日付の情報を特定のファイルまたはカテゴリに割り当てることを示す。例えば、旧データ・タイム指定は、サーバが古いとマークされないようカテゴリ内のデータをリフレッシュすべき頻度を分単位で定義する。

表Ｖの例では、コンテンツ・マッピング・ファイル３２９はファイルとして図示されているが、コンテンツ・マッピング・ファイルは実際には全くファイルでなくてよい。ＷｉｎｄｏｗｓＮＴベースのサーバを使用する場合、コンテンツ・マッピング・ファイルは実際には建物サーバのサービスが操作する一連のレジストリ・キーでよい。コンテンツ・マッピング・ファイルは、テキストまたはコンフィギュレーション・ファイルの情報も含むことができる。

また、コンテンツ・マッピング・ファイルの概念を、任意選択で包括的プレイ・リストに含めてもよい。この場合のサンプルのファイル・フォーマットは以下の通りである。
セグメント、カテゴリ、情報パス、リフレッシュ・サイクル
しかし、これらのデータを分離すると、コンテンツの開発プロセスの融通性が向上し、単純になる。

この用途では、コンテンツ・マッピング・ファイル３２９は上述したフォーマットを有するファイルと仮定される。
＜コンテンツの検索＞
コンテンツ・マッピング・ファイル３２９とともに、建物サーバ３２８は、ローカル・プレイ・リスト３６８を構築するために必要なファイルを検索するのに必要な情報を有する。プロダクション・センタ３２０から送信された包括的プレイ・リスト３２１は、特定のファイル参照ソース情報も、その位置も定義していない。代わりに包括的プレイ・リスト３２１のスロットは情報のカテゴリのみを定義する。建物サーバ３２８は、コンテンツ・マッピング・ファイル３２９のソース・ディレクトリ３２７から、そのカテゴリのソース・ディレクトリ３２７で使用可能な全ファイルの連続的な反復シリーズ（ラウンド・ロビン）ピックに基づき、そのスロットのどのファイルをプレイするか選択する。

ラウンド・ロビン選択は、図２０に示したコンテンツ検索プロセス４００の間に構築され、保守されたカテゴリ・ファイル・リストに基づく。このコンテンツ検索プロセスは、３つの基本的ステップを含む。つまりディレクトリの列挙、認定、および検索である。

ディレクトリ列挙ステップ４００では、建物サーバ３２８（図１９参照）がコンテンツ・マッピング・ファイル３２９のソース・ディレクトリ３２７にどのファイルがあり、識別されたファイルが最後に変更されたのはいつか識別する。建物サーバ３２８は、コンテンツ・マッピング・ファイル３２９で指定されたパス情報を使用して、各ソース・ディレクトリ３２７のコンテンツをサンプリングする。ソース・ディレクトリにある各ファイルのファイル名および変更日を抽出し、認定ステップ４０４に供給する。

認定ステップ４０４では、建物サーバ３２８は、列挙ステップ４０２で識別されたファイルが検索の候補になるか否か判断する。検索の認定には、識別されたファイルが、（１）ローカル建物サーバ３２８に現在存在しない、または（２）識別されたファイルがローカル建物サーバ３２８に存在する場合、識別されたファイルが、ソース・ディレクトリ３２７にあるファイルより前の変更日を有する、ということが必要である。

認定ステップ４０４の別の重要な態様は、ローカル・プレイ・リストを予め作成する必要があるか否かを判断することである。認定プロセスによって、検索中のファイルが新しいと判断された場合は、ローカル・プレイ・リストを再作成しなければならない。既存のファイルの更新には、ローカル・プレイ・リストを再作成する必要がない。

ファイルに検索の資格がある場合は、以下で詳細に説明するファイル検索ステップ４０６でファイルが検索され、ダウンロードされる。
＜ファイルのダウンロード、ファイルの確認、およびリストの更新＞
コンテンツ検索プロセス４０６は、ファイル・ダウンロード・ステップ４０８、ファイル確認ステップ４１０、およびリスト更新サイクル４１２を含む。ダウンロード・ステップ４０８は、情報ファイルをローカル建物サーバ３２８（図１９参照）へ運ぶ。ファイル確認ステップ４１０は、建物サーバ３２８に運ばれたデータの保全性を確実にする。カテゴリ・ファイル・リスト更新プロセス４１２は、カテゴリ・ファイル・リスト４１３を操作して、ダウンロードされたデータに関連する変更を反映する。
＜ファイルのダウンロード＞
コンテンツ・マッピング・ファイル３２９によって指定された転送プロトコルに応じて、ファイルのダウンロードは、ＦＴＰ取出しまたはＨＴＴＰ取得オペレーションで実行される。ファイルは、建物サーバ３２８の情報ファイル記憶エリア４１４にあるＴＥＭＰディレクトリにダウンロードされる。転送が完了すると、ファイル確認プロセス４１０を実行することができる。
＜ファイルの確認および抽出＞
ファイル・ダウンロード・ステップ４０８中に転送された各ファイルは、プロトコル・ヘッダ内でカプセル化される。プロトコル・ヘッダは、プログラミングの融通性を向上するよう設計された複数の機能レベルを有する通信メカニズムである。プロトコル・ヘッダは、例えば、データの保全性を確保し、ネットワークのセキュリティを提供して、サーバでファイルを起動または停止するよう設計することができる。ファイル・ヘッダ・フォーマットの例を、以下の表ＶＩに示す。

セキュリティＩＤ
ファイル数
ファイル・リスト
検査合計
表ＶＩ
表ＶＩのプロトコル・ヘッダのセキュリティ識別（ＩＤ）は、ファイル転送のあるレベルのネットワーク・セキュリティを提供する。図２１について説明すると、ステップ４２０の開始の後、認定サイクル４１０の第１のステップ４２２は、セキュリティＩＤを確認することである。セキュリティＩＤは、ファイル・サイズ、検査合計、およびキー値で専用ＯＦ（ＸＯＲ）機能を実行することによって計算される。キー値は、建物サーバ３２９のレジストリ・キーによって定義され、表ＶＩのプロトコル・ヘッダを開発するプログラムと共通である。所与のファイルのセキュリティＩＤを確認する能力がないことは、潜在的に重大なセキュリティ危機である。

セキュリティＩＤを認定できない場合、建物サーバ３２９は、ステップ４２４でロギングを通してレベル１のエラー・メッセージをネットワーク・オペレーション・センタ（ＮＯＣ）３２５（図１９参照）に返し、即座に調査してもらう。次のレベルの認定は、検査合計を使用してステップ４２６で実行する。表６のプロトコル・ヘッダを開発するプログラムが検査合計を計算する。建物サーバ３２９は、受信したファイルに基づいて自身の検査合計を計算し、２つの値が一致するか確認する。一致しない場合、建物サーバは検索プロセスを終了し、ステップ４２８でロギングを通してレベル２のエラー・メッセージをＮＯＣ３２５に返し、調査してもらう。

ファイルが認定されたら、ファイル情報を抽出し（ステップ４３０）、建物サーバ３２９のＦＲＡＭＥＳディレクトリに入れる（ステップ４３２）。全ファイルが抽出されたら（ステップ４３４）、認定サイクルが終了する（ステップ４３６）。

表６のプロトコル・ヘッダにより、プロトコル内に複数のファイルを入れることもできる。この構成は、建物サーバ３２９が複数の情報ソースを捕捉し、包括的プレイ・リスト３２１（図１９参照）からローカル・プレイ・リスト３６８を開発できることにより、多大な融通性を提供する。残念ながら、複数の検索ファイルの配置はランダムであるので、１つのファイルが必ず別のファイルの次にあるわけではない。多ファイル・プロトコルによって、検索したファイルをプレイ・リスト内で相互に並べることができる。プロトコルは以下の表ＶＩＩに示すように作動する。
検索したファイルの数が１より大きい場合
各ファイルを個々に抽出して、それにバンドルとマークを付ける
上記以外の場合
検索したファイルの数が１と等しい場合
ファイルを抽出して、それに単一項目とマークを付ける
終了
表ＶＩＩ
上述したプロトコル・ヘッダでは例示されなかったが、プロトコル・ヘッダは、各ファイルの起動および停止時刻を含むよう拡張することができる。ファイルがサーバに送信されると、ヘッダの起動／停止要素によって、建物のプロセッサは、同じ情報カテゴリのファイルが異なる時刻に実行されるよう、各ファイルの開始および終了時刻を制御することができる。このような建物プロセッサの役割の拡張は、ネットワーク・オペレーション・センタ３２５でのファイル管理に大きい融通性を提供し、それを単純化する。
＜カテゴリ・ファイル・リストの更新＞
ステップ４１０のソース・チェックの後、カテゴリ・ファイル・リスト４１３はステップ４１２で更新される。カテゴリ・ファイル・リスト４１３は、各コンテンツ・カテゴリを構成するファイルへのポインタを有する。建物サーバ３２９のディレクトリ構造をさらに分割して別個のコンテンツ・カテゴリにする代わりに、ファイル構造をフラットに維持し、リストを使用してデータを管理する方がはるかに効率的で有用である。カテゴリ・ファイル・リストの構造を以下の表ＶＩＩＩに示す。

カテゴリ
ファイル
変更日
ファイル存在フラグ
バンドル・フラグ
旧フラグ
表ＶＩＩＩ
表ＶＩＩＩの構造では、カテゴリはコンテンツ・マッピング・ファイル３２９（図２０および表Ｖ参照）のカテゴリ要素にマッピングされる。ファイル・フィールドは、ソース・ディレクトリから抽出したファイル名を現す。最終変更日および旧フラグは、以下で説明する旧データ回復アルゴリズムにとって重要である。ファイル存在フラグは、最後のコンテンツ検索サイクルの間、ファイルがまだソース・ディレクトリに存在したか否かを示す。これは検査プロセスにとって重要である。最後に、バンドル・フラグは、ファイルをローカル・プレイ・リスト内に強制的に連続して配置するために使用する。バンドル・フラグは、実際には、表ＩＸに示す以下の可能な状態を有する英数字値である。

オフ−ファイルはバンドルの一部ではない
開始−これはバンドルの最初のファイルである
要素−これはバンドルの中間ファイルの１つである
終了−これはバンドルの最後のファイルである
表ＩＸ
上述したプロトコル・ヘッダと同様、カテゴリ・ファイル・リストの定義も、ファイルの実行時間制御を完全に、または部分的にネットワーク・オペレーション・センタから建物プロセッサへ転送ファイル起動または停止時刻を含むよう拡張することができる。これはプログラミングの融通性を向上させる。

カテゴリ・ファイル・リスト４１３を更新するプロセス４１２（図２０参照）は、カテゴリの作成、ファイルの挿入、およびファイル保守ステップで構成される。
＜カテゴリの作成および除去＞
カテゴリ・ファイル・リストは、コンテンツ・マッピング・ファイル３２９で定義されたカテゴリ毎に存在しなければならない。したがって、図２２について説明すると、更新プロセス４１２の第１の要素４４０は、カテゴリの作成および除去手順である。カテゴリの作成および除去手順４４０の間、建物サーバ３２８はコンテンツ・マッピング・ファイル３２９に応答指令信号を送り、存在していないカテゴリ・ファイル・リスト４１３があれば追加し、存在するがコンテンツ・マッピング・ファイル３２９で定義されていないカテゴリ・ファイル・リスト４１３があれば削除する。
＜ファイルの挿入＞
検索プロセス４０６は、各ソース・ディレクトリを列挙し、ファイルを確認するにつれ、建物サーバ３２８に存在しないファイルがあれば、これを検索して認定し、次にカテゴリ・ファイル・リスト４１３に入れなければならない。検索および認定プロセスは、２つの要素が（１）サーバ３２８のＦＲＡＭＥＳディレクトリに存在し、（２）カテゴリ・ファイル・リスト４１３内にあるか考慮する。ファイルがサーバ３２８のＦＲＡＭＥＳディレクトリに存在する場合、これは検索されない。しかし、ファイルがカテゴリ・ファイル・リスト４１３にない場合は、これを挿入しなければならない。特に、ファイルがサーバ３２８のＦＲＡＭＥＳディレクトリにない場合は、ファイルが検索、認定され、次にステップ４４２でカテゴリ・ファイル・リストに挿入される。カテゴリ・ファイル・リストはリング・バッファであり、したがって新しいファイルはリストの最後に追加される。次に、建物サーバは変更日を捕捉し、存在フラグを設定して、適切にバンドル・フラグのマークを付ける。
＜ファイルの保守＞
検索および確認ステップ４０６、４１０の間、ファイルが変更されているか、変化がないか判断されたら、カテゴリ・ファイル・リスト保守事象４４４を実行しなければならない。保守活動４４４は、カテゴリ・ファイル・リストの要素、つまり変更日、旧フラグ、およびファイル存在フラグを考慮する。これらのフラグは、以下で説明する４５０のクリーンアップおよび回復機能で使用する。ファイルが変更される度に、建物サーバ３２８は変更日を更新し、旧フラグをクリアして、ファイル存在フラグにマークを付けて、ファイルがまだ有効であることを提示しなければならない。変化がないファイルの場合、建物サーバ３２８は単にファイルが存在するというマークを付ける。
＜クリーンアップおよび回復＞
クリーンアップおよび回復は、コンテンツ管理プロセスの重要な要素である。再び図２０について説明すると、クリーンアップおよび回復プロセス４５０は、プレイ・リスト内でもはや活動していないファイルが建物サーバ３２８のＦＲＡＭＥＳディレクトリから確実に除去される。これによって、ＦＲＡＭＥＳディレクトリが何週間または何ヶ月も操作する間に制御不能になることを防止する。

プロセス４５０のクリーンアップ部分は、各カテゴリ・ファイル・リストの全ファイルのファイル存在フラグを検査する必要がある。ファイルが設定されていない場合、ファイ
ルはＦＲＡＭＥＳディレクトリおよびカテゴリ・ファイル・リストから削除され、ステップ４５２でローカル・プレイ・リストが再構築される。ファイル存在フラグが設定されている場合は、次のコンテンツ検索サイクルの準備としてフラグが除去される。

ステップ４５０の回復部分は、旧データの管理に使用される。情報の各カテゴリはリフレッシュ・サイクル（上記の表５参照）を有する。旧データは、ファイルの変更日がそのカテゴリのリフレッシュ速度を超えた時に発生する。コンテンツ検索およびクリーンアップ・ステップ４０６、４１０の後、カテゴリ・ファイル・リストの各ファイルで回復を実行する。ファイルが旧式であると判明したら、建物サーバ３２８は所与のファイルの旧フラグを設定し、ステップ４５２でローカル・プレイ・リストを再構築する。旧フラグは、ローカル・プレイ・リストの開発プロセス中に再検討され、ファイルがローカル・プレイ・リストに含まれているか判断する。建物サーバ３２８は、ロギングを通してレベル２のエラーを生成し、ＮＯＣに状況警告することもできる（図２０には図示せず）。ファイルが更新され、カテゴリのリフレッシュ要件を満たしたら、再びローカル・プレイ・リストに入れることができる。この旧データ回復アルゴリズムの力は、それによってローカル・プレイ・リストは、建物サーバ３２８がインターネットとの通信を喪失した場合に自己治癒できることを確保する。

クリーンアップおよび回復ステップ４５０が終了したら、コンテンツ検索プロセスはステップ４５２で終了する。
＜ローカル・プレイ・リストの開発＞
図２３について説明すると、ローカル・プレイ・リストの開発５００は、包括的プレイ・リストを建物固有のローカル・プレイ・リストに入れるプロセスである。カテゴリ・ファイル・リストを包括的プレイ・リストと融合させ、次に建物プレイ・リストからのスクリーン・センタ・メッセージを組み込むと、変形が実行される。

ローカル・プレイ・リスト３６８の開発を開始することができる幾つかの誘因事象５０２がある。例えば、コンテンツ・ファイルの追加、スクリーン・センタ・メッセージの新しい建物プレイ・リスト、新しい包括的プレイ・リスト、コンテンツ・ファイルの除去、および旧ファイルの除去である。ローカル・プレイ・リストの開発プロセス５００が引き起こされると、これは２段階のオペレーションを実行する。第１に、包括的プレイ・リストが、コンテンツ・スロット割り当てプロセス５０４を介してコンテンツ・プレイ・リストに変換される。次に、スクリーン・センタ割り当て機能５０６によってコンテンツ・プレイ・リストをローカル・プレイ・リストに変形する。
＜コンテンツ・スロットの割り当て＞
コンテンツ・スロットは、包括的プレイ・リスト３２１を１日２４時間全部に適合するよう拡張し、次にラウンドロビン方式でカテゴリ毎にコンテンツを配置することにより、ステップ５０４で割り当てられる。図２４について説明すると、これは２つのパスで実行され、コンテンツ・プレイ・リストの第１のパスを作成する。第１に、包括的プレイ・リスト３２１をステップ５０５で拡張する。この拡張は、カテゴリ・ファイル・リスト４１３内のカテゴリ割り当てを回転し、ＡＭセグメント、ＬＴセグメント、およびＰＭセグメントを有する分割された２４時間の期間にする。第２に、包括的プレイ・リスト３２１内のカテゴリの定義を、ステップ５０７でセグメント毎に単純に繰り返し、コンテンツ・プレイ・リスト内の各１０秒時間スロットを満たす。包括的プレイ・リストが１日に拡張されたら、コンテンツ・プレイ・リスト５１０の第１のパスは完成し、コンテンツ・ファイルの挿入プロセスを実行することができる。

包括的コンテンツ割り当てを実際のコンテンツ・ファイル名で置換するには、カテゴリ・ファイル・リスト４１３を使用する。ファイル・プロセス・ステップは、以下の表Ｘに示したアルゴリズムを使用してラウンドロビン方式で実行される。

Start at time 00:00:00 in content play list
Step 1: Locate category file list for category specified in content play list
IF category file list is empty
Remove slot in content play list
Else
IF stale flag not set for current file in category file list
Replace category name in content play list
If bundle flag = start
Continue to add the files from category file list to the content play list until the bundle flag =end is found
Endif
Else
Find the next file entry in the list that is not marked as stale and
insert this file name into content play list. If all files are marked stale in the category, then remove the category from content play list.
Endif
Endif
If not end of content play list
Goto to next entry in content play list and repeat step 1
Endif
表Ｘ
起動および停止時刻を使用する場合は、上記の表Ｘのアルゴリズムを変更して、現在の時刻がカテゴリ・ファイル・リストの候補リストの起動および停止時刻に入っているか検証するため、各ファイルでのテストを含める。

表Ｘに記載したアルゴリズムは、コンテンツ・プレイ・リスト５１０を作成する。このプレイ・リストは、次にステップ５０６でスクリーン・センタ・スロット割り当てにより変更されて、建物の所有者・管理者（ＢＯＭ）のプレイ・リスト５１２メッセージを含み、ローカル建物プレイ・リスト３６８を生成する。ローカル建物プレイ・リストを使用して、ステップ５１４にてビデオ情報が建物サーバによって建物ＬＡＮ３３０を介してエレベータ・ディスプレイ・ユニット３１０に配信される。

さらに他の実施形態が特許請求の範囲に包含される。

Claims

建物内に位置するエレベータ内のディスプレイ・モニタにビデオ情報を提供する方法であって、
ビデオ情報のカテゴリを定義する第１のデータを受信するステップと、
前記ビデオ情報のカテゴリに関連し、前記ビデオ情報の少なくとも１つのソースを定義する第２のデータを受信するステップと、
データ通信路上で、前記第１のデータおよび前記第２のデータに基づき、前記エレベータ内の前記モニタに表示する前記ビデオ情報を前記ソースから検索するステップとを含む方法。