Background of the Invention
This invention relates to providing information in an elevator
and other such personnel transport vehicles.
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 structures is the elevator, particularly in buildings having
Visual information provided in an elevator is generally
limited to floor information and passenger instructions in the event of an emergency
or assistance is required. An elevator may also include a static placard posting
the day's present and their locations.
An information distribution system for use in an elevator
is already known for example from W-A-9840816.
Summary of the Invention
The invention features an elevator display system and method
as defined in claims 1 and 11 respectively.
Also described herein is 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
The system includes an elevator display unit 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 one 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 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.
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 complete strangers. Elevator passengers often seek ways to avoid making
eye contact with fellow passengers during what feels like an endless, unnerving
duration of time. Passengers no longer need to stare aimlessly at the floor or ceiling,
but have an informative media resource to watch.
Occupants of high-rise office buildings are typically business
people with understood interests and buying tendencies. These 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 demographics 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 interest. 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 aspects of the invention may include
one or more of the following features. The local server receives the scheduling
information from the production server over a data communication network (e.g.,
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 characterization data, as well as
the addresses from where the general and commercial information can be retrieved
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 associated with the system.
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 information retrieved from the production
The local area network includes an Ethernet path for connection
to the elevator display unit. The elevator display unit further 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
For the BOM interface, the video information includes a
text message (e.g., in HTML 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
Internet, a dial-up modem, or a local area network. The play list is a building
operations play list, with the video information and scheduling information 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 generates 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.
Brief Description of the 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 portion of the information
distribution system of Fig. 1.
- 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 scheduler module of the production
- Fig. 7 illustrates the format of a play list.
- Fig. 8 is a functional block diagram of a building server of the building subsystem
portion of Fig. 3.
- Fig. 9 is a functional 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 architecture.
- 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
- Fig. 14 illustrates the format 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 illustrating the operation of the parsing function
of the BOM interface.
- Fig. 17 illustrates the format of a local building play list.
- Fig. 18 is a functional block diagram of the display server architecture.
Referring to Fig. 1, an information distribution system
1 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 important tasks described below-creates and distributes
elevator display data by merging advertising with the "real time" general information.
The general information is considered "real time" because the information is relatively
current (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 Internet 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 advertising
information to each elevator display unit 10 of associated elevators 12 through
a local area network (LAN) 30.
Information distribution system 1 utilizes a concept called
"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 occupants 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 shown encircled by larger geographical regions 8a-8b (e.g., New England). Geography
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 partition demographics by both geography and business
segment provides tremendous value to 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 advertisement
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 which time slots are available include: the
target demographic (e.g., financial community in northeast United States), the number
of advertisement impressions (i.e., the number of times an advertisement is viewed)
purchased, the advertisement start and end dates (e.g., start and end of a two week
period), prime time requirements (i.e., prime time morning), the advertisement format
(280 x 90 animated GIF file) and advertisement locator (where GIF file is located).
Once the advertisement time slots are 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 a.m. and 15 seconds simultaneously with a local news article
in one building play list while running the same 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 Internet 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 play list 68, assembles
displays at the times indicated by the list and distributes them to the individual
elevators 12. Thus, 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 (EDU) 10 receives
and processes data provided by building 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, 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 interacts with local area network 30 and is configured
by computer 34 during system startup. Display data being broadcast downstream from
building server 28 to elevator display units 10 represents the majority of the network
traffic. In the downstream direction (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 downstream direction, however this
is negligible. Network interface card 36 routes display data directly to display
13. Control information will generate an interrupt to computer 34 to request service.
In the upstream direction (from elevator display unit 10 to building server 28),
network traffic includes occupancy information and system monitoring data. All upstream
data is generated by computer 34 and passes to network interface card 36 for transmission.
Data from building 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 discussed, 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
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 throughout 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
statistical traffic information for each building. This data is critical to the
scheduling and advertisement sales process.
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 characteristics of the sensors
define whether the passenger is entering or departing the elevator. Occupancy detector
42 maintains an occupancy 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, exhibit story excerpts
50, one or more pictures 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. Simultaneously, 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 connectivity provided via Internet 24.
Another important function of production center 20 is management
and maintenance 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 section 48.
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, "real 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
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 (banking, 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.
<City, State ZIP>
<City, State ZIP>
<number of occupants>
Number of elevator
Number of lobby displays
From: <time of day> EST
To: <time of day> EST
From: <time of day> EST
To: <time of day> EST
Average elevator occupancy
Real Time Content
<List of Content>
The results of the characterization process are stored
in production center 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-to-one with the characterization
categories for the buildings, shown in Table I therefore 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" information must adhere to specific
formats which 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
locations for each content segment within that format. The format determines the
number of segments for each entry. Locations are described using Universal Resource
Locators (URLs). The database parameters maintained for each "real time" content
source are shown below in Table II below.
"real time" Content
<City, State ZIP>
Content Segment 1
Content Segment 2
Content Segment N
Advertising content data consists of two components. The
first component defines when the advertisement must be run, the locations it is
run, and for how long it runs. The second component describes where the advertisement
is retrieved from and how it is inserted into the display. Consider the run parameters
first. Advertisers will purchase advertising time on the system in units of Cost
Per Thousand Impressions (CPM). Advertisers may further target specific demographics
by requesting the advertising be distributed nationally, regionally, locally, or
at a specific business segment. In addition, an advertisement 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 actual
advertising content and how it is integrated into the system and displayed. The
parameters that describe this information are the content parameters which include
the advertising locator and format type. The database parameters maintained for
each Advertising content source are shown below in Table III.
<City, State ZIP>
Prime Time Requirement
<% of advertisement run time>
<start time - end time>
Scheduling module 62 has the primary function of creating
building play lists by generating both advertising and "real-time" 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 advertisements 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 information through
a phone interview, an application form, or a third party representative. Initial
list 72 is further pruned in a second parsing step (102) using secondary criteria,
such as advertisement start/finish dates, prime time requirements, delivery times,
and impression parameters. The result of these pairing steps is an advertisement
building-specific list 68 indicating advertisements and time intervals for when
those advertisements could potentially be displayed.
Next, scheduler module 62 considers "real time" content
preferences for each building as set forth by building characterization data (see
Table I) associated with that building (104). Using this information, 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 merging 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 accompany it. "Real time" content
is presented at fixed intervals (e.g., every 30 seconds). As a result, scheduler
module 62 will place the "real time" content first.
Advertising placement is also subject to distribution and
occupancy considerations. The commuting patterns of the network audience is always
an important distribution consideration in effectively distributing a particular
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.
Advertisements can 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 advertisements. This could be a potentially unattractive
annoyance for elevator passengers. To eliminate this possible annoyance, scheduler
module 62 lengthens the display period for each advertisement to make the transitions
Once advertising and "real time" content has been defined
for each time slot, scheduler module 62 creates the display. The format of the advertising
and "real time" content is critical because it determines which of a variety of
templates is 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 frame type in order to merge them.
The number 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 construct building play list 68.
Referring to Fig. 7, the format of a building play list
68 used to manage the assembly of both "real 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 defines the time as well as frame type used
for the advertising content.
Referring 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.
Unfortunately, Internet 24 also represents a path for potential system corruption.
In consideration of this risk, system 1 is designed to require that each building
server 28 request information from production center 20, rather than having production
center 20 broadcast data. Building 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 further protect the information from
Billing 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 better distribute the advertising and content. A
billing and database maintenance 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 numbers. From this process, the actual
number of impressions can be calculated for each advertisement. The billing operation
will 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 advertisement yet to be delivered. That is, the
number of "Undelivered Impressions" (see Table III) 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
maintenance 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 important parameters used by scheduling
module 62 in the scheduling process.
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 "real time" content and transport the advertising information. "Real
time" output from interface 90 is deposited into a local "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 latency problems which would realistically
prohibit creating high performance display presentations including, for example,
animation, streaming video, 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 performed by an
Display Generator/LAN (DGLAN) Interface 96 which interprets building play list 68
and assembles the specified content. The result is an HTML 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 manages the interaction
with Internet 24. Interaction with the wide area network (WAN) is generally initiated
from the buildings in order to increase security within the system. PCWAN interface
90 includes a play list parser 110, which performs a translation to create local
references for the advertising and "real time" content. The translation is required
because all 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 accumulation process must take place to create
this local store. Parser 110 initiates advertisement accumulation when it determines
the play list contains an advertisement not currently available in the advertisement
content database. The accumulator function will interface with the WAN to retrieve
the missing content and store it in the database. The local URL for the advertisement
is returned, which the parser writes to the local building play list. A similar
operation takes place for "real time" content. In this case however, updates are
performed 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 control 109 to retrieve the "real time" content. The content is stored
based on the locator provided by parser 110.
Display Generator/LAN Interface
Referring to Fig. 10, Display Generator/LAN (DGLAN) 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 DGLAN Interface
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 Interface 96 includes a display format
parser 120 and a display assembler 122. Display format parser 120 uses Hyper Text
Markup Language (HTML) to build the framework for the display. HTML is used extensively
on Internet 24 to develop display information and is easily understood by modern
browser technology. Display format parser 120 generates the HTML 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 HTML file, specifying the physical attributes of the display. These attributes
include the absolute position, size, and definition of each content segment. Missing
from the template are the pointers to these content segments. Content segment pointers
are generated by display assembler 122.
Display assembler 122 is used in the final 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 will 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 HTML 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 HTML 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 host/display 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 Microsoft Corporation?). Browser 136,
within the operating system (e.g., Microsoft Windows NT a product of Microsoft Corporation?)
used by building server 28, interfaces with 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 communication layer. The encapsulated data is passed to
the network interface and transmitted through network switch 30 (Fig. 3) to the
Further embodiments are supported by the following claims.
For example, the distribution channel used by information distribution system 1
described above is the Internet 24. The Internet, or "web" provides a growing and
existing infrastructure for obtaining information and establishing communication
between computers. However, information distribution system 1 can also be implemented
using other communication channels including cable modem, satellite, XDSL.
Twisted pair lines 38, discussed above in conjunction with
Fig. 4, can be replaced with other forms of transport media including fiber optic,
coaxial lines, RF transmission). 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 Manager (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 1 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 (BOMGUI) 202 which communicate with one or more
building subsystems 204 via distribution channel 24. 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 channel 24, as shown
in Fig. 1 was represented, for example, by the Internet. In this case, distribution
channel 24 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
building. Messages generated using a BOMGUI 200 are merged at the building server
without interaction from production center 20. Thus, building managers 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:
BOM User Interface (BOMGUI)
- * Time critical messages including fire alarm testing, parking garage closures,
changes to building hours, building-specific traffic information;
- * Special Events such as holiday events, building activities;
- * New building features/services including health club, cafeteria facilities,
parking, coffee shop, florist;
- * Public Address/Emergency messages including instructions for stuck elevator
passengers, storm warnings, fire information; and
- * Advertising messages such as announcements for available space, description
of the management organization and their capabilities.
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 interconnection 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 <!-message 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 which allow for tabs, carriage returns, and spaces,
along with plain text information.
BOMGUI 202 is also able to import already completed html
files. This enables building owners and managers the ability to create special announcements
and display them on the information system without using the template structure
discussed immediately above.
The message creation process requires that each of the
fields of the template be populated. Within BOMGUI 202 this is accomplished in one
of two ways. The first way uses a message creation wizard, a user-friendly program
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 pattern 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 system. BOMGUI 202 converts the information from template
212 into a file, capable of being read and displayed on the display units of the
As will be described below, BOMGUI 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 HTML output file with the name <message 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 BOMGUI 202.
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 distributed throughout the week/month/year.
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 determine 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. Thus, BOM play list 220 defines
time periods 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 created
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 is created using BOMGUI 220 and is generated
by individually stepping through each HTML 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 transformed
directly into the BOM play list format. For example, the sample BOM play list shown
in Fig. 14 indicates that bom_message1.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.
BOM interface 200 utilizes a BOM play list parser to parse
BOM play list 220 in a manner similar to the manner used by play list parser 110
to parse building play list 68, as described above in conjunction with Fig. 9. Specifically,
play list parser 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 useful, 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 production center/WAN interface 90 described above in conjunction with Fig.
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 URLs 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 list
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).
In other applications, BOM interface 200 is used independently
by building managers as a means for communicating 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 the BOM play list has been updated 232 and
derives a local building play list 114 solely from BOM play list 220.
The goal of the interleave function is to insert a programmed
number of building manager messages every minute during the designated time period
using a round robin priority scheme. The number of messages inserted per minute
can be programmed from 0 to all available slots. Of course, prior to inserting a
message parser 222 will verify that the current date and time fall within the start/stop
dates and time period parameters of the message.
An example will help illustrate the manner in which parser
222 functions. Assume a building manager has created and downloaded the BOM Play
List shown in Fig. 14, via BOMGUI (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_message1.htm and bom_message2.htm are
interleaved into the PC building play list 68. Also note that these messages alternate
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
will appear every minute.
Unlike the Production Center path for content assembly
described above in conjunction 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, BOMGUI 202 will deposit message files
into a BOM Message Store 240. As display assembler 122 interprets the local building
play list 114 it will 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.
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 functionality 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 Interface 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.
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. BOMGUI 202 performs a username and password
check procedure prior to invoking the user interface. The passwords and usernames
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 functions not associated with the system. This three
phased approach should make it very difficult for any unauthorized access to the
system to occur.
Still further embodiments are within the claims.