CA 02458358 2004-03-15
INFORMATION DISTRIBUTION SYSTEM FOR USE IN AN ELEVATOR
BACKGROUND OF THE INVENTION
This invention relates to providing informa.tion in an elevator and other such
personnel transport veliicles.
The impetus for constructing skyscrapers and other high-rise structures lies
in providing a more efficient use of real estate, particularly in urban areas
where the
value of real estate is at a premium. The primary mode of transportation in
such
stractures is the elevator, particularly in buildings having many floors.
Visual information provided in an elevator is generally limited to floor
information and passenger instruotions in the event of emergency or if
assistance is
required. An elevator may also include a static placard posting the day's
present and
their locations.
SU1ViMARY OF THE INVENTION
This invention features a system for displaying video information to
passengers of an elevator in accordance with a play list defining a sequence
of
messages. The video information messages can include combinations of digital
advertising, "real-time" general information, as well as, building-related
information.
In one aspect of the invention, the system includes an elevator display uait
having a display monitor for displaying video information to the passengers,
and a local
server which, receives scheduling information associated with the video
information
over a data communication path and, in accordance with the scheduling
information,
generates a play list used to display at the elevator display unit.
In another aspect of the invention, a method of providing general
information and commercial information within an elevator includes the steps
of: a)
providing to a local server, scheduling information associated with video
information to
be displayed; b) generating, from the scheduling information, a play list
associated with
-1-
~
CA 0245835812008-01-22
60412-3044D
the video information; and c) generating a display for
viewing at the elevator display unit within the elevator,
the video information at predetermined times in accordance
with the scheduling information.
In yet another aspect, the invention is a method
of providing video information to a display monitor within
an elevator located in a building. The method includes
receiving first data defining a category of video
information, receiving second data, associated with the
category of video information and defining at least one
source of the video information; and retrieving from the
source, over a data communications path and on the basis of
the first data and the second data, the video information to
be displayed on the monitor within the elevator. The
invention also extends to a system for providing video
information by this method.
In still another aspect, the invention provides a
method for displaying an image on a plurality of displays,
each display being in one of a plurality of elevator cabs,
the method comprising: defining a plurality of categories of
information; parsing a playlist having first data leading to
first information to be displayed, the first information
being information associated with a category selected from
the plurality of categories; based on the first data,
retrieving the first information; assembling second data,
the second data being representative of an image that
includes the first information; and distributing the image
to each display.
In still another aspect, the invention provides a
method for displaying an image on a display in an elevator
cab, the method comprising: defining a plurality of
categories of information; parsing a playlist having first
-2-
CA 02458358 12008-01-22
60412-3044D
data leading to first information to be displayed, the first
information being information associated with a category
selected from the plurality of categories; and based on the
first data, retrieving the first information for display in
the elevator cab.
In yet another aspect, the invention provides a
computer readable medium having computer readable
instructions stored thereon for execution by a processor for
performing a method for displaying an image on a plurality
of displays, each display being in one of a plurality of
elevator cabs, the computer readable instructions
comprising: code means for defining a plurality of
categories of information; code means for parsing a playlist
having first data leading to first information to be
displayed, the first information being information
associated with a category selected from the plurality of
categories; code means for, based on the first data,
retrieving the first information; code means for assembling
second data, the second data being representative of an
image that includes the first information; and code means
for distributing the image to each display.
In a further aspect, the invention provides a
computer readable medium having computer readable
instructions stored thereon for execution by a processor for
performing a method for displaying an image on a display in
an elevator cab, the computer readable instructions
comprising: code means for defining a plurality of
categories of information; code means for parsing a playlist
having first data leading to first information to be
displayed, the first information being information
associated with a category selected from the plurality of
categories; and code means for, based on the first data,
-2a-
CA 0245835812008-01-22
60412-3044D
retrieving the first information for display in the elevator
cab.
In still a further aspect, the invention provides
a system for providing video information to a plurality of
display monitors, each display being in one of a plurality
of elevator cabs, the system comprising: a plurality of
elevator display units each having a display monitor
position within a respective elevator cab to display video
information to passengers within the elevator cab; a
processor which; for a defined plurality of categories of
information; parses a playlist having first data leading to
first information to be displayed, the first information
being information associated with a category selected from
the plurality of categories; based on the first data,
retrieves, over a data communications path, the first
information from a source; assembles second data, the second
data being representative of an image that includes the
first information; and distributes the image to each display
monitor.
In yet a further aspect, the invention provides
asystem for providing video information to a display monitor
being in an elevator cab located in a building, the system
comprising: an elevator display unit having a display
monitor position within the elevator cab to display video
information to passengers within the elevator cab; a
processor which: for a defined plurality of categories of
information; parses a playlist having first data leading to
first information to be displayed, the first information
being information associated with a category selected from
the plurality of categories; based on the first data,
retrieves, over a data communications path, the first
information from a source for display in the elevator cab.
-2b-
CA 02458358 2008-01-22
60412-3044D
By "video information", it is meant any
combination of general, commercial, and building-related
information. By "commercial information", it is meant any
information relating to commerce and trade including
advertisements. "General information" is used here to mean
information of general interest, including news (recent
happenings, sports, entertainment, etc.) and weather.
General information can also include information associated
with the building within which the elevator is a part, for
example, 1) events associated with the building; 2) traffic;
3) transportation schedules (e.g., train/shuttle services).
By "building-related information", it is meant that
information specifically related to the particular building
where the elevators transport residents, tenants, and
visitors of the building. The building-related information
may include certain types of commercial information, such as
advertising for businesses within or local to the building
(e.g., coffee, shop, parking, florist), as well as
announcements by building management for available space
within the building. The building-related information can
also include forms of general information, particularly
relevant to the building and its elevator passengers. For
example, such information can include building activities
(e.g., holiday events, fire alarm testing), public
address/emergency messages, traffic information, and other
information useful to the elevator's passengers. In
general, the building-related information is less limited by
the type of information, and more by its geography.
With this system, advertisers, online content
providers, and building management/owners can interact with
a specific, well-defined, and targeted audience in an
elevator, a setting where passengers often feel
uncomfortable being confined with
-2c-
CA 02458358 2004-03-15
coaiplete strangers. Elevator passengers often seck ways to avoid making eye
contact
with fellow passengers during what feels like an endless, unnaving duration of
time.
passengers no longer need to stare aimlessly at the floor or ceiling, but have
an
in.formative media resource to watch.
Occupants of high-rise offiee buildings are typically business people with
understood interests and buying tendencies. T'hese people are ideal recipients
for
targeted content and advertising. The system allows content providers (e.g.,
local and
national news sources) and advertisers to selectively target audiences based
on the
demog.raphics of a building, city, region, business segment, etc. Similarly,
national,
regional, and local online content providers are afforded an opportunity to
provide
elevator passengers with information of general iaterest. The system also
provides
building owners and managers the ability to provide video information
particularly
relevant and useful to tenants and visitors of their buildings.
Embodiments of these aspeets of the invention may include one or more of
tb.e following features.
The local server receives the scheduling information from the production
server over a data communicatian network (e.g., the Internot).
The system also includes a production server which generates scheduling
information associated with the general and commercial information. Thus, the
production server serves as a central distribution site where, among other
things, the
scheduling information (e.g., building play lists or scripts) are generated.
The
production server includes a production server database for storing building-
related
data, general information-related data, and commercial information-related
data. This
database includes, for example, building cbaracterization data, as well as the
addresses
from where the general and commercial information can be retdeved over the
data
communication path.
The production server includes a scheduling module, which retrieves the
data from the production server database and generates the scheduling
information and
a building loader interface through which data is passed between the
production server
and the local server. The building loader interface encrypts the data passed
between the
production server and the local server and authenticates that the local server
is one
assoeiated with the system.
-3-
CA 02458358 2004-03-15
The production server includes a billing module, which generates
documentation relating to the duration of time the general information and
commercial
information is displayed at elevator display unit. A database maintenance
module is
also included within the production server to update the production center
database
with information relating to elevator occupancy as a function of time.
The local server communicates with the elevator display unit via a local area
network including local and general information databases and a scheduling
information parser. General information and commercial information retrieved
over
the data communication path are cached in respective ones of the local and
general
information databases. The scheduling information parser generates a local
building
play list from the scheduling informationrelrieved from the production server.
The local area network includes an Ethernet path for connection to the
elevator display unit. The elevator display unit fiuther includes an occupancy
detector
for determining, at predetermined intervals, the number of occupants riding
within a
particular elevator.
Generating the elevator play list is performed with a graphical user
interface.
For the BOM interface, the video information includes a text message (e.g., in-
HT'ML format) and the play list includes a start date on which the text
message is
displayed on the display monitor; an end date on which the text message is
displayed
on the display monitor, and a day segment indicating a portion of a day the
text
message is displayed on the display monitor.
The user interface is remote from said local server and communicates
with said local server over a data communications path, such as the Intemet, a
dial-up
modem, or a local area network. The play list is a building operations play
list, with the
video information and scheduling infonnation for generating the building
operations
play list relating to building operations.
The local server further receives a production server play list from a
production server, remote from said local server, over a data communication
network,
said production server play list associated with general and commercial
information for
display on the display unit, The local server includes a parser, which
genem.tes a local
building play list from the production server play list and the building
operations play.
Other features of the invention will be apparent from the following
description and from the claims.
-4-
CA 02458358 2004-03-15
BRIEF DESCRIPTION OF'1'SE DRAWINGS
Fig.1 is a block diagram of the information distribution system of the
invention.
Fig. 2 illustrates the concept of micro-demographics.
Fig. 3 is a block diagram of a building subsystem porrtion of the infortnation
distribution system of Fig. I.
Fig. 4 is an example of a display screen of the display monitor of Fig. 3.
Fig. 5 is a block diagram of the production center of Fig. 1.
Fig. 6 is a flow diagram for the operation of a schedules module of the
production center.
Fig. 7 illustrates the format of a play lis#.
Fig. 8 is a functional block diagram of a building server of the building
subsystem portion of Fig. 3.
Fig. 9 is a fanctional block diagram of the wide area interface between
building servers and the distribution channel.
Fig.10 is a functional block diagram of the display generator LAN
interface.
Fig.11 is a functional block diagram of the display server arcbitecture.
Fig. 12 is a block diagram illustrating the BOM interface of the information
distribution system of the invention.
Fig. 13 is an example of a message template used by the BOM interface to
create messages.
Fig. 14 illustrates the fonnat of a BOM play list.
Fig. 15 is a functional block diagram of a building server of the building
subsystem portion of Fig. 12.
Fig. 16 is a flow diagram illust<ating the operation of the parsing fiuiction
of
the BOM interface.
Fig. 17 illustrates the fonnat of a local buildin.g play list.
Fig. 18 is a functional block diagram of the display server architecture.
Fig. 19 is is a block diagram of the information distribution system of the
invention.
-5-
CA 02458358 2004-03-15
; _ . . _
Fig. 20 is a functional block diagrau of the content retrieval procedure of
the method of the present invention.
Fig. 21 is a flow diagram illustrating the validation procedure in the method
of the present invention.
Fig. 22 is a flow diagram illustrating the file update procedure of the method
of the present invention.
Fig. 23 is a functional block diagram of the local play list development
procedure of the method of the present inventioa
Fig. 24 is an illustration ofthe generic play Iist expansion procedure in the
process of the present invention.
Fig. 25 is a block diagram illustrating an alternative embodiment of a BOM
interface of the information distribution system of the invention.
DESCRTI'T1ON OF THE PREFERRED EMBODIMENTS
Referring to Fig. 1, an information distribution system I provides a media
outlet for distributing general information along with digital advertising to
elevator
display units 10 mounted in elevators 12 of high rise office buildings 14
(represented
by dashed-line boxes). System 1 includes a production center 20 which--among
other
importaut tasks described below-creates and distributes elevator display data
by
merging advertising with the "real time" general information. The general
information
is considered "real tune" because the information is relatively ctuxent
(refreshed at
defined periodic intervals) with system 1 collecting, formatting, and
displaying the
information without human intervention. The general information is provided by
any
number of sources 22 (e.g., websites) connected via a distribution channel,
here the
Internet 24.
Each building 14 includes a building server 28 which interfaces with
production center 20 via lnternet 24 to develop presentations of merged
advertising and
general information to be exhibited on elevator display units. As is described
in greater
detail below, each building server provides the general and adverdsing
information to
each elevator display unit 10 of associated elevators 12 through a local area
network
(LAN) 30.
-6-
CA 02458358 2004-03-15
Infonmation distribution system 1 utilizes a concept cailed "micro-
demographics" which allows advertisers and online providers to target a highly
desirable demographic, business population. The desired audience targeted by a
particular advertiser or on-line provider may vary greatly and depend on a
number of
factors. As will be discussed below, system 1 collects or otherwise determines
the
demographics associated with a particular building as well as the occupants of
that
building. Thus, the geographical location and elevator traffic patterns of the
building,
and the nature of the business of the building ocoupants are determined by and
stored at
production center 20 so that a building script or play list 68 (Fig. 5) of
advertisements
and general ("real time") content can be matched to the building.
Referring to Fig. 2, buildings 14 are shown encircled to represent that they
belong to a particular geographical region. Smaller encircled groups 7a-7f
represent,
for example, buildings 14 within a city (e.g., Boston) are also shovm
encircled by larger
geographical regions 8a-8b (e.g., New England). aeography is generally a very
important demographic factor, however, as important may be the particular
business
segment which is targeted. Thus, several buildings 14a 14c which are from
different
geographical regions, but associated with the same business segment population
(e.g.,
financial) may be grouped together (shown bounded by the cross hatched area).
The
ability to parfition demographics by both geography and business segment
provides
tremendous value tD content providers- and advertisers.
In an example of one application of the system, assume an advertiser wishes
to distribute an advertisement targeted. specifically at the financial
community in the
northeast region of the United States. The*adverkisement needs to appear over
a two
week period during morning prime time hours. Production center 20 provides the
advertiser with an automated request entry process for capturing this
pertinent
information representative of the target demographic. Production center 20
creates,
from the target demographic, building play list 68 of potential building
candidates for
the advertisement and defines possible run time slots for when the
advertisement is to
be displayed. Several factors affecting which of a number of buildings are
candidates
and wluch time slots are available include: the target demographic (e.g.,
financial
community in northeast United States), the number of adverdsement impressions
(i.e.,
the number of times an adverdsement is viewed) purchased, the advertisement
start and
end dates (e.g., start and end of a two week period), prime time requirements
(i.e.,
-7-
CA 02458358 2004-03-15
prime time morning), the advertisement formatt (280 x 90 anima2ed GIF file)
and
advertisement locator (whes+e (lIF file is located). Once the advertisement
time slots
arc identified, production center 20 determines the general information (e.g.,
news
article, weather update) provided by an online provider that is to be merged
and
displayed with the advertisement Building play list 68 specifies the format
and content
of the elevator displays for every instant of the day. Thus, in the example,
production
center 20 schedules the advertisement to be played at 9:00 am. and 15 seconds
simultaneously with a local news article in one building play list while
running the
sanae advertisement at 8:15 a.m. and 0 seconds with a weather update in
another
building play list. It is important to note that building play list 68 defines
what gets
displayed and when, but does not contain the actual display content. Instead,
building
play list 68 provides pointers for obtaining the information over Intemet 24.
With information relating to the advertisement imbedded in the building
play list, production center 20 must then present the advertisement to
elevator
occupants. Building server 28 is responsible for downloading the building play
list
from production center 20, retrieving over Internet 24, the specified
advertisement and
general information, followed by assembling and distributing the advertisement
and
information within displays which are to be viewed in elevator display units
10.
Building server 28 uses the pointers in play list 68 to retrieve the content
and store it
locally to a particular building 14. This allows building server 28 to create
a very high performance broadcast channel within building 14. In the example,
building server 28
uses an advertisement locator embedded in play list 68 to retrieve and store
locally the
animated GIF file for the advertisement. With the content stored locally,
building
server 28 reads piay list 68, assembles displays at the times indicated by the
list and
distributes them to the individual elevators 12. T'hus, in the example, at
9:00 a,m. and
15 seconds, building server 28 assembles the advertisement with the specified
local
news story and displays it in elevators 12.
Details relating to the major components of information distribution system
1 follow.
Referring to Fig. 3, elevator display unit (EDLT)10 receives and processes
data provided by buildfng server 28 to create display presentations. Elevator
display
unit 10 includes a display 13 controlled by a single-board computer 34 and a
network
interface card (NIC) 36. Display 13 includes an LCD controller, a back light
assembly,
-8-
CA 02458358 2004-03-15
a power converter, and a flat panel display (none shown). Computer 34 manages
the
operation of elevator display unit 10 including system setup and monitoring,
network
overhead, display data routing, and elevator occupancy. Network interface card
36
intemcts with local area network 30 and is configured by computer 34 during
system
S startup. Display data being broadcast downstream from building server 28 to
elevator
display units 10 represents the m.ajority of the network ttafl'ic. In the
dowastsearn
dire.ction (from building server 28 to elevator display unit 10), network
traffic is mostly
comprised of display broadcast data. There is a limited amount of control
information
in the downstiream direction, however this is negligible. Network interfaoe
card 36
routes display data directly to display 13. Control information will generate
an
intarupt to computer 34 to request service. In the upstream direction (from
elevator
display unit 10 to building senver 28), network traffic includes occupancy
information
and system monitoring data. All upstream data is generatod by computer 34 and
passes
to network interface card 36 for transmission,
Data from buil.ding server 28 is transmitted to each elevator display unit 10
via local area network 30 (shown enclosed by dashed lines). In particular,
data is
transmitted through copper twisted pair lines 38 via an Ethernet network
switch 40 for
managing data flow.
One important feature of system 5 not yet discmswd, is its closed-loop
nature. Advertising is measured based on impressions (i.e., the number of
times an
advertisement is viewed). To quantify the number of impressions delivered by
system
1 requires system feedback which is generated using elevator occupancy
measurements.
To provide feedback to system 1, each elevator display unit 10 includes an
occupancy detector 42 for determining the number of occupants in a particular
elevator
tbroughout the day at predetermined time intervals (e.g., every 5 seconds).
This
information is summarized on a per building basis and uploaded via building
server 28
to production center 20 once a day, typically during downtime periods.
Production
center 20 uses the feedback for billing and maintenance of a production center
database
60 (Fig. 5). In particular, this feedback is used to update the advertisement
impressions
which are still to be displayed and for creating statisticat teaffic
information for each
building. This data is critical to the scheduling and advorkisement sales
process.
-9-
CA 02458358 2004-03-15
Occupancy detector 42 utilizes sensors (not shown) to generate a pair of
pulses when a passenger enters or leaves the elevator. The sensors are, for
example,
imbedded in the elevator doors. The pulse charwteristics of the sensors define
whether
the passenger is entering or departing the elevator. Occupancy detector 42
maintains an
oceupancy count based on these sensors. Computer 34 samples the occupancy
count
periodically. Each elevator display unit 10, therefore, generates a daily
occupancy
history which is used in the advertisement billing process.
Referring to Fig. 4, under the control of building server 28, display 13 is
segmented so that specific types of information are exhibited within
particular regions
of the display. Display 13 includes an advertising banner section 44 for
displaying
advertising and other commercial information and a"real time" content section
46 for
viewing general information. "Real time" content section 48 may, in turn, be
divided
into other sections, for example, exrdbit story excerpts 50, one or more
piciures 52
related to the excerpt, and descriptions of the pictures 54. For example, as
shown here,
elevator passengers are provided, in banner section 44, the day's breakfast
specials
from a cafe located, for example, in the first level of building 14.
Siunultaneously,
news text of general interest is displayed within a story excerpt 50 along
with a related
picture 54.
As stated above, a primary function of production center 20 is to create and
distribute the elevator display data. Creation of the elevator display data
includes
merging of news, information, and advertising to produce the building-specific
play
lists 68. Distribution of the play lists is accomplished using the
conneetivity provided
via lntemet 24.
Another important function of production center 20 is management and
rnaintenance of a website for system 1. The website provides management of
building
14 and a central location where potential advertisers can request information
relating to
advertising on the system. Elevator occupants can also access the website for
additional information relating to both the displayed "real time" information
or
advertising information viewed on display 13 in elevator 12. For example, an
occupant
may not remember details of a particular advertisement (e.g., today's specials
at one of
the building's dining facilities) or may want to learn more about breaking a
news story
displayed in "real time" content sedion 48.
-10-
CA 02458358 2004-03-15
PRODUCTION CENTER
Referring to Fig. 5, production center 20 includes a production center
database 60, scheduling module 62, building loader 64, and billing and
database
maintenance module 66. In general, production center database 60 stores data
related'
to advertising, "reat time" content, and building parameters.
Scheduling module 62 uses the data to produce play lists 68 for each
building 14. As discussed above, a building play list 68 (Fig. 5) serves as
the recipe
used by building server 28 to create display presentations exhibited
throughout the day.
Scheduling module 62 also provides advertising and content usage information
to
billing and database maintenance module 66 which generates billing summaries
and
invoices 70 for each advertiser and "real time" content supplier. Billing
summaries and
invoices 70 are also stored for later retrieval in the production center
database 60.
Production Center Database
Production center database 60 includes three basic types of data: 1) building
characterization; 2) 'real time" content, and 3) advertising content.
Building characterization data is generated to establish a particular
building's micro-demographic profile. Creating a micro-demographic begins with
a
building characterization process. The building characterization process
consists of .
three components: 1) building geography - where is the building (city, state,
region(s),
etc.); 2) business segments - the building population is categorized into
business
segments (banki.ng, insurance, financial services, law, advertising, real
estate, etc.); 3)
self learned - the system is able to learn building characteristics once
installed. Peak
travel periods (used to establish prime time periods) and average elevator
occupancy
(important in scheduling) are examples of self-learned characteristics.
The results of the characterization process are stored as building
characterization data in production center database 60 for use in the
scheduling process
and includes the information listed in Table I below.
-11-
CA 02458358 2004-03-15
Bftilft- Dft .!B1uIiiin *
Building Location <Building Name>
<Street Address>
<Ci State ZTP>
Management Organization < Name>
<Street Address>
<City, State ZIP>
Management Contact <Name>
<Phone>
Building Population <number of occupants>
Building Classification <primary classification>
veconda classification>
Regional Designation <R 'on ID>
Local Desi tion <Local ID>
Number of elevator displays <Mumber>
Number of lobby di la <number>
Building hours From: <time of day> EST
To: <time of da EST
Prime time periods From: <time of day> EST
To: <time of da EST
Average elevator occupancy <number>
Network Address <IP Addresa>
Authentication <Authentication ID>
Subscription Fee -4lmonth>
Real Time Content <List of Content>
Preferences
Table I
The results of the ch.aracterization process are stored in productioncenter .
database 60. The format of this data is described in the building
characterization data
section. Online content providers and advertisers create associations between
their
target audience and the buildings by specifying audience micro-demographics.
The
micro-demographics choices for the advertisers map one-ta-one with the
characterization categories for the buildings, shown in Table I th,erefore
ensuring an
association. As will be described below, a scheduling module maps the
advertisements
to the buildings via these associations
As stated above, "real time" information (general information) is the data
which is merged with advertising data to create elevator display data. To
accomplish
this, the content of the "real time" infonmation must adhere to specific
forrn:afs which
-12-
CA 02458358 2004-03-15
represent segment sections 44, 46 of display 13 and describe the content 50,
52, 54
contained within those segments (Fig. 4).
For example, for each "real time" content source 22 (Fig. 1), production
center database 60 contains an entry describing the format type and locataons
for each
content segment within that format. The format determines the number of
segments for
each entry . Locations are described using Universal Resource Locators (URI
s). Thc
database parameters maintained for each "real time" content source are shown
below in
Table II below.
"real:tiinebn=: Yb>
Source <Provider Name> <Street
Address> <Ci State 7V>
Source Contact <Name>
<Phone>
Refresh Interval <time>
Format Designation <format ID>
Content Se ent 1 <IJRL>
Content Se ant 2 <UItI,>
Content Se ent N <URL>
Table II[
Advertising content data consists of two components. The fiist
component defines when the advertisement must be run, the locations it is run,
and for
how long it runs. The second eomponent describes where the advertisement is
retrieved from and how it is inserted into the display. Consider the run
parameters ftrst.
Advertisers will purchase advertising time on the system in units of Cost Per
Thousand
Impressions (CPM). Advertisers may further target specific demograplzics by
requesting the advertising be distn'buted nationally, regionally, locally, or
at a specific
business segment. Ya addition, an adverfisement campaign is likely to have
time
parameters as well. For example, the campaign may run for only two weeks with
exposure required to be made between 10:00AM and 1:00PM each day. These
concerns constitute the advertising run parameters. Equally important is the
aetnal
advertising content and howit is intWated into the system and displayed. The
parameters that describe this information are the content patameters wbich
include the
-13-
CA 02458358 2004-03-15
advertising locator and formattype. The database parameters maintained for
each
Advertising content source are shown below in Table M.
Adve*semen itenf ;RADVERMSE Y9NT YD:,;,-
= ~ . =~Q~ '~'=,
Desi on
Source <Provider Name>
<Street Address>
<City, State ZIP>
Source Contact <Name>
<Phone>
Undelivered Impressions <number>
CPM <S>
Advertisement Start Date <date>
Advertisement Finish Date <data>
Demo hic Selector <miicro-demo a hie>
Prime Time Requirement <% of advertisement run time>
Delivery Time <start time - end time>
Advertisement Format <format ID>
Advertisement Locator <URL>
Table III
Scheduling lyio , ule
Scheduling module 62 has the primary function of creating building play
lists by generating both advertising and "reai-tlme" content from production
center
database 60 and then merging the content.
Referring to Fig. 6, scheduling module 62 performs a first parsing step
(100) to determine which buildings are potential targets for each
advertisement in
production center database 60. Scheduling module 62 utilizes information
provided by
the advertiser in an automated request entry process to generate an initial
list 72 of
buildings and adverdsements which can be paired together. The entry process is
available to advertisers using the production center website which provides an
electronic entry form for allowing the advertisers to enter the required
information
needed to schedule an advertisement for viewing by a targeted demographic,
business
population. Alternatively, advertisers may provide the pertinent infor.mation
through a
phone interview, an application form, or a third party representative.
Init.ial list 72 is
further pruned in a second parsing step (102) using secondary criteria, such
as
advertisement starUfinish dates, prime time requirements, delivery times, and
-14-
CA 02458358 2004-03-15
impression parameters. The result of these pairing steps is an advertisement
build.ing-
specific list 68 indicating advertisements and time intervals for when those
advertisements conld potentially be displayed.
Next, scheduler module 62 considers "real tinne" content preferenoes for
each building as set forth by building characterization data (see Table I)
associated with
that building (104). Using this infomiation, a "real time" building specific
list 76 of
"real time" content is generated.
With both the advertising content and "real time" content specified for a
particular building, scheduler module 62 merges lists 74 and 76 to provide a
building
play list 68 (106). In particular, when mergi.ng the advertising and "real
time" content
for each building 14, scheduler module 62 considers the content format, time
intervals,
and advertisement distribution. Time intervals and advertisement distribution
are
considered first because they determine when an advertisement will be
displayed and
what "real time" content will acaompany it. "Real time" content is presented
at fixed
intervals (e.g., every 30 seconds). As a result, scheduler module 62 will
place the "resl
time" content first.
Advertising placement is also subject to distribtttion and occupancy
considerations. The commuting patterns of the network audience is always an
important disGribution consideration in effectively distributing a partieular
advertisement. For example, most people arrive to work take lunch, and leave
work
within 30 minutes of the same time each day. Scheduler module 62 ensures
therefore,
that the same advertisement does not run within 30 minutes of when it ran the
previous
day for any given building. The result is a more uniform advertisement
distribution
within a building demographic. Advertising occupancy is another important
consideration. Advertisetnents ean-be rotated quickly (e.g., every 15
seconds).
Without a fully populated advertisement schedule however, system 1 would
constantly
rotate the same advertisement or a limited set of advertiseiuents. TWs could
be a
potentially unattructive annoyance for elevator passengers. To eliminate this
possible
annoyance, scheduler module 62 lengthens the display period for each
advertisement to
make the transitions less noticeable.
Once advertising and "real tune" content has been defined for each time
slot, scheduler module 62 areates the display. The format of the advertising
and "real
time" content is critical because it determines which of a variety of
templates is
-15-
CA 02458358 2004-03-15
selected to create the overall display. As has been described, both the
advertising and
"real time" content must adhere to one of a set of predefined formats. When
both are
merged together they are placed into a frame. Frames represent the template
from
which the final display is generated. Since content formats can vary,
scheduler module
62 selects the appropriate fiame type in order to merge them. The nuxnber of
content
formats is intentionally limited to simplify the merging process. With the
time slot and
frame type information defined, scheduler module 62 is able to constniet
bailding play
list 68.
Refening to Fig. 7, the format of a building playlist 68 used to manage
the assembly of both "reai time" content data and advertising content is
shown. Play
list 78 includes a"real time" content section 80 which is generated directly
from "real
time" data within production center database 60 and defines refresh periods
for the
"real time" content. Play list 78 also includes an advertising content section
82 which
defnes the time as well as frame type used for the advertising content.
Referting again to Fig. 5, production center 20 also includes a building
loader 64 which serves as the interface between production center 20 and
buildings 14
within system 1. Because communication with the buildings occurs over Internet
24,
an inexpensive, yet broad distribution mechanism is provided. Unforhuiately,
Internet
24 also represents a path for potential system eoruption. In eonsideration of
this risk,
system I is designed to require that each building server 28 request
information from
production center 20, rather than having production center 20 broadcast data.
Buildiag
loader 64 performs an authentication procedure to ensure that the request is
being made
from a server associated with and recognized by system 1 for each building
requesting
a play list. Before being distributed, building loader 64 encrypts the play
list to furth.er
protect the information from potential corruption.
BI'Iling and Database Maintenance Module
Billing and database maintenance are also critical to the closed loop
nature of system 1. As discussed above, scheduling module 62 generates
building play
lists based on micro-demographic parameters and the. statistical probability a
number of
advertisement impression are made at a given time within a specific building.
To close
the system loop, elevator occupancy information is accumulated for each 14
building
on a daily basis. This allows system 1 to adapt to changes in building
characteristics to
-16-
CA 02458358 2004-03-15
better distribute the advertising and eonteat. A billing and database
mainteaance
module 66 is used to provide this feedback to system 1. The two operations,
billing and
database maintenance, leverage the same processes, but deliver different
outputs. The
feedback process involves overlaying building play lists 68 onto the building
occupancy numbess. From this process, the actual number of impressions can be
calculated for eaeh advertisement. The billing operation wiIl use the
information to
create reports and invoices 70 for the advertisers. The database maintenance
operation
uses this data to update production center database 60 with the impressions
for each
adve,rtisement yet to be delivered. That is, the number of "Undelivered
Impressions"
(see Table lII) is updated. In addition, billing and database maintenance
module 66
will further alter the building occupancy numbers to update the building
characterization data. For example, billing and database nnaintenance module
66 may
update fields labeled "Building hours", "Prime time periods" and "Average
elevator
occupancy" (see Table I). Important feedback here is defining dead zones
(times when
there are few elevator passengers), peak viewing periods, and average elevator
occupancy. These are inaportant patameters used by scheduling module 62 in the
scheduling process.
Buildin Sg, erver
In general, building server 28 interfaces with production center 20,
caches advertising and "real time" content, develops elevator displays, and
manages
local area network 30.
With reference to Fig. 8, building server 28 includes a production
center/WAN (PCWAN) interface 90 which is responsible for communicating with
production center 20 and the Internet 24. As previously described, each
building 14
receives from production center 20 a play list 68 which defines the display
content and
time interval the display content is to be presented. Internet 24 is used to
capture the
'vtal time" content and transport the advertising information. "Real time"
output from
interface 90 is deposited into a 1oca1 "real time" database 92 while
advertising output
retrieved from Internet 24 is cached in an advertising database 94. These
represent
local copies of the information retrieved via the Internet. Local copies are
maintained
in order to avoid Iatenoy problems which would realistically prohibit creating
high
performance display presentations including, for example, animation,
streatning video,
-17-
CA 02458358 2004-03-15
and movie effects. Updates to the databases are performed as needed as defined
by the
building play list.
Assembly and display of the content is perforuxed by an Display
GeneratorltAN (DGLAN) Interface 96 which inteaprets building play lisi 68 and
assembles the specified content. The result is an HTTN/a. file, served via
local area
network 30 to each elevator display unit 10.
Building server 28 also includes an occupancy database 98 for storing
information relating to occupancy of the individual elevators 12 in the
building.
Production Center/WAN Interface
Referring to Fig. 9, PCWAN interface 90 nmnages the intesaetion with
Internet 24. Interaction with the wide area network (WAN) is generally
initiated from
the buildings in order to increase security within the systenn. PCWAN
interface 90
includes a play list parser 110, which performs a translation to create local
references
for the advertising and "real tun.e" content. The ttanslation is required
because atl
content displayed within building 14 is cached locally within databases 92,
94. Thus,
the WAN-based URLs contained in the original play list are invalid. Parser 110
also
interacts with an advertising content accumulator 112. Since advertisements
are stored
locally to the building, an aceumulation process must take place to create
this local
store. Parser 110 initiates advertisement accumulaxion when it determines the
play list
contains an advertisement not currently available in the advertisement content
database.
The accumulator function w3ll interface with the WAN to retrieve the missing
content
and store it in the database. The loeal URL for the advertisement is retumed,
wliich the
parser writes to the local building play list. A similar operation takes place
for "real
time" content. In this case however, updates are perfonned based on a refresh
period.
The refresh period for "real time" content is defined in the building play
list. Play list
parser 110 passes the refresh period, the WAN based URL, and the "real time"
database
address to the "real time" proxy module 116. Proxy module 116 schedules the
refresh
cycles and interfaces with the WAN interface contro1109 to retrieve the "real
time"
content. The content is stored based on the locator provided by parser 110.
-18-
CA 02458358 2004-03-15
Display GeneratorlLAN Interface
Referring to Fig. 10, Display Generator/L" (DGI.AN) interface 96
performs two distinct operations: 1) assembly and transfer of the display, and
2)
occupancy data collection.
With respect to the second of these operations, occupancy calculations
play a very important role in the system. Advertising is measured in cost per
thousand
(CPM) impression increments. An impression is defined as someone being exposed
to
the advertisement. In system 1, advertisement exposures occur in elevators 12.
To
quantify the number of advertisement impressions displayed using system 1, a
method
for measuring elevator occupancy is required. The DGILA.N Iinterfsce 96
accumulates
measured information from each elevator and creates occupancy=database 98 for
each
of buildings 14. An occupancy accumulator 130 extracts the measured data from
each
elevator during system downtime (typically at the end of the day). This
information
provides the elevator occupancy at constant intervals throughout the day.
Occupancy
accumulator 130 summarizes this information into a single list, which is
passed to
production center 20 for billing.
Display assembly and transfer is the primary function of DGLAN
Interface 96. Display assembly is dictated by local building play list 114
which uses
the same format as building play list 68 of Fig. 5, except that the "real
time" control
parameters are deleted and all content locators (e.g., URLs) have been
replaced by local
equivalents. DGLAN lnterface 96 includes a display format parser 120 and a
display
assembler 122. Display format parser 120 uses Hyper Text Iviarknp Language
(HTML)
to build the framework for the display. HTMI, is used extensively on Internet
24 to
develop display information and is easily understood by modem browser
technology.
Display format parser 120 generates the HTMI,, template that is used, once it
is
populated, to create the actual display. Local building play list 114 defines
the frame
type. Display parser 120 interprets the frame type and generates an HTMI,
file,
specifying the physical attributes of the display. These attributes include
the absolute
position, size, and definition of each content segment lviissing from the
template are
the pointers to these content segments. Content segment pointers are generated
by
display assembler 122.
-19-
CA 02458358 2004-03-15
Display assembler 122 is used in the fi.nal step of the display generation
cycle. Display assembly is initiated based on the time intervals defined in
the play lists.
Each display is assembled and passed to a display server 124 as defined by its
time
indicator. Display assembler 122 parses the HTML template generated by the
display
format parser 120 to find the content segment definitions. The template wi11
match the
content segment definitions specified in play list 114. As a result, display
assembler
122 inserts the location pointer for each content segment. When each content
segment
pointer has been inserted, the FfTML file is ready to be passed to elevator
display units
10.
Elevator display units 10 are connected to the building server 28 via
local area network 30. Display server 124 manages local area network 30 by
retrieving
the H'1'MI., file from display assembler 122 along with the "real time" and
advertising
content specified by the HTML. Display server 124 then translates this data
into a
display format compliant with elevator display units 10, encapsulates the
translated data
with a file transfer protocol and passes the encapsulated data to network
switch 40 (Fig.
3) for broadcast. The task of retrieving the data from display assembler 122
is made
more difficult by the great distances (e.g., > 1500 feet) that separate
building server 28
from elevator display units 11.
Referring to Fig. 11, display server 124 and elevator display units 10
form networked hostJdisplay pairs, where elevator display 13 is merely an
extension of
the server display. The HTML file is interpreted by a browser 136 (e.g.,
Internet
Explorer 4.0, a product of Mierosoft Corporation't). Browser 136, within the
operating
system (e.g., Microsoft Windows NT a product of Microsoft Corporation ) used
by =
building server 28, interfaceswith a display driver 138 to communicate with
hardware
associated with display 13. Display data is extracted by a translator 140,
which re-
targets the data to elevator display unit 10 and display 13. This data is
cached local to
server 28 to reduce the effects of browser refresh delay. A network protocol
encapsulation software module 142 extracts the data from the cache and adds a
TCP/IP
conununication layer. The encapsulated data is passed to the network interface
and
transmitted through network switch 30 (Fig. 3) to the LAN.
Further embodiments are supported by the following claims. For
example, the distribution channel used by information distribution system 1
describetl
above is the Tnternet 24. The lnternet, or "web " provides a growing and
existing
-20-
CA 02458358 2004-03-15
infrastructure for obtaining inforrniation and establishing communication
between
computers. However, information distribution system 1 can also be implemented
using
other communication channels including cable modem, satellite, )MSL.
Twisted pair lines 38, discussed above in conjunction with Fig. 4, can be
replaced with other forms of transport media including fiber optic, eoaxial
lines, RF
tran,smission). Moreover, in certain applications an asymmetrical digital
subscriber line
(ADSL) can be substituted for the Ethernet connection in local area network 30
in Fig.
3.
Building Owner Manaster (BOM) Interface
The information distribution system 1 shown in Fig. 1 was described
above as including a production center 20 which interfaces with building
servers 28 to
develop presentations of merged advertising and general information for
display on
elevator display units 10. As also stated above, system I can provide building
owners
and managers the ability to communicate with tenants resident in their
building. As
will be described immediately below, this capability is provided to building
managers
through a Building Owner Manager (BOM) interface.
Referring to Fig. 12, for example, a BOM interface 200 is shown to
include BOM interfaces (BqMGUI) 202 which communicate with one or more
building subsystems 204 via distribution channe124. Building subsystem 204 is
shown
to include building server 28, building LAN 30, and building display units 206
including elevator display units 10 mounted in elevators 12. Distribution
channe124,
as shown.in Fig. 1 was represented, for example, by the Internet. In this
case,
distribution channe124 is shown to include other interconnection approaches,
such as, a
direct or indirect connection via a public building LAN 208, a dial-up modem
210, as
well as an Internet Service Provider 209. It is important to note the
distinction between
public building LAN 208 and building LAN 30 of building subsystem 204. In
particular, public building LAN 208 represents building management's own local
area
network for inter-office communication. Building LAN 30, on the other hand, is
a
private local area network, used exclusively for information distribution
system 1.
In general BOM interface 200 allows building managers to deliver
messages to building tenants who can view the messages on the display units 10
mounted in elevators 12 as well as other displays 206 positioned throughout
the
-21-
I
CA 02458358 2004-03-15
building. Messages generated using a BOMGUI 200 are merged at the building
server
without interaction from production center 20. Thus, building Ynanagers are
able to
control the creation of the messages and deploy and modify the messages
quickly.
Examples of the wide variety of message types deliverable using BOM
interface 200 include:
= Time critical messages ineluding fire alarm testing, parking
gara.ge closiaes, changes to building hours, building-speeific traffic
information;
= Special Events such as holiday events, building activities;
= New building featues/services including health club,
cafeteria facilities, parlting, coffee shop, florist;
. Public Address/Emergenay messages including instiuctions
for stuck elevator passengers, storm waraings, fire infomsation; and
= Advertising messages such as announcements for available
space, description of the management organization and their capabilities.
BOM User Interface (BOMGUII
BOMGUI 200 represents the user portion of BOM interface 200 for providing
an environment to building management to create, modify, and send messages to
display units from literally anywhere in the world via nearly any of a wide
variety of
interconneation means.
Referring to Fig. 13, BOMGUI 202 uses a template 212 to define message
structure and format. Template 212 is based on HTML, thus providing a flexible
and
rich environment for its development. In one embodiment, template 212 fits in
a 640 x
480 pixel format and utilizes a comment field <l--3nessage text --> inserted
where the
message information is to be placed. The message text that populates the
selected -
template is entered using BOMGUi 202. Text entry fields are provided whieh
allow
for tabs, carriage returns, and spaces, along with plain text information.
BOMGI7I 202 is also able to import already completed html files. This enables
building owners and managers the ability to create special announcaments and
display
them on the information system without using the template structure discussed
immediately above.
1.1.1 Message Creation
The message creation process requires that each of the fields of the template
be
populated. Within BOMGUI 202 this is aoeomplished in one of two ways. The
first
.22-
CA 02458358 2004-03-15
way uses a message creation wizaz~d,- a user-friendly prograin that takes the
user through
each step of the message creation process by prompting them for the required
input as
they populate each field. The second way uses a message entry form which may
have
been previously generated by the wizard and pre-stored to serve as a pattem
for
creating messages. This form contains all the message fields the user must
populate
and is typically used to edit an existing message. Using either approach, the
result of
the entry process is a valid message which can be displayed on the systenz.
BOMGUI
202 converts the information from template 212 into a file, capable of being
read and
displayed on the display units of the system.
As will be described below, BOMGTJI 202 includes parsers for parsing the
selected template file. A first group of parsers searches for the comment
field <!--
message text -->. When this field is located, a second group of parsers
operates on the
message text to convert this information into an HTML format. The result is an
13TIviI.
output file with the name <nnessage name>.htm. This file is submitted to
building
server 28 for display on the system. BOMGUI 202 also allows managers the
ability to
preview messages prior to being displayed within the elevator or other
displays in the
building. This process is repeated for each message that is created by BOM(3UI
202.
1.1.2 BOM Play List Creation
BOMGUI 202 allows building managers to create multiple messages for display
in the building. These messages may be programmed to appear simultaneously or
distcabuted throughout the week/monthlyear.
Referring to Fig. 14, a BOM play list 220 includes a series of building
messages
221, each of which is comprised of several elements: start date, stop date,
period of
day, message template, and message text The start and stop dates deteranine
when the
message is first displayed by the system and when it will be removed from the
system.
The period during the day a message can be displayed is also selectable within
BOMGUI 202. In one embodiment, the day is divided into four segments: AM
Segment, Lunch Time (LT} Segment, PM Segment, and Sleep (SLP) Segment. These
represent time slots within the day, and are system programmable. For example,
the
AM Segment may be defined as the time from 6:00AM to 11:00AM each day. The
building manager may select a specific time period for the message to run or
they can
choose to have the message run all day. T'hus, BOM play list 220 defines time
periods
-23-
~ . ~.:. . ~~ -.~ ~_ _ ~~
CA 02458358 2004-03-15
when each message is displayed and for how long (e.g., month, year). The
format of
BOM play list 220 is similar to the building play list 68 mv4ftd by Production
Center
20 described above in conjunction with Figs. 5-9. However, BOM play list 210
includes additional start and stop fields.
BOM Play List 220 iscreated using BOMGUI 220 and is generated by
individually stepping through each HT1VM output file message to determine the
period
of day and start and stop dates. The period of day is used to define in which
time
segments the message will appear. The start and stop dates are transfornned
directly
into the BOM play list fonnat. For example, the sample BOM play list shown in
Fig.
14 indicates that bom messagel.htm is programmed to run in only the AM Segment
between 6/12/98 and 6/13/98 while bom message2.htm is programmed to run all
day
between 6/12/98 and 6/14/98.
As stated above, BOMGUI 202 allows building management to send messages
to displays from literally anywhere in the world. This is accomplished using
off-the-
shelf LAN and WAN technology available in most computers today. BOMGUI 202
includes a connection setup menu. The connection setup menu allows the user to
define the method(s) for interfacing with the building subsystem through the
distribution channel 24. Using the setup menu, the user can create multiple
paths to
send messages to building subsystem 204. For example, when residing in the
building,
the building manager may send messages via public building LAN 208. This same
building manager may also need to use BOM interface 200 to send messages to
the
system from a remote location via a dial-up modem 210 connection or Internet
Service
Provider (ISP) 209. In each case, the building manager would simply define the
connection information within BOMGUI 202, save it, and then choose the
appropriate
connection setup each time a message is sent. BOMGUI 202 automatically attends
to
establishing the connection, sending the message information, and disabling
the
connection each time messages are submitted.
1.2 Building Subsystem
BOM interface 200 utilizes a BOM play list parser to parse BOM play list 220
in a manner similar to the man,ner used by play list paxser 110 to parse
building play list
68, as described above in conjunction wiith Fig. 9. Specifically, play list
parser
-24-
CA 02458358 2004-03-15
translates the BOM play list 220 to create local references for advertising or
"real
time"content.
BOM interface 200 is also configured to permit building owners and building
managers to create and deliver messages through building server 28 and
building LAN
30 to a specific one or more of elevator display units 10. This flexibility is
particularly
usef-ul, for example, for providing instructions to elevator passengers in a
stuck
elevator. As a result, building management can maintain communication with the
stuck
elevator passengers without alarming passengers riding in other elevators.
In some embodiments, BOM interface works in concert with the produckion
center/WAN interface 90 described above in conjunction with Fig. 9.
1.2.1 Play List Parsing/Development
Referring to Fig. 15, in this case, the local building play list parsing
function of
building server 28 must be modified to receive messages from both a play list
assembled by production center 20 and BOM play list 220.
As described above in conjunction with Fig. 9, the operation of the play list
parser 110 in the absence of a BOM Interface was to remap the tTRLs to the
building
database. With the addition of the BOM Interface, a play list parser 222 must
now
perform both a remapping and an interleave operation.
Referring to Fig. 16, play list parser 222 is initiated (230) by an update to
either
Production Center (PC) building play list 68 or the BOM play list (232). If an
update
has not been made to either play list, parser 222 will await a predetermined
period of
time and then poll to determine a change in the update status of the play
lists. On the
other hand, if either play list has been updated, parser 222 then queries
whether PC play
list 68 has been updated (234). PC building play list 68 represents the
baseline version
of the local building play list 114. That is, local building play list 114 is
derived from
the starting point created from PC building play Ast 68. If building PC play
list has
been updated, parser 222 performs the URL remapping (236) described above with
reference to Fig. 9. Following the URL remapping, parser 222 performs a second
pass
to interleave information from the BOM play list 220 into the updated PC
building play
list 68 (238).
-25-
- --- ------------ -
CA 02458358 2004-03-15
In other applications, BOM interface 200 is used independently by building
managers as a means for commtmica,ting with their tenants without any
interaction with
a production center. In these applications, there is no PC play list within
which the
BOM play list interleaved. Thus, with reference to Fig. 16, play list 222
simply
determines whether &e BOM play list has been updated 232 and derives a local
building play list 114 solely from BOM play Iist 220.
The goal of the interleave function is to insert a programmed number of
building manager messages every minute during the designsted time period using
a
romnd robin priority scheme. The number of inessages inserDed per minute can
be
programmed from 0 to aU available slots. Of course, prior to inserting a
message parser
222 will verify that the current date and time fall within the startlstop
dates and time
period parameters of the message.
An example will help iIlustrate the manner in which parser 222 functions.
Assume a building manager has created and downloaded the BOM Play List shown
in
Fig. 14, via BOMGUT (202). If the current date is 6/12/98, and the slots per
minute is
set to 1, the parsers would produce a local building play list 114 shown in
Fig. 17.
Note that during the AM Segment, both bom messagel.htm and
bom message2litm are interleaved into the PC building play list 68. Also note
that
these messages atternate in "round-robin" fashion within the AM time segment.
During the LT, PM, and SLP time periods only bom message2.htm is displayed. In
these time segments, this message wilt appear every minute.
1.2.2 Message Storage/Transmission
Unlike the Production Center path for content assembly described above in
conn,jimction
with Fig. 10, the pages created by BOMGUI 202 do not require modification by
the
building subsystem. However, the advertising component of the page will be
subject to
automatic assembly within the building.
Referring to Fig. 18, BOMGIJi 202 will deposit message files into a BOM
Message Store 240. As display assembler 122 interprets the local building play
list 114
it vs+iIl look in the BOM Message Store 240 for all building messages. The
advertisement associated with the message is defined by the play list and is
inserted by
display assembler 122 before being passed to Display Server 124.
-26-
CA 02458358 2004-03-15
In embodiments in which building subsystem 204 interfaces with production
center 20, a dial-up modem connection is typically used to establish the
connection. To
add the fanetionality of BOM Interface 200, system 1 may need to be equipped
with a
network card to allow interaction with private building LAN 30. If the BOM
lnterface
physical interconnect is via dial-up modem 210 or ISP 209, a single modem
interface is
sufficient This is accomplished via software running on both the BOMGUI 202
and at
the production center 20 which performs retries and allows data multiplexing.
The
result is a minimal hardware implementation.
1.3 BOM Interface Security
BOM Interface 200 represents a direct path into information system 1.
As such, security for this interface is important to insure that inappropriate
or
unauthorized use is not allowed. The security procedures for the system are
performed
at three levels: BOMGUI password protection, secure connections, and
password/access protection at the building subsystem. BOMGIJ1202 performs a
username and password check procedure prior to invoking the user interface.
The
passwords and useruaines are encrypted and stored in a protected file. Only
individuals
with root privileges are allowed to manipulate this information. At the
physical
interconnect level, the path names and dial up properties are encrypted and
only
accessible by authorized personnel. Lastly, building subsystem 204 provides
two
layers of protection. First, user name and password verification is performed
on every
message request to the system. This insures that the security monitor of
system 1 is
aware of all licensed users. Secondly, the BOM message information is kept in
a
separate partition on the building server 28. This insures that an
unauthorized user of
the system is precluded from accessing other fimctions not associated with the
system.
This three phased approach should make it very difficult for any unauthorized
access to
the system to occur.
In the embodiment described above in conjunction with Figs.13-18,
BOM interface 200 enabled building owners and managers to create and send
messages
to display units 10 mounted in elevators (or other displays) throughout a
building. In
particular, BOMGUI 202 represented the user portion of the interface for
allowing
-27-
.~.___,..n.~.,,~h__.~._:w.~.~..
CA 02458358 2004-03-15
owners and maaagers to greate, modify, and send messages to display units from
literally anywhere in the world.
Referring to Fig. 25, in another embodiment of a BOM interface 600, referred
to
here as "Screen Center Interface,' allows a Screen Center user 602 to create
messages
using any of a number of different commerci.ally available standard desk#op
publishing
tools (e.g., MicrosofflD Power Point, Adobe Photoshop). In particular, to
support the
highly scalable and flexible nature of the system, the Sareen Center Interface
includes a
printer driver 604, which translates a desktop image generated using the
desktop
publishing tool 605 into a file format consistent with information distnbukion
system 1.
Printer driver 604 then makes a web connection to a remote web server 606 via
a
secured socket layer (SSL) path 608. A web browser 610 allows the user to
schedule
messages and determine the buildings in which the messages wIII appear. In all
cases
the buildings available for a given user are strictly controlled through user
id and
password protection. Once the message has been scheduled, web server 606
places the
message in an FTP site director3+ at FTP server 612 for each building targeted
by the
message and recreates the screen center play lists. During the next retrieval
cycle, the
buildings will collect the screen center play lists and messages and build
them into a
local play list, -
An important element oftlus architecture is the ability of the system to
have multiple messaging sources for any given building. Because the product is
web
based, owners of multiple properties can allow a local building manager, a
regional
manager or a marketing group to each have access to the messaging capability
within
the buildings. The user id and password protection restricts access on an
individual
basis, and also provides that different groups could get a greater or lesser
share of the
available message inventory. The intelligent building server takes care of
interleaving
.
the multiple message sources and providing the proper access to inventory
Generic Play List and Content Selection
In the embodiments of the invention descn'bed above, the local building play
list
specifies the content used for each slot in the building prograinming. The
content is
retrieved from known sources to a central location on the building server.
Tbis content
information is provided to the elevator displays based on the local building
play list.
Another embodiment of the method and system of the invention may be used to
provide
-28-
~...~.
CA 02458358 2004-03-15
a buildang owner with greater flexibility in choosing the content and the mix
of
infornaation displayed in the building. In this approach, inform.ation is
still retrieved
from known sources by content mapping. However, when the retdeved Sles are
delivered to a processor in the building, such as, for exampley a building
server, a
virtnal hierarchy is added. The reason for this hierarchy is two fold. First,
information
is managed by category, and multiple sources of infonnation may be present in
a saurce
directory in the content mapping'file for a single category. As a result, the
building
server compresses the multiple sources from the source directory zn the
content
mapping file into a single category to create the local play list for its
particular building.
Second, the building server creates the local play list by inserting into the
list in
circular, repeating series (referred to herein as round-robi$) information
from the
source directory in the content mapping file for a particular category.
This embodiment provides another layer of protocol to accommodate the
dynamics of communicating with an elevator in a high-rise building.
Refen=inng to Fig. 19, an information distribution system 301 is shown that
provides a media outlet for distributing video information to elevator display
units 310
in a building subsystem 314. As noted above, the video information transmitted
may
include any combination of general, commercial and building related
information. The
system 301 includes a production center 320 with a network operations center
(NOC)
325 that creates a generic play list 321 for each buiiding 314.
The generic play list 321 defines categories of video information 323 to be
displayed at the elevator display units 310, such as national news, local
sports, events,
weather, tra$'ic, and the like. Although the generic play list 321 defines a
category or
type of information that is to be displayed, it does not speaify a content
source 322 of
. information in that category to be retrieved via the distribution channel
(here the
Internet 324). A processor in the building, in this embodiment a building
server 328,
uses a content mapping file 329 to define the actual sources of information
322
specified by the categories of information in the generic play list 321. The
processor in
the building that accesses the content mapping file is not limited to a
building server,
but may also include, for example, a sufficiently powerful computer system in
the
elevator or in the electronic display unit 310. Building owners may then
optionally add
building information from the Building Owner Manager (BO1VI) play list 331 so
that
-29-
CA 02458358 2004-03-15
the processor may generate the local building content play list 368 and
dishibute to the
elevator display units 310, for example via a building LAN 330.
Generic Play List
The generic play list 321 def nes the density of information to be displayed
in
the building elevators and provides a script used to develop the local
buildfn.g play list
3 68. As noted above, the elements in the generic play list 321 are categories
of
information. These categories define the type of information that will
eventnally fill
each element of the local play list 368. Unlike the content play lists in the
embodiments of the invention described above, the generic play list 321 does
not
provide any specific pointers to=files specifying sources of information, but
includes
only categories of information. T'hus, an elevator passenger will not see a
screen that
has the same name as a slot in the generic play list. An example of a generic
play list is
shown in Table IV below.
-30-
CA 02458358 2004-03-15
AMS,world uws
AMS,naHonal news
A1N51ocal riewe
AMZweatlur
A11C,national sparts
.4MS, local sports
AARjoaal restaurant
L75,nationat busfness
L1S,tr~
L75,weather
LTS,local busbess
PP4 local newa
PMalood evsnts
PI,AIocalõplaees
PMS traffic
PMS weather
SLP,world ews
SLP,na4io a1_newss
SLP,nationa( sports
TABLE TV
Much like the content play list shown in Fig. 6 above, the format of the
generic
play list 321 matches the day parts, or segments (AMS, LTS, PMS, SLP) with the
categories of information (local news, national news, traffic, weather, etc.)
to provide
maximum flexibiJity for the programming manager developing the network
schedule.
The generic play list foruiat described in Table N also aUows the progxemming
manager to develop generic play lists 323 that target speeific viewers. For
example, a
generic play list targeting buildings in the financial community may have a
greater
density of financial and market information thau a generic play list tha#
targets
buildings primarily populated by the medical or legal community. The advantage
of
the generie play list formst is that these targeted play lists can be applied
across
-31-
CA 02458358 2004-03-15
multiple markets. This is accomplished by the using the content mapping file
329 to
target the generic play list 323 to a specific market or building.
Content Mspping File
The content mapping file 329 defines the sources of infom-ation 322 specified
in the generic play list 321. The content raapping file 329 allows the
building
owner/manager to select a speeific source of information 322 within a category
of
information in the generic play list 321 to create a unique viewing
environment within
an individual building. For example, the content map enables a building A to
choose .
CNN as the world news source witbin the world news category of the generic
play list,
while a building B may choose Reuters as the world news source within that
cate.gory,
and a building C may select CNN, New York Times, and Reuters as their world
news
sources. This approach allows maximum flexibility to the building
owner/managbr
while requiring very little additional overhead at the production center 320.
An example of a format for the content mapping file is shown below in Table V.
<category>,<~rrnat7on path>,<re,fresh cycIe>
world news,ftp::/cnn.com/captivatenetworkhiews,4320
world riewa,f%p::/reuters.comlcaptivetenetwwk/worldnews,4320
weatherftp::/captivatenetwortcom/weather/boston,40
natJonal news,hUp::/barton.com/eaptivcrtenetwork/new8,1440
TABLE V
The first element of the content mapping file 329 shown in Table V,
<category>, identifies the category in the generic play list being mapped For
the
example above, the first line indicates a single mapping to the world news
category,
worldnews. However, any given category is not limited to a single niappfng,
and may
include multiple mappings. The second element, <information path>, identifies
the
information path, which is the mapping performed by the content mapping file
329.
During the content retrieval process described below, the building server 328
will use
the information path designation to make an FTP or HTTP request to retrieve an
actual
file or files for the data source in the specified category. The last
component of the
content mapping file 329, <refresh cycle>, signifies the assignment of date
information
-32-
CA 02458358 2004-03-15
to a particular fiIe or category. For example, a stale data time designation
defines, in
minutes, how often the data in a category needs to be refreshed before the
server marks
it as stale.
In the example of Table V the content mapping file 329 is illustrated as a
file,
but the content mapping file may actually not be a file at all. If a Windows
NT based
server is used, the content mapping file could aetually be a series of
registry keys
mauipulated by the building server service. The content mapping file may also
include
information in a text or configuration file.
In addition, the content mapping file concept may optionally be included in
the
generic play list. A sample file format for this case is as follows:-
Segment, category, information path, refresh cycle
However, the separation of these data enhances flexibility and siinplifies the
content
developmeict process.
In the present application, the content mapping file 329 will be assumed to be
a
file with the fozmat described above.
Content Retrieval
With the content mapping file 329, the building server 328 has the information
needed to retrieve the files necessary for building the local play list 368.
The generic
play list 321 sent from the production center 320 does not define any specific
files
referencing source information or where they are placed. Inste,ad, a slot in
the generic
play list 321 defines only the category of information. The building server
328 chooses
from a source directory 327 in the content mapping file 329 which file is
played in that
slot based on a continuously repeating series (round robin) pick of all the
available files
in the source directory 327 for that category.
The round robin selection is based on category file lists built and maintained
during the content retrieval process 400 iliustrated in Fig. 20. This content
retrieval
proeess includes three principal steps: directory enumeration, qualification,
and
retrieval.
In the directory enumeration step 400, the building server 328 (See Fig. 19)
identifies what files are located in a source directory 327 in the content
mapping file
-33-
CA 02458358 2004-03-15
329, and when the identified fiies were last modified. The building server 328
uses the
path information specified in the content mapping file 329 to sample the
contents of
each source directory 327. The file names and modification dates for each file
in the
source directory are extraoted and supplied to the qualifieation step 404.
In the qualification step 404, the building server 328 determines whether a
file
identified in the enucnezation step 402 is a candidate for retrieval.
Qualification for
retrieval requires that the identified file either: (1) does not currently
exist on the local
building server 328; or (2) if the identified file does exist on the laoal
building server
328, the identified file has a modification date that is earlier than the file
in the source
direetory 327.
Another important aspect ofthe qualification step 404 is the detenmination
whether the local play list needs to be re-generated. The local play list must
be
regenerated if the qualification process determines that the file being
retrieved is new.
Updates of an existing file do not require re-generation of the local play
list.
If the file qualifies for retrieval, the file is retrieved and downloaded in
the file
retrieval step 406, which is explained in detail below.
F31e Download, File Validation, and List'[Ipdate
The content retrieval process 406 includes a file download step 408, a file
validation step 410, and a list update cycle 412. The download step 408 brings
the
information files to the local building server 328 (See Fig. 19). The file
validation step
410 insures the integrity of the data brought to the buflding server 328. The
category
file list update process 412 manipulates the category file lists 413 to
reflect changes
associated with the downloaded clata.
File Download
Depending on the transfer protocol specified by the content mapping file 329,
the f le download is performed by either an F'tT fetch or an HTTP gct
operation. The
file is downloaded to a TEMP dixectory in an information file storage area 414
on the
building server 328. Once the transfor is complete, the file validation
p=ocess 410 can
be performed.
-34-
CA 02458358 2004-03-15
File Validation and Extraction
Each file traasferred during the file download step 408 is encapsulated within
a
protocol header. The protocol header represents a communication mechanism with
multiple levels of functionality designed to enhance progrannnzing
flexibility. The
protocol header may be designed to, for example, ensure data integrity,
provide
network security, and activate or.deactivate files at the server. An example
of a file
header format is shown below in Table VI.
Security ID
Number of Files
File List
Checksum
TABLE VI
The security identification (ID) in the protocol header of Table VI provides a
level of network security for file transfers. Referring to Fig. 21, following
an initiation
step 420, the fust step 422 in the validation cycle 410 is to verify the
security ID. The
security ID is calculated by performing an exclusive OR (XOR) fanetion with
the File
Size, Checksum, and a key value. The key value is defined by a registry key on
the
building server 329 and is common with the program that develops the protocol
header
of Table VI. The inability to validate a security ID for any given file
represents a
potentially serious security risk.
If the security ID cannot be validated, the building server 329 will send a
level
one error message in step 424, through logging, back to the network operations
center
(NOC) 325 (See Fig. 19) for immediate investigation. The next level of
validation is
performed at step 426 using the checksum. The program that develops the
protocol
header of Table 6 calculates the checksum. The building server 329 will
calculate its
own checksum based on the received file and verify the two values matcb. If
they do
not match, the building server will terminate the retrieval process and send a
level 2
error message in step 428, through logging, back to the NOC 325 for
investigation.
-35-
CA 02458358 2004-03-15
If the f le is validated, the fil' e information is extracted (step 430) and
plaeed in a
FRAMES directory in the building server 329 (step 432). Once atl files are
extraeted
(step 434), the validation cycle ends (step 436).
The protocol header of Table 6 may also allow multiple files to be placed
within
the protocol. This arrangement provides tremendous flexibility by allowing the
building server 329 to oapture multiple sources of information and develop the
local
play list 368 from the generic play list 321 (See Fig. 19). Unforlunately, the
placement
of the multiple retrieved files is random, meaning one file is not guaranteed
to appear
next to another. The multi-file protocol allows retrieved files to be placed
next to eaoh
other in the play list. The protocol operates as shown in Table VII:
If Number of Retrieved Files is greater than 1, then
Extract each file individually and mark them as a bundle
else
If Number of Retrieved Files is equal to 1
Extract the file and mark it as a single entry
End
TABLE vII
While not exemplified in the protocol header discussed above, the protocol
header may be extended to include activation and deactivation times for each
file.
Once a file is transmitted to the server, the activation/deactivation elements
in the
beader allow the building processor to control the start and end times for
eacb file so
that files in the same information category may run at different times during
the day.
This expansion of the role of the building processar provides great
flexa'bility and
simplified file management at the network operations center 325.
Category Ffle List Update
Following the source check in step 410, the oategory $le lists 413 are updated
in
step 412. The category file lists 413 hold pointers to the files tttiat make
up eaeh content
category. Instead of subdividing the direatory struature in the building
server 329 into
-36-
CA 02458358 2004-03-15
separate content categories, it is far more efficient and useful to keep the
file structure
flat and use lists to manage the data. The strucfire of the category file
lists is shown
below in Table VIII.
Categury
File
Modification Date
File Present Flag
Bundle flag
Stale flag
TABLE VIII
In the structure in Table VIIi, the category maps to the category element in
the
content mapping file 329 (See Fig. 20 and Table V). The file field represents
the file
names extracted from the source directories. The last modification date sad
stale flag
are important for the stale data recovery algoritbm, which is descn'bed below.
The file
present flag indicates whether the file was still present in the source
directory during
the last content retrieval cycle. This is important for the cleanup process.
Finally, the,
bundle flag is used to force files to be placed in succession within tb,e
local play lisk
The bundle flag is actually an alphanumeric value having the following
possible states
shown in Table IX:
Off-Thefileisnotapart ofabundle
Start - This is the first file in a bundle
Element - This is one of the middle files in the bundle
End - This is the last fle in the bundle
TABLE TX
As with the protocol header discussed above, the category file list
definitions
may also be expanded to include an activation or deactivation time to transfer
file ran
-37-
CA 02458358 2004-03-15
time control fully or partially from the network operations center to the
building
processor. This enhances programiming flexi'bility.
The process 412 (See Fig. 20) for updating the category file lists 413
consists of
category creation, file insertion, and $le maintenanee steps.
Category Creation and Removal
A category file list must exist for each category defined in the content
mapping
file 329. Therefore, refenang to Fig. 22, the first element 440 in the update
process 412
is the category creation and removal procedure. During the category creation
and
removal procedure 440, the building server 328 will interrogate the content
mapping
file 329 and add any category file lists 413 that are not present or delete
any category
fiie lists 413 that are present, but not defined in the content mapping file
329.
File Insertion
As the retrieval process 406 enumerates each source directory and qualifies
the
files, any fite that is not present on the building server 328 must be
retrieved and
validated and then placed in a category file list 413. The retrieval and
validation
process considers two elements: (1) does the file exist in the FRAMES
directory on the
server 328; and, (2) is it in the category file list 413. Tf the file exists
in the FRAMES
directory on the server 328, it will not be retrieved. However, ifthe file is
not in the
category file list 413 it must be inserted. Specifically, if the file is not
in the FRAMES
directory on the server 328, the file will be retrieved, validated and then
inserted into
the category file list in step 442. The category file lists are ring buffers,
therefore, the
new file is added to the end of the list. The building server wi11 then
captare the
modification date, set the present flag, and mark the bundle flag
appropriately.
File Maintenance
During the retrieval and qualification steps 406, 410, if it is determined
that a
file has been modified or is imchanged, then a category file list maintenance
event 444
must take place. The maintenance activity 444 considers the elements of the
category
file list: the modification date, the stale flag, and the file present flag.
These f lags are
used by the cleanup and recovery functions at step 450, which is described
below.
Each time a file is modified, the building server 328 must update the
modification date,
-38-
CA 02458358 2004-03-15
cle.ar the staleflag, and tnark the file present flag to indicate the file is
still valid. For
unchanged files, the building server 328 will simply mark the file as present.
Cleanup and Recovery
Cleanup and recovery are important elements of the content management
process. Referring again to Fig. 20, the cleanup and recovery process 450
insures that
files, which are no longer active in the play list, are removed from the
FRAMES
directory in the building server 328. This keeps the FRAMES directory from
growing
out of control during the course of weeks and months of operation.
The cleanup portion of the process 450 requires examination of the file
present
flag for every Ele in each category file list. If the file is not set, the
file is deleted from
the frames directory and the category file list, and the local play list is
rebuilt at step
452. If the file present flag is set, the flag is removed in preparation for
the next
content retrieval cycle.
The recovery portion of the step 450 is used to manage stale data. Each
category of information has a refresh cycle (See Table 5 above). Stale data
occurs
when the modification date for a file exceeds the refresh rate for that
category.
Following the content retrieval and cleanup steps 406, 410, recovery is
performed on
each file in the category file lists. If a file is found to be stale, the
building server 328
will set the stale flag for the given file, and tebuild the local play list at
step 452. The
stale flag is reviewed during the local play list development process to
determine
whether the file is included in the local play list. The building server 328
may also
generate a level 2 error, through logging,to alert the NOC of the situation
(not shown
in Fig. 20). Once the file is updated and meets the refiresh requirements for
the
category, it can again be placed in the local play list. The power of this
stale data
recovery algorithm is that it insures the local play list can self heal if the
building server
3281oses communication with the Internet.
Once the cleanup and recovery step 450 has concluded, the content retrieval
process ends at step 452.
Local Play List Development
Referring to Fig. 23, local play list development 500 is the process in which
the
generic play list is made into the building specific local play list. Marnying
the
-39-
CA 02458358 2004-03-15
category file lists with the generic play list, and then incorporating screen
center
messages from the building play list performs the transformation.
There are a number of triggering events 502 that can initiate the development
of
the local play list 368. Examples include addition of a content file, a new
building play
list for screen center messages, a new generic play list, content file
removal, and stale
file removal. Once the local play list development process 500 is triggered it
perfornas
a two step operation. First, the generic play list is converted to a content
play list via
the content slot assignment process 504. The content play list is then
transformed into
the local play list by the screen center slot assignment fim:ction 506.
Content Slot Assignment
Content slots are assigned in step 504 by expanding the generic play list 321
to
fit the entire 24 hour day and then placing content by category in a round
robin fashion.
Referring to Fig. 24, this is done in two passes to create the first pass of
the content
play list. Fi.rst, the generic play list 321 is expanded at step 505. This
expansion rotates
the category assignments in the category file lists 413 into a segmented 24-
hour period
with an AM segment, an LT segment, and a PM segment. Second, the category
defnitions within the generic play list 321 are simply repeated in step 507,
on a per-
segment basis, to fill each 10-second time slot within the content play list.
Once the
generic play list is expanded to the full day, the fnst pass of the content
play list 510 is
complete and the process of inserting the content files can be performed.
Replacing the generic content assignments with real content file names is done
using the category file lists 413. The fill process step is performed in a
round robin
fashion using the algorithm shown in Table X below.
-40-
..,~,~._-___.._____~_a,~....~.~...~~,~-,,,
CA 02458358 2004-03-15
Start at time 00: 00: 00 in content play list
Step 1: Locate categoryfile llst for category speci, fled in content play list
IF category file list is empty
Remove slot in content play list
Else
IFstale jlag not set for currentfile in category file list
Replace category name in content play lfst
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
Endt; f
Else
Find the nextfile enby in the list that is not marked as stale and
insert thisfile name into content play list. If all, f'sles are marked stale
in the
category, then remove the category from content play
Ifst.
Endif
Endrf
If not end of content play list
Goto to next entry tn content plrry list and repeat step 1
Endif
TABLE X
If activation and deactivation times are used, the algorithm in Table X above
would be modified to include a test on each file to verify that the current
time faUs
within the activation and deactivation times of the candidate files within the
category
file list.
The algorithm desoribed in Table X will create the content play Iist 510. This
play list is then modified in the sereen center slot assignment step 506 to
include the
building owner-manager {BUM) playliat 512 messages to produce the local
building
play list 368. Using the local building play list, video information is
distributed at step
514 by the building server via the building LAN 330 to the elevator display
units 310.
Still further embodiments are within the claims.
-41-
