CA2266598C - Multimedia information transmission and distribution system - Google Patents

Abstract

A communication system having programmable, addressable receivers that receive, store, process, and send digital and conventional video, audio and control signals for use in, among other things, a cable video network (9).
Conventional audio and composite video and digital data signals are assembled into a single transmission by an automated production system. The transmission is delivered to the addressable receivers where the audio and video signals and some portion of the data may be selected and processed for re-transmission (114, 116, 118, 120, 98). The receivers may be addressed individually, in units or in groups for the purpose of receiving information on the basis of one or more pre-selected criteria.

Description

CA 02266~98 1999-03-19 MULTIMEDIA INFORMATXON TRANSMISSION
AND DISTRIBUTIOI~ SYSTEM

Background of th~ Invention This invention relates to a system for the tr,ln.~mi~.~ion of audio and combined video, ~ data, multimedia progr~mming and control signals to remote receiving locations for distribution under the command of the control signals. Transmission of audio and video signals to local receiving stations for immediate use, re-tr~n~mi~.~ion or recordation for later tr~ncmi~sion is a well-established practice, particularly in connection with distribution of television progr~mming by various television networks and cable systems. Utilization of data to generate characters which are displayed on a video screen over a single color background or another video signal background is also established practice.
These practices have been combined with new technologies to create for viewers what appears to be continuous progr~mming, but is reall y a sophisticated stream of many types of segments, or products, origin~ting from different places. For instance, U.S. Patent No.
4,725,886 to Galumbeck and related U.S. Patent Nos. 4,916,539 to Galumbeck and 5,140,419 to Galumbeck, which are incorporated herein in their entireties by this reference, disclose current communications systems l~tili7in~ novel hardware and software configurations to transmit conventional video and audio program material together with data and control comm~n~ within the constraints of conventional television signal specifications to remote signal processors or receivers within the system. The remote signal processors or receivers receive the entire tr~3n~mi~.~ion and process it in a predetermined manner such that the data and the conventional video and audio signals may be utilized at the remote receivers, under network control, particularly for tr~n~mi~sion on local cable television systems.
This technology may be applied to any system for distributing information and is not limited to weather related information; however, the application of this technology may best be understood by analyzing the operation of an existing system such as The Weather Channel (TWC). TWC is an automated system for distributing and delivering weather related information, or "products" over broad areas.

CA 02266~98 1999-03-19 The main classes of current TWC information are local weather segments, nationalweather segments and advertisements. All are presented in different ways and at different times, creating a multiplicity of products. These products vary in sophistication. For example, a product may be a relatively simple banner of text running across the bottom of a 5 screen; a nationwide weather presentation by an On-Carnera Meteorologist (OCM) with the help of satellite animation; or a multiframe radar map overlay sequences provided in data form to the cable headend and processed there for display to local viewers overlaid on a geographic map to show, for instance, movement of a storm system.
As illustrated in FIG. 1, at any time during the TWC progr~mminE day, there are two 10 types of information which must be prepared at the TWC central facility and transmitted to the cable company for presentation of TWC progr~mming: the national transmission 10, which is seen by all cable subscribers; and the local tr~n.smi~.sion 16, which is seen by viewers in selected corresponding cable markets. National tr~nsmi.s.sion 10 is transmitted as a traditional audio/visual (A/V) signal origin~ting at TWC headquarters 12 in Atlanta, Georgia.
15 The same signal carries (via subcarrier) local tr~n.smicsion 16, which is transmitted to the cable operator as data representing local weather information7 advertising information and cornmands that instruct the cable headend, or receiving unit 14, on how to display the information. Receiving unit 14 periodically produces its own progr~mming using the data sent by TWC. Receiving unit 14 passes national tr~nsmission 10 through during its time slot;
20 however, during the time for the local tr~nsmi~sion 16, locally-created graphics and progr~mming (generated with data received from TWC) from receiving unit 14 are interposed.
The conventional TWC distribution system for local weather data can be thought of generally as a one-way client/server architecture, where raw data and AfV are sent to 25 receiving unit 14. Receiving unit 14 then assembles the data for display (local tr~nsmission 16) or passes through the A/V signal (national tr~n.smi~.sion 10), depending on the instructions sent by TWC headquarters 12.
As illustrated in FIG. 2, three sources of information are drawn upon to create national tr~nsmi.s~sion 10 and local transmission 16: weather data 18, affiliate database 20, and CA 02266~98 1999-03-19 programming/scheduling 22. These sources are drawn upon by many subsystems to form the final progr~mming seen by the cable subscriber.
The first source of information is data and graphics accumulated for weather forecasts from external sources and is collected in a system c:alled the meteorology system ~4, 5 illustrated in FIG. 3. Not all information is passed from Meteorology system 24.
Meteorology system 24 filters information as dictated by a local database called the meteorology system interest list.
Weather data 18 is collected by the National Weather Service (NWS) 26. NWS 26 has weather collection sites throughout the United '~tates at airports, military bases, and other 10 selected sites. These sites report each hour during their scheduled reporting time, which varies from six to twenty-four hours depending on requirements. Some sites are automated, while others are m~n~ l, with information being collected and presented either by machine or by personnel at the site.
A third party provider 28, disseminates that information to TWC in tabular and 15 narrative form. Tabular data 30 is presented in fixed-length records with fixed-length fields or specific weather conditions. Character fields are typically leftjustified and either maximum length or null-terminated. Numeric field.s are either binary or rightjustified with leading spaces. I~or example:
Location Temp Description Etc.
ATL 75 SUNNY ETC.

20 This information arrives at any time and typically includes information such as the t~llpe.dlllre, wind speed, humidity and other weather related information for a particular location.
Other information provided by the weather r eporting agencies includes weather warnings and advisories, which are provided as narrative data 32 in free-form text as variable 25 length strings. Radar maps 34 are provided by the National Oceanic and Atmospheric Administration (NOAA) in run-length encoded forrn and are converted into a composite and sent to the field every fifteen minutes. Backup system 36 is provided in the event data cannot be received from TWC.

W O 98/15122 PCT~US97/17412 Referring to FIG.2, to correctly route the information, ~ffili~te database 20 stores the location and address of the cable operator (or the cable operator's equipment in cases where there may be multiple headends installed). Affiliate database 20 contains information needed to transmit weather data to cable operators. Much of the information 5 focuses on reconciling a cable operator's zip code with their geographical longitude and latitude. This allows the information to be addressed to an appropriate location, so that, for instance, weather information relevant to Miami will be directed to the Miami receiving unit.
This also allows tags and copy splits to be directed to the desired location. Tags are ~ billboards appearing at the end of a commercial. They display the name and address of the 10 local operator of a national company. For example, a Michelin Tire commercial could list the names of the local dealers. A copy split could include different commercials for different areas of the country.
Progr~mmin~ 22 includes information, advertisements, program direction, and camera assignments. Production is fully automated: cameras, sets, commercials, and weather data are 15 presented on a predeterrnined schedule. OCM segm~nt.~ and other live action A/V are produced in an automated studio where the operation of cameras and other production equipment are controlled by an automated production engine 38. Production engine 38 creates and coordinates the live A/V trancmi.~sion and command data feed.
FIG.4 illustrates how inforrnation for this progr~mminE is directed into production engine 3~. Entry of progr~mming information to the system begins with the sale of comrnercial advertisements and sponsorships of progr~mming. Sales proposal system 40 identifies and tracks potential customers. Also, sales are proposed and secured with contracts. Commercial contracts are entered into traffic system 42 by department personnel.
Traffic system 42 classifies the terms of the contract. An advertisement schedule is then transferred to traffic system 42. Traffic system 42 also contains the progr~mming schedule for TWC and, as such, the first draft for a progr~mming day is developed there. In addition, traffic system 42is the main scheduler, where the script is written for the progr~mminE day, including advertisements and schedules for national 10 and local 16 transmissions. A video tape of the commercial is loaded into a large videotape tower carousel 44,such as an Odetics.
30 The stored commercials are then played according to a schedule log.

CA 02266~98 1999-03-19 WO 98/15122 PCTtUS97117412 The Souree Book program on eomputer 46 converts the commercial schedule from traffic system 42 into the sehedule log. It eoordinates the sehedule with the eomputer commands to be sent to all equipment involved in the tr~n~mi~.cion period. Once compiled, this file is transferred from computer 46 to production engine 38 and tape earousel 44.
5 Teehnical Directors at the produetion engine Edit Station perform any necessary real-time modifieations.
The Souree Book program produces OCM Guide Sheets 48. It produces hard copies of the schedule log speeifieally for the OCMs. Th.is log then beeomes the produetion seript for live weather transmissions.
Referring to FIG. 2, produetion engine 38 also direets eommand data 50 to host 52.
Weather data 18 and affiliate data 21 are eombined with eommand data 50 to ereate the final eommand tr~n~mi~.sion 53 (provided by host 52), and a live A/V tr~n~mi~sion 54 is ereated simultaneously. Next, eommand tr~3n.~mi.~sion 53 and the live trz~n.cmic~ion 54 are combined into one tr~n~mi.~ion 56. Tr~n~mission 56 is bearned via satellite to most of the cable 15 operators in the US. Tr~n.~mi.csion 56 is eaptured by a satellite dish, deerypted by eonventional decryption means such as General Instruments Videocypher II equipment and broken into its component parts--eommand data a.nd video---and then sent to reeeiving unit 14.
Reeeiving unit 14 uses the inforrnation earried in the signal to produee the 20 presentation seen by viewers and to pass-through audio and video. To aceomplish this task, reeeiving unit 14 reeeives the national tr~n.cmi.s~ion 10 and a stream of eomm~n~l advertising and weather data. W'hen reeeiving unit 14 is instr leted to pass-through national tr:~ncmi.~ion 10, it direets the video signal~ i.e., the national tr~n~mic.~ion, from the TWC to the eable operator's network, where it is seen by viewers. When instrueted to show the loeal 25 tr~n~mis.sion 16, reeeiving unit 10 combines data and onboard graphies to produce local tr~n~mi.~ion 16. The pass-through of national tr~n~mic.sion 10 is then interrupted and loeal tr~n.~mi.~ion 16 is forwarded to the eable operator's network, where it is seen by viewers.
Reeeiving unit 14 is capable of building graphies by running a eustom scripting language. It ean perforrn eolor shifts and simple radar map anirnations. The end result is that the cable 30 subseriber reeeives prograrns formed of segments of national 10 and loeal 16 tran~mis~ions.

CA 02266~98 1999-03-19 Rel'erring to FIG. 5, one of the most important aspects of the current TWC system is the relationship between receiving unit 14 and host 52. Host 52 communicates with receiving unit 14 by sending commands. The commands either configure receiving units 14 or prepare and execute local tr~n~mis.~ion 16 (including programming such as advertising inf'ormation).
There are two lines of communications between production engine 38 and host 52.
First, there is a data communications line 58 between host 52 and production engine 38. As previously mentioned, production engine 38 produces the program day's schedule in its final form. Data line 58 sends an event list and ensures that production engine 38 and host 52 are synchronized. The second form of communications is the Take Line. This is a binary switch 10 (5 volts = on, -5 volts = off) that instructs host 52 to initiate the next event.
In general, local weather is transmitted several times each hour; however~ weather warnings or remote reports may be scheduled in an ad-hoc manner. Thus, the TWC system must be able to respond accordingly. In order to produce the desired progran ming, receiving units 14 typically respond to at least three command sets: cyclic, load and run. The task with 15 the lowest priority is the cyclic command, which runs during each hour and sends all the configuration data needed to re-initialize receiving units 14. The cyclic command set is intended to refresh a receiving unit 14 that has lost power or been replaced. The cyclic command set is important because no current receiving unit 14 has any significant amount of permanent storage capability. The only storage provided consists of random access memory 20 (RAM), backed up by a battery power supply. If the batteries fail, the configuration information is lost.
Another important command sent to receiving units 14 is the load command set. The load command set warns receiving units 14 of an impending local trAnsmicsion 16. This allows time for loading the presentation into memory to elimin~te delays in the transition 25 from national 16 to local 10 tr~ncmi~ions.
After the load command set has been executed, the run command set is sent. This causes receiving units 14 to cut offnational tr~n~mi~ion 10 and begin local transmission 16.
Three components of the run command set are: sensors, commercials and tags. The sensor component instructs those receiving units 14 that have weather sensing e~uipment attached to 30 read those devices. The commercial component allows receiving units 14 to run local CA 02266~98 1999-03-19 WO 98/15122 ~CT/US97/17412 commercials. Upon receiving the run command, receiving units 14 signal local video equipment to run and turn off national transmission 10. The tag command instructs the receiving units 14 to produce a text output over or after a national commercial, thereby advertising local outlets.
Of course, these systems can be used to create all forms of programming and are not limited to weather-related information. For instance, educational, sports, entertainrnent, business, product marketing and other forms of iniormation can be distributed in this manner.
Furthermore, this system may be used to distribute information over media other than televisions, for instance, home computers. Nonetheless, these systems have several 10 limitations which limit the quality and character oi'progr~mming that may be displayed to the viewer and the flexibility with which product can be distributed on a national and local level.
In particular, bandwidth availability may limit the volume of information which may be transmitted to the various receiving units. Although compression technology has significantly expanded the amount of information lhat may be transmitted over a given 15 channel, consumer demand for more information and increasing sophistication of multimedia products has caused even greater growth in the total volume of inforrnation which must be transmitted to create the ultimate program received by the viewer. One solution is simply to increase the number of channels used to transmit the information; however, rapid expansion in the number of content providers has limited the availability of additional channels (as well 20 as increasing the cost of existing charmels). This problem affects not only conventional cornmunications channels, such as satellite tr~n~mi~.sion, but also more recently available channels, such as the Internet. Thus, it is desirable to limit the bandwidth required to transmit a given set of inforrnation by providing a system which coordinates the tr~ncmi.csion of information in its various forms, i.e., analog and di,gital video and audio, data, etc. to 25 maximize the utilization of the available channels a~nd therefor the through-put.
The hierarchical addressing system as taught in the Galumbeck patents can limit the flexibility of product distribution over discrete areas. This is because the current scheme requires that a separate message be sent to each receiving unit unless the message is common to all of the receiving units within a given tier of the hierarchy. For example, a single 30 message cannot be sent to only the receiving units in Miami and Los Angeles unless it is CA 02266~98 1999-03-19 desired that all other receiving units within the same tier display that same message. If the message is only intended for Miami and Los Angeles, two separate messages must be sent.
Due to the limited availability of bandwidth and tr~ncmi.csion channels, the total number of messages being sent over a given period may be limited, often making it difficult or 5 impossible to send individual messages to discrete receiving units.
Nonetheless, it may be desirable to send messages to individual receiving units based on non-hierarchical criteria. The current hierarchical structure is based on geographical boundaries, which is consistent with the needs of displaying weather data; however, other criteria for distributing information may be envisioned. For instance, it may be desirable to 10 target distribution based on demographics for advertising purposes, e.g., locations with high proportions of retirees or males 18-24, etc. Thus, it would be desirable to provide a system for sending a single message addressed to multiple receiving units on a non-hierarchical basis without necessarily incorporating other, undesired receiving units.
The current system distinctly segregates A/V tr~n.cmission and data tr~ncmissions.
15 The data tr~n.cmi~sions are handled by the product server/host/receiving unit system (the "command data system") while the A/V tr~n.cmic.cions are handled by the production system.
production engine 38 coordinates both signals to create the final sequence of products displayed to the viewer. It may be desirable to provide A/V data which can be displayed on the local rather than the national level; however, the current receiving unit does not have the 20 capability of reeording and replaying such large blocks of data. Furthermore, the command data system is not capable of producing and transmitting A/V data. Also, the production system is not capable of transmitting addressed data. Therefore it would be desirable to provide a system which can coordinate the tr~ncmi.csion of an address through the command data system and the tr~ncmic.cion of local A/V through the produetion system to a receiving 25 unit eapable of reeording the loeal A/V and re-distributing it as is eurrently done with data.
The current reeeiving unit 14 may be accessed from the host via the tr~ncmi~.cion system as well as other means, including modems and the Internet; however, the multiplicity of communications protocols limits the flexibility of these communications. Also, it is difficult to coordinate multiple lines of communications to perform advaneed functions such 30 as monitoring of tran.cmic.cion reception via an Internet link. Thus it would be desirable to CA 02266~98 1999-03-19 W O 98/15122 PCTrUS97117412 create an integrated communication system which allows the host to use a single interface regardless of the communications topology that is being used to communicate with the receiving unit.
The command data system comprises mult:iple hardware and software elements. Each5 of these elements must communicate effectively in. order to ensure system functionality. As system complexity increases, however, it becomes increasingly difficult to maintain the integrity of inter-module communication, especially as particular elements are upgraded or replaced. Thus, it would be desirable to provide a standardized interface between the ~ elements which allows data to be transmitted there between and allows an app,ol,liate level of 10 error checking to be used.
The current receiving unit can only perform limited manipulations of the data itreceives. It would be desirable to provide a receiving unit which can perform advanced data manipulation. Performing more advanced manipulation requires a more sophisticated operating system and system diagnostics. Therefore an advanced receiving unit must also be 15 capable of performing advanced housekeeping functions.
The current system relies on the production system and the meteorology system toprovide the vast majority of products such as weather alerts and data form~tting. This requires large amounts of data to be repeatedly transmitted. It would be desirable to provide the receiving unit with sufficient intelligence to perform much of the data form~tting, such as 20 plotting data on map-like representations and other advanced features such as identification of notable weather anomalies or patterns and independent product selection.
The current receiving unit presentation file is built and played at the same time, leaving these systems idle for most of the progr~mming hour, then forcing them into a high state of utilization for the local weather tr~n~mi~.~ion. Because the current receiving unit must 25 "Build and Play" concurrently, it is limited by horsepower (as to the sophistication of its graphics) and by the desire to use the latest data. ":Build and Play" is a requirement of these systems because of the lack of permanent storage limited their ability to build and store a play file. Thus, it would be desirable to provide a system that can store data and selectively retrieve and process that data in a manner that more effectively and efficiently uses the 30 available resources, e.g., processor time, storage space, etc.

CA 02266~98 1999-03-19 wo 98/15122 PCT/USg7/17412 Summary of the Invention The present invention relates to a system which provides these desired functions and capabilities.
Addressing schemes according to the present invention allow more flexibility in progr~mming individual receiving units. The information may be, for instance, segregated between individual receiving units in the following manner: Each receiving unit has an interest list which can be, for instance, a table of two columns, the first of which bears a f~leld name and the second bearing a field value. Thus, a receiving unit in Cobb County, Georgia 10 may have a field name of"state" and a field value of ~'Georgia," a field name of"county" and a field value of "Cobb," and so forth, for any variety of selection criteria that may be desired.
The criteria need not be geographic. For instance, one criteria may be a field name of "demographic area I " which represents an area with a high number of retirees. A field value of "I" or "0" indicates that that receiving unit is or is not a member of "demographic area I ."
15 Thus, completely disparate receiving units in different regions may be "interested" in similar information due to factors other than geography.
At the tr~ncmi.~sion source, a product server formats the data, introducing an address which may be formatted in structured query language (SQL). For instance, a set of data may begin with the command "select receiving unit where County = Cobb." The next line of 20 information begins "weather inforrnation equals" followed by a string of data. Each receiving unit looks at the incoming inforrnation and if the address data matches the interest list, in other words, if "county = Cobb," it then proceeds and reads the rest of the data and formats it for display. ~f it is not true, the information is simply disregarded.
This allows the system to be different from conventional systems in at least the25 following manner. The current system uses a hierarchical addressing scheme. In other words data may be delivered only to ever expanding unitary régions. Thus, data may be sent to the receiving unit in the City of Atlanta or all of the receiving units in Cobb County, Georgia which might include the receiving unit in the City of Atlanta or all of the receiving units in the State of Georgia which will include all of the receiving units in Cobb County and the City 30 of Atlanta. It is impossible, however, to send a single message to be received by both a CA 02266~98 1999-03-19 receiving unit in Atlanta and a receiving unit in San Francisco without the same message being received by all of the receiving units in the same common region~ for instance, the United States.
It may be desirable, however. to address one message to separate receiving units in 5 distinct geographical regions without capturing the smallest common region between those two points. For instance, it may be desirable to direct targeted progr~mmin~ to a particular demographic sample such as the elderly or the retired in the cities of Phoenix, Miami and Los Angeles. However to do so with the current systern would require that three separate messages be sent, even though the data being sent is identical, in order to be addressed to 10 those particular receiving units without including the intervening common region and all of the receivin~ units included therein. The addressing system of the invention allows a single message to be targeted to numerous disparate locations without capturing unwanted receiving units. Thus the addressing list for a piece of data targeted at receiving units with particular demographics may be accomplished simply by including that criteria on the receiving units' 15 interest list and then addressing the information accordingly.
Both the current system and the new system transmit to the receiving units by means of a single transmission channel which carries multiple channels, e.g., four audio channels and one video channel. This video channel and one of the audio channels may be dedicated to the national progr~mming. One of the audio channels provides the background music for 20 data displays and one of the audio channels provides the comrnand feed to the receiving units.
The last audio channel provides digital command data. Other numbers and combinations of audio and video channels may be selected as applopliate.
Systems according to the invention have the ability to send local voice-over audio signals, that is, a narration for the local tran~mi~sion. Also provided are local video 25 downloads. In other words, instead of simply directing data to particular regions, audio and video may also be provided selectively to different regions. In order to do this, a portion of the satellite transponder system is taken and the modulation is narrowed to allow the addition of one or more sub-carriers. Alternatively, more tr~msponders may be used, increasing total available bandwidth.

CA 02266~98 1999-03-19 WO 98/lS122 PCT/US97/17412 In order to provide the video and voice-over information to the receiving units, a master dynamic scheduler (MDS) may be provided. Addressing information for data and the data itself can thereby be sent over separate channels. In the current system, the national transmission is produced in the production system as controlled by the automation system and 5 sent directly through the receiving unit to the viewer. The local transmission is created by the command data system and the data is sent to the receiving unit and stored, processed, and displayed periodically. The decision by each receiving unit to store particular data is based on the addressing information.
According to the invention, voice-over and video information can be produced in the 10 studio, which may controlled by the automation system, forwarded to a storage system and periodically transmitted, under the control of the automation system, in digital compressed form to the receiving units. The form in which it is transmitted, however, is not addressed.
Instead, addressing information is sent out from the host, which commands the receiving unit to, for example, "look at digital channel one and record information for the next 2 minutes."
15 The MDS coordinates the automation system and the host so that the message instructing the receiving units when to begin recording comes at the proper time so that the data is not missed.
Thus, a video and voice-over intended for a particular locality, such as Miami, may be pl~ pared. The host then sends a message addressed to the Miami receiving unit which tells it 20 to look at the first digital tr~n~mission line and to store the next 2 minutes of data that is being fed through. At the same time, the automation system begins transmitting the video data. The MDS coordinates these two devices so that the timing is worked out. The MDS
also knows to avoid conflicts. For instance, if the receiving unit cannot record video data and play back video data at the same time, the MDS knows at what times video is being played 25 back by a particular receiving unit and avoids sending data to that particular receiving unit at that time. The MDS is aware of what each receiving unit is doing at any particular time and selects data from the tran~mi~.cion queue for delivery in a way that avoids functionality conflicts while optimi7ing the use and capacity of the delivery medium. An alternate embodiment includes recording the data in digital fonn and also providing it with an address.

CA 02266~98 1999-03-19 Another embodiment includes foregoing the digiti.zation and compression of video data feeding it to the receiving unit in real time for immediate playback to the viewer.
Furthermore. use of the MDS allows the throughput of the tr~n.~mi.csion channel to be maximized. By prioritizing data, transmitting at appropriate times and identifying 5 "downtime" in which to transmit low priority data., the tr~n.cmi.~sion channel can be kept "full" at all times. This approach allows as much as possible of the channel bandwidth to be used before additional bandwidth must be secured. In other words, rather than rigidly scheduling tr~n~mi~ion times, much of the inforrnation which is not real-time or high priority may be delayed until bandwidth becomes available. Additional bandwidth becomes 10 necessary only when the entire channel is consumed over such long periods of time to make tr~ncmi~sion delays impractical. This has the effec:t of dramatically increasing the total tr~n.cmi.csion capacity over a given period of time.
In order to effectively manage the data flow, however, the MDS must know the status of each and every receiving unit which it controls. Where a two way link is available, such as 15 over the Internet, the MDS may simply query each receiving unit to determine its status (for example, this is necessary to avoid sending data to be recorded to a receiving unit when the unit is already playing back recorded data, since the recording and playback functions may conflict). When the only available link is one way., such as satellite tr~ncmic.sion, the MDS
must maintain a "mirror file," that is, a record of all information that has been delivered to 20 each receiving unit. In this manner, the MDS knows the rem~ining storage capacity of each unit and its playback schedule, allowing data tr~ncmic~ions to be scheduled for maximum efficiency.
One limitation of the system is that the satellite link between the tran.cmiccion facility and the receiving units only supports one way communication from the tr~ncmi~ion facility 25 to the receiving units. If this were the only link available, it would be impossible to monitor the receiving units and to conduct diagnostics to determine whether information was being properly delivered Thus receiving units are equipped with additional ports for communications, such as RS232 ports for modem access and TCP/IP ports for Internet access In this manner, the operator may contact each of the receiving units through these 30 other means and have two way communications that allow diagnostics, monitoring and other CA 02266~98 1999-03-19 tasks. Additionally, receiving units may receive transmissions over the Internet, but be serviced via a direct modem link.
One problem, however~ is that three or more communications protocols may be necessary, each required to support one means of communications. One standard protocol is provided for satellite delivery to the receiving unit, a second for modeming to the receiving unit and yet another for Internet communications with the receiving unit, etc. Thus it would be desirable to provide a consistent interface to the user regardless of what topology is used to communicate with the receiving unit. This is accomplished by providing a TCP/IP overlay, ~ which connects to the receiving unit. The "underbelly" of the overlay is a socket which 10 connects to as many communication protocol ~'translators" as necessary to support the selected means of communications.
Similarly, each element of the system includes sophisticated software components.
Each of these components must communicate effectively with the others so that the system can function properly. A system according to the invention provides software "plugs" which 15 are standard interfaces between software components. These interfaces allow standardization of communication protocols between components. Furtherrnore, features, such as error checking, may be incorporated in the plug.
Receiving units according to the invention incorporate a soRware structure whichincludes three layers: command, hardware and presentation. The command layer accepts all 20 data and determines whether the data is addressed to the particular receiving unit. If so, the data is either sent to the hardware layer, which is responsible for carrying out housekeeping tasks such as debugging and defragmentation, or to the presentation layer, which manipulates the data and prepales the product seen by the viewer. This modular approach allows for flexibility in progr~mming and maintaining the receiving unit.
Receiving units according to the invention may have advanced capabilities for manipulating and form~tting the data. Instead of simple graphics and static icons, many video effects, such as text scrolling, video fades, ~nim~ted icons, screen squeezes, etc. are provided.
In a system according to the invention, for particular forms of inforrnation only certain 30 data related to the product are actually transmitted. For instance, for radar maps, the basic CA 02266~98 1999-03-19 wo 98tl5122 PCT/US97tl7412 information relating to the region to be displayed, e.g., a topographic map of the United States and an overlay map showing the geographical boundaries, are stored by the receiving unit. Additional overlay information showing the actual radar data is sent out over the system. The receiving unit is given information to know its own location by latitude and 5 longitude. The receiving unit selects the portion of the map corresponding to its location and a predetermined surrounding area and displays only that portion of the map and its corresponding radar data.
Receiving units according to the invention may have a artificially intelligent prograrn for sc~nning the weather data in making projection,s based thereon. For instance, the 10 receiving unit may analyze the data used to construct a radar image and, if certain criteria are met, such as high intensity precipitation in conjunction with other factors, the receiving unit may issue a severe weather alert regardless of whether the National Weather Service has done so.
Likewise, receiving units according to the invention may intelligently "select"
15 products. For instance, a receiving unit in a landlocked region knows to display an Alm~n~c product instead of a Tides product. SimilarJy, receiving units according to the invention analyze incoming data and, based on selected criteria, generate new products which highlight significant aspects of the data. For instance, the receiving unit may analyze the incoming radar data to identify regions of high pixel intensity and density which would indicate severe 20 weather. The receiving unit may then generate a weather advisory product for the affected area.
The receiving unit according to the invention also responds to a loss of signal by generating its own playlist and operating until the signal is recaptured.
Accordingly, it is an object of the present invention to provide a multimedia 25 tr~ncmi~cion and distribution system which increases the ability of each receiving unit to be highly customized on a localized basis.
Another object of the present invention is to provide a multimedia tr~ncmiccion and distribution system which maximizes information throughput over a given tr~ncmi~sion channel thereby minimi7ing the number of channels necessary to deliver the product.

CA 02266~98 1999-03-19 WO 98/15122 PCT/US97/l7412 Another object of the present invention is to provide a multimedia transmission and distribution system which de-links the overall system from the receiving unit software - i.e., makes the software accommodate the spectrum of localization.
Another object of the present invention is to provide a multimedia transmission and distribution system which eliminates much of the time for dispatching configuration data so that more sophisticated and specialized data can be delivered in its place.
Another object of the present invention is to provide a multimedia transmission and distribution system which accommodates the current strategy of building a presentation from data and visual effects in a way that allows for more advanced pre-built presentations to be 10 downloaded and displayed.
Another object of the present invention is to provide a multimedia tr~n.smis.sion and distribution system which accommodates value-added "for-profit" services such as local advertising.
Another object of the present invention is to provide a multimedia transmission and 15 distribution system which facilitates the use of off-the-shelf presentation products.
Another object of the present invention is to provide a multimedia transmission and distribution system which allows remote retrofit of presentation and housekeeping software.
Another object of the present invention is to provide a multimedia tr~nsmi.ssion and distribution system which allows a consistent communications interface between the host and 20 the receiving unit regardless of the method of communication used.
Another object of the present invention is to provide a multimedia transmission and distribution system which has a non-hierarchical addressing system, i.e., that allows a single message to be delivered to multiple receiving units in different regions without capturing all receiving units the region common to the selected receiving units.
Another object of the present invention is to provide a multimedia tran.cmi.ssion and distribution system which allows local, but un-addressed, data to be recorded and/or processed by selected receiving units.
Another object of the present invention is to provide a multimedia tr~nsmis~ion and distribution system which includes software plugs between software modules to allow 30 standardized intermodule communications and error checking.

CA 02266~98 1999-03-19 Wo 98/15122 PCT/US97/17412 Another object of the present invention is to provide a multimedia transmission and distribution system which allows presentation of data with state of the art graphics and video effects.
Another object of the present invention is to provide a multimedia transmission and distribution system which can intelligently plot da~ta onto on-board graphic "base maps."
Another object of the present invention is to provide a multimedia transmission and distribution system which can independently interpret downloaded data and create new products based on the content of the data.
Another object of the present invention is lo provide a multimedia transmission and 10 distribution system which can independently selec,t products based on local criteria, Another object of the present invention is lo provide a multimedia transmission and distribution system which can operate in the absence of command data or input signals.
Other objects~ features, and advantages of the present invention will become apparent with reference to the rem~in(l~r of the written portion and the drawings of this document.
Brief Description of the Drawings FIG. 1 is a block diagram of a conventional video and data distribution system illustrating the tr~n.cmi~.~ion path of the national and local tr~n~mi~.~ions.
FIG. 2 is a block diagram of a conventional video and data distribution system 20 illustrating the flow of information through the production system.
FIG. 3 illustrates the structure of the Advanced Weather Graphics System of a conventional video and data distribution system.
FIG. 4 illustrates the structure of the production engine of a conventional video and data distribution system.
FIG. 5 illustrates the flow of data through the host of a conventional video and data distribution system.
FIG. 6 illustrates a scheme for providing additional tr~n~mi.~sion band width in a multimedia tr~n~mi.~sion and distribution system according to the present invention, CA 02266~98 1999-03-19 W O 98/15122 PCTrUSg7/l74l2 FIG.7 illustrates the portion of a multimedia transmission and distribution system according to the present invention which is responsible for creating and distributing the progr~mming.
FIG.8 illustrates the portion of the system of FIG.7 which is responsible for 5 receiving the progr~mming.
FIG.9 illustrates the configuration of the product server of the system of FIG.7.
FIG.lOis a functional object map of the system of FIGS.7-8 which illustrates theC++ classes and objects and their interrelationships.
FIG.llis a structural object map illustrating the relationship between the components 10 of and the flow of data through the system of FIGS.7-8.
FIG.IIA is a structural object map illustrating the relationship between the components of and the flow of data through the host and product server of FIG.lI.
FIG.llB is a structural object map illustrating the relationship between the components of and the flow of data through the product posting module of FIG.Il.FIG.llC is a structural object map illustrating the relationship between the components of and the flow of data through the host module of FIG.ll.
FIG.llD illustrates the structure of a command message as utilized by the system of FIG.ll.
FIG.llEis a structural object map illustrating the relationship between the components of and the flow of data through the queue server module of FIG.II.
FIG.llFis a structural object map illustrating the relationship between the components of and the flow of data through the command module of FIG.II.
FIG.llG is a structural object map illustrating the relationship between the components of and the flow of data through the de-queue module of FIG.ll.
FIG.lIH is a structural object map illustrating the relationship between the components of and the flow of data through the command abstraction layer of FIG.II.
FIG.12is a functional object map of the socket classes of the system of FIG.II.
FIG.13 illustrates the structure of the software plugs of the system of FIG.Il.
FIG.14is a functional object map of the packet classes of the system of FIG.11.

CA 02266~98 1999-03-19 WO98/15122 pcTrus97ll74l2 FIG.15is a t'unctional object map illustrating the data base abstraction definitions of the system FIG.II.
FIGS.16 and 16A illustrate the dynamic information strategy employed by the system of FIG.II.
FIG.17is a functional object map of the host of FIG.II.
FIG.18is a flowchart showing the flow of information through the ingesters of FIG.
I I .
FIG.19is a flowchart showing the flow of information through the product postingmodule of FIG.ll.
FIG.20is a flowchart showing the flow of inforrnation through the host module ofFIG.II.
FIG.21is a flow chart showing the flow of information through the command moduleof FIG.II.
FIG.22is a functional object map showing the structure and classes of the receiving 15 unit of FIG.II.
FIG.23 illustrates the software structure of the receiving unit of FIG.II
FIG.24is a flowchart showing the flow of information through the common application layer of the receiving unit FIG.ll.
FIG.25is a flowchart showing the flow of information through the hardware abstraction layer of the receiving unit FIG.II.
FIG.26is a flowchart showing the flow of information through the presentation application layer of the receiving unit FIG.ll.
FIG.27 illustrates the file structure of the receiving unit of FIG.Il.
FIG.28 illustrate the fields used in data records used by the system of FIG.Il.
FIG.29 illustrates the data types used by the system of FIG.Il.
FIG.30is a table of common application layer commands used by the system of FIG.11.
FIG.31is a table of presentation engine layer comm~n~ used by the system of FIG.11.

CA 02266~98 1999-03-19 WO 98/1512~ PCT/US97/17412 Detailed Description of the Invention Figures 7-8 schematically show a multimedia tr;ln.~mi~ion and distribution system 9 consistent with the principles of the present invention. They should not be viewed as limiting, but rather to disclose in detail one particular way for carrying out the invention.
5 Although the embodiment disclosed hereunder is directed to a system for the transmission and distribution of weather related multimedia progr~mmin~, the invention may be used to distribute many different forms of information, including, but not limited to, sports, education, entertainment, business and commercial progr~mming, data and other information.

10 Types of Data Transmitted Data types have important rarnifications with respect to the function and capacity of hardware involved in processing~ transmitting and distributing information. Data types may be defined based on three criteria: Lossiness, Average Size, and Real-Timeliness.
Lossiness refers to the degree to which data degradation (e.g., due to compression) 15 will be tolerated by system 9. Lossless data cannot tolerate any data degradation. Lossy data can tolerate some degradation. Average size of the file is generally computed in megabytes and ls relevant because thé conduit (the "pipe") through which the data is transmitted is often limited. Thus, larger files may require special h~n-lling considerations. Real timeliness refers to the urgency of the data. Thus, a severe weather alert is urgent, whereas an upgrade to an 20 infrequently used software utility may not be urgent.
Data may be divided into four classes:
~ Class A Data Binary Lossless: Usually under 1 MB. This type of data normally consists of command strings, tabular, and narrative weather data, and relatively small bitmaps such as the national 25 weather map. It is not generally acceptable for data to be lost in the compression and processing of this data.
Class B Data Single Variable Frame Lossless: Large files, such as bitmaps and programs. Again, it is not generally acceptable for data to be lost in the compression and processing of this data.

CA 02266~98 1999-03-l9 ~ Class C Data Digital Audio/Video Lossy: Large audio and video clips. These files require large amounts of storage space and norrnally must be compressed, which may cause the data to be changed and perhaps degraded to an acceptable extent in the process.
~ ClassD Data Analog tr~n~mi~sions.
These data types reflect the increased flow of data to receiving unit 14. This flow requires increased space and transmission lines. To achieve the needed pipe size, current bandwidth may be manipulated to allow more data tr~n~mi~sion without affecting current 10 tr~n~mission reception. Signal processors snip the ends off of the current bandwidth and send compressed data through the two ends. FIG. 6 illustrates such a strategy. Also, as described more fully below, a dynamic scheduling system may be employed to maximize utilization of the pipe. Other means of providing increased tr~n~mi.csion capacity may be employed as apl~lopliate.
Data Gener~tion The sources of the information to be transmitted and distributed are national transmission 60, weather (via met system 66), and scheduling 64. National tr~n~mi.csion 60 runs continuously, whether it is live or pre-produced. This is necessary because not all cable 20 operators have receiving units 14 for local weather tr~nsmi.csions. Also, some viewers have their own satellite dishes or direct broadcast systems and do not receive local tr~n~mi~ions.
In these cases, the cable operators and viewers continue to view the national tr~n.cmi~ion 60 throughout the progr~mming day.
System 9 treats all progr~mming segments, including advertisements, as products.25 Product development system 62 provides the mech,~ni~m by which these products are created and introduced into the system. Examples of products that may be displayed include: radar, current conditions, 36-hour forecast, regional observations, regional forecast, :~lm~nzlc, extended forecast, tags, copy splits, custom products. Of course, because the system may also be used to distribute non-weather information, any number of products may be 30 envisioned. For instance, a sports channel may display game statistics, scores, etc.
2l CA 02266~98 1999-03-19 Traffic system 64 provides the template for production and advertisement schedules for the progr~mming day. This template is delivered as a static file and is made real-time by real-time source book 78.
Weather observations arrive from met system 66 and are delivered to product server 76 where they are ingested, addressed (via data supplied by AIMS), logged, and forwarded to host 52 and the Voice-Over Support System (VOSS) 77. Product server 76 feeds data to the in-house receiving unit (via 10 based "T" connection or over its own network) VOSS 77 provides system 9 with a means for allowing the presentation of graphicsand speech to be synchronized and delivered to selected receiving units 14. This technology 10 allows the operator to produce and deliver market specific audio forecast presentations to air during local transmissions 16.
To record audio tr~n~mi~sions, the On-Radio Meteorologist (ORM) requires equipment to record, store, and transfer audio. This is performed by digital audio sampling device 104 (essentially a computerized tape recorder), such as an Enco Audio System.
15 Device 104 allows audio mixing; recording from a number of sources; and the storage, compression, playbacl~, and transfer of audio files. Device 104 is used to record and playback voice files. Device 104 in voice booth 102 is used to record and pre-view voice files.
Device 104 is used for playback of voice files to air.
The ORM requires local weather information from met system 66. VOSS 77 feeds 20 this information to the ORM in an easy-to-access manner, so that the data can be read into the device 104. Voice booths 102 are used to record local tr~n~mi~.cions 16, and provide another source of inforrnation. They are supplied with equipment to record tr~n~mi.~ions and provide local meteorological information to the meteorologist. The workstation in voice booth 102 has the same functions as the prep station (not shown).
The prep station allows the user to view any products supplied to system 9 by met system 66. The prep station is responsible for preparing scripts which are supplied to product server 76. The scripts specify the components and the duration for a selected local playlist.
Once the playlist is pr~p~ed, the prep station downloads the script to product server 76. All narrative text editing takes place at met system 66. Met system 66 feeds data to product CA 02266~98 1999-03-19 Wo 98/15122 PCT/USg7/17412 server 76. The user in the voice booth has the ability to access narrative, tabular, graphic &
imagery inforrnation from met system 66.
VOSS 77 is adapted to address and continuously receive data for specific markets.
When voice booth 102 sends out a request, VOSS 77 acknowledges the request and runs the S file. The output of VOSS 77 is then monitored by the user in voice booth 102. MDS 68 monitors the automation playlist in order to schedule the playlist transmission to specific local markets.
Automation system 72 controls and manag,es the playlist and triggers device 104 and host 52 for field recordings and playback. Host 52 is the real time engine that controls the l 0 sched-lling and execution of products to be displayed on receiving unit 14.
Affiliate database 20 connects directly to product server 76. Affiliate database 20 m~int~in~ the integrity of the ~ffili~e information in the product server's database. This allows all other applications to view this as one lo~ical tl~t~h~ce.
VOSS 77 may be programmed via a graphical user interface in the following manner:
Screen One allows the selection of the city to be edited for a particular presentation.
This is a drop down window feature that allows scrolls through the cities loaded in the system. The operator scrolls through the menu by using the up and down arrows or by moving the slide bar with mouse. Once the city is selected, the operator may press enter or double click the mouse to select the city. After a city is selected a window appears. In that window there are three options to choose from. (1'1 metro forecast; (2) county specific; (3) Head-end specific. Once the selection is made, the interface advances to the next screen.
Screen Two offers two functions:
a) Selection of the playlist to be prepared; and b) Pull-up the playlist by typing a file narne.
The pre-programmed playlist includes marhet specific alpha, beta, g~mm~ delta, and sigma files.
Screen Three is in a spread sheet type forrnat. The operator has the ability to edit, delete, or insert on any field necessary. The fields and their functions include:
a) Flavor type - Header title indicating the sequence of products or "flavor" being ple~ ed.

,,, CA 02266~98 1999-03-19 b) City - Indicates the city for which the forecast is being l~le~)aled.
c) Head-end address - Indicates the receiving units 14 that will receive productand audio data.
d) Expiration time - Indicates the expiration time of a playlist. This time stamp is 5 embedded in the product data stream.
e) Total duration - Shows the total run time of the playlist.
f) Duration field - Shows the duration of a product in a playlist. This is a changeable field.
g) Product type - Indicates the type of product (e.g. current condition page).
l O h) Notify field - In this field it may be deterrnined whether the operator or talent is alerted when special weather conditions are transmitted.
i) Product ID - Indicates the type of product via its ID number (e.g. ALOOIX =
Alm~n~r) j) Priority field - Allows the operator to assign a priority for the transmission of a~5 playlist (e.g. 3=normal, 2=high, l=highest).
k) Time slot - This allows the operator or talent to choose the forecast they want the playlist to preempt.
l) Pre-load - Allows staging of the playlist.
m) ~ecord - A GPI trigger that takes the interface to the countdown window (4) 20 and simultaneollsly trigger device l O4 to record and start the playlist sequence. Device and the playlist should not fire until the clock reaches zero.
n) Save - Allows saving of the playlist to a file name for recall at a later time.
o) Quit - Takes the user back to screen ~1.
Screen Four appears when '~record" is executed (in screen 3). The system switches to 25 screen 4 and starts the countdown sequence. At zero, the system switches to screen 5 and, via GPI, triggers device 104 to record and start the playlist sequence. Executable icons include:
a) Hold - Holds the countdown sequence.
b) Start - ~e-starts the countdown sequence when Hold or Stop is triggered.
c) Stop - Stops the countdown sequence and re-sets to the default countdown 30 time.

CA 02266~98 1999-03-ls d) Quit - Stops the countdown se~uence and sends the user back to screen 3.
Screen Five allows the user to see the playlist sequence while the user synchronizes voice with each product. Executable icons include:
a) Stop - Stop halts the process and re-sets the playlist and device 104.
b) Start - Simultaneously re-starts the playlist and device 104.
c) Re-play - Allows the user to perform quality control on the presentation.
d) Send - Sends the product and voice files to their proper holding destination before going up on the satellite.
VOSS 77 functional requirements preferably (but need not) include:
1 ) Voice files are mixed at receiving unit 14 during the local forecast with the national music feed. The national feed may be reduced by 2db (~30%) and the voice file played back at its normal level.
2) A priority "one" playlist is transmitted within 5 minutes of MDS 68 receivingthe request.

3) Each in-house receiving unit 14 is configured regionally. Receiving units 14 are placed on the router and routable to any selected voice booth 102.

4) All updates from product server 76 to all in-house receiving units 14 are automatic and continuous.

5) Regular forecast air pass-through audio at their full levels.

6) Playlist for all markets are pre-built products. The operator has the ability to dynamically edit playlist fields. This includes durations, products, expiration time, priority, and time slot.

7) All playlist files are scheduled to trcmsmit once received by host 52. If theassociated audio file does not reach the receiving unit 14 when local forecast 16 is triggered, 25 the system recognizes that the associated voice file is not present and passes national audio at its full level.

8) The in-house receiving units 14 must be continuously updated with the most current data by product server 76.

9) When host 52 transmits new weather data to the field, receiving unit 14 30 associates that new data with current voice-supporl:ed products airing during local forecast 16.

. . .

CA 02266~98 1999-03-19 Once the association is made~ receiving unit 14 dismisses any voice file previously associated with that product(s) and go to national default audio. However, some products continuously receive updates during the life of a playlist (e.g. temperature, wind, etc.) These products should continue to play their associated audio files. These products are identified for the 5 programmer.

10) Improperly formatted messages are rejected and passed to the receiving unit VOSS position.

11) All specific playlist and voice support terminate at their expiration time.

12) All narrative text updates are performed preferably at met system 66 terminal 10 rather than VOSS 77.

13) Each element of a playlist is recorded separately and reassembled at receiving unit 14.

14) Each element of a playlist may be recorded individually or collectively.

15) Ability to request supporting data, playlist, etc. from multiple VOSS 77 work 1 5 stations.
Local tran~micsion 16 may also include video portions, such as local weather reports, commercial advertisements, etc., tailored to each region. To record the production of local weather reports, additional video recording studios 106 must be installed. Studios 106 can also act as baclcups for national tr~n~mi~.cion 60. Production systems facilitate the recording, storage, and transfer of digital media.
Recordings from local video studios 106 are stored on media server 108 until transmitted to receiving units 14. Each local video studio has manual control panels, much like the national studio. These panels can also be used as a backup, should the main studio control panel fail.
The primary source of information, which may be weather data or other types of information, enters the system through met system 66. Met system 66 is a system for collecting and formatting data for use by the other elements of system 9. Met system 66 preferably communicates with host 52 via TCP/IP Ethernet. Met system 66 feeds all localized weather data--temperature, weather conditions, etc. Such data features an address-level scheme information for downward compatibility with previous systems. These ... ...

CA 02266~98 1999-03-19 addresses are converted into the Command/Query architecture. Met 66 provides the national radar map, immediately upon receipt, as frequentl~ as every five minutes. Host 52 is responsible for sending the map to all receiving units 14 within the next five minutes, but preferably on an average of no more than thirty seconds following receipt by host 52.
Warnings and advisories are transferred in real-time and host 52 transmits them to receiving units 14 preferably within one minute and more preferably within thirty seconds.
Warnings or advisories not sent because of the sysl:em's inability to interpret them should be displayed on the command console and/or printed.
Media server 70 stores digital and audio clips for future tr~ncmic.cion, and records and 10 transmits data on command from automation system 72. Because of its tr~n.cmicsion method.
it can only store digital video and audio (Class C) f;les. Tape console 44 is currently envisioned as a component of the media server 70. Tape console 44 is a video tape "jukebox," such as an Odetics, and acts as a repository for video productions off-loaded from the media servers, particularly national commercials.
Coor~in~tion ~nd Assembly of Data To route data to individual receiving units 14, host 52 requires ~ffi]i~te information.
The Affiliate Information Management System (AlMS), m~int~inc affiliate-related data for each receiving unit 14. Each receiving unit 14 is at an ~ffili~te's place of business. That data 20 is m~int~ined by affili~te ~1~3t~b~ce 20. Because the goal of the system is to provide increasing localized productions, ~ffili~te ~l~t~h~ce 20 stores configuration modifications made to each receiving unit 14 from a generic configuration. Affiliate database 20 consolidates data into working files for addressing by host 52. When data is downloaded to a receiving unit 14 during full reconfiguration, data remains on affiliate ~i~t~b~ce 20 for dynamic access via 25 TCP/IP.
To access the required data, product server 76, AIMS and ~ffili~te database 20 requires connectivity capable of establishing links between foreign databases. With such a link in place, a read-only interface into ~ffili~te ~t ~bS~ce 20 provides access to its data elements. Data is then converted to a predetermined data format and posted to the product 30 posting file 84, where host 52 can access the inforrmation.

, CA 02266~98 1999-03-lg WO 98/15122 PCTtUS97/17412 Affiliate database 20 supports additional features, thus the database is preferably modified to contain the following additional fields:
Receivin~ unit type. This field contains a value indicating whether receiving unit 14 is a local edition or a standard receiving unit.
S Receivir~ unit rP Address. This field contains the IP address of receiving unit 14 to facilitate use of Comm~n-l/Query.
Host File. Affiliate database 20 compiles Affili~te data into an addressing file for host 52.
~Jpdate host. Mass updates may occur once each day, such as at 18:00 hours (6:00PM) Eastern Standard Time (EST).
S4_Address. Refreshes receiving unit data once each hour.
Ski T~.
Rotate Ski T~s.
Garden T~.
Master Dynamic Scheduler (MDS) 68 adjusts systems 9's schedule and communicates that schedule to automation system 72 and host 52. MDS 68 coordinates with all other system elements to update schedule adjustments. MDS 68 also calculates and schedules the downloading of products 64 from product server 76 through the host 52. MDS 68 may simply provide .for original posting of and updates to the daily schedule log. MDS 68 may also organize and schedule product downloads through other channels outside host 52. MDS
68 may also organize the routing of digital media, such as host command data, device 104 audio data, and media server 108 digital video data, over available digital lines.
Automation system 72 is a sched--ling subsystem that controls and schedules the production components. Some schedule events such as off-line video and audio production, are in the domain of automation system 72. However, when scheduling affects the tr~n~mission of information to receiving unit 14, automation system 72 works as a sub-system of MDS 68.
Host 52 accepts its schedule from MDS 68. To execute the next event in the schedule list, a Take Command is sent from automation system 72 in the form of a 5-volt pulse. When CA 02266~98 1999-03-19 WO 98/lS122 PCT/US97/17412 such a command occurs, host 52 sends a command to receiving unit 14. Host 52 acquires prioritized data from the product server 76:
Priority I - Class A command data and important weather information.
Priority 2 - Class B standard weather data.
Priority 3 - Class B data consisting of programs and graphics.
To execute the next event in the schedule list, a Take Command is sent from real-time source book 78 in the form of a 5-volt pulse. Hosl. 52 takes the data and delivers the data to the master router 80 for delivery to receiving units 14.
~ Host 52 also performs some additional formatting of the data. For instance, text may be formatted for particular screen configurations to avoid orphans or other aesthetic anomalies. Host 52 may also perform some dynamic scheduling. For instance, by applying a set of rules, the host may determine that a particular set of data is more time critical than other data and move the time critical data to a higher trz n~mi.c~ion priority. For example, a weather warning might override data reflecting culTent weather conditions. Thus, the weather warning information would be moved to the front of the queue. Backup host 74 also accepts its schedule from real-time source book 78.
As illustrated in FIG. 9, product server 76 is the primary central database and computing resource for system 9. It is responsible for hzln~lling of addressing, configuration, meteorology, data mirroring, and transaction logging for host 52. Through Product Development Management System 84, all meteorological data, presentation products, and configuration information are docked for eventual trztncmi.~cion to a receiving unit 14.
From the product server 76 perspective, there are three types of data that must be transmitted to receiving unit 14 to form a trzln~mi.csion: Command, Cyclical, and Real-Time Weather Data. As notices of modified data are received by product server 76, they are categorized accordingly. This categorized data is then formatted and combined with addressing information retrieved from affiliate ~z~tzlbz~ce 20. This final data product is posted to Product Posting File 82, which is continuously polled by host 52. Product server 76 and host 52 may be resident on a single platform such as a Hewlett Packard 9000, or may be resident on separate platforms.

CA 02266~98 1999-03-19 Referring to FIG 7, the Master Control (not iliustrated) allous monitoring and human in~er~ention into the system Svstem Mainten~nce The Engineering Maintenance S,vstem (not sho~hn) provides access ~o. and diagnostics utilities for host 52 I~aintenance System 86 provides hardware and softt are to configure and maintain equipment. and provides local and remote (~modem) diagnostics of individual receivin~ units 14 10 Tr~n~mission of Pro~r~rnminc to Receivin~ Units Master Router 80 rou~es all production lines. and has four importan~ input linesNational Feed Video 82 which carries national transmission 60 2 National Feed Audio One 82 which carries the audio associated ~ith national transmission 3 National Feed Audio Two 82 which carries alternate audio, normally for music associated with the national tr:ln~miccion 60.
4 l~'ational Feed Audio Three 82 which carries alternate audio. normally for foreign lan uage associated with the na~ional transmission 60 I ;'nder the control of automation system 72 and the Master Control Panel (not shown).
20 master router 80 coordinates inputs with the various outputs The inputs defined abo~e are matched with their corresponding outputs as follows 1 National Feed Video (NFV) 88 2. National Feed Audio One (NFAI) 90 3 l~iational Feed Audio Two (NFA2) 92 4 ~'ational Feed Audio Three (NFA3) 94 From this point. all outputs take different paths to their final combination into a satellite si~nal.
The na~ional feed must be scrambled along with its two most closely associated audio feeds. All three, NFV 88. NFA1 9'. and NFA2 94. are combined and scrambled at the National Feed Scrambler 96 30 Once combined. this inforrnation is fed into sub-carrier combiner 98. Sub-carrier combiner 98 talces the CA 02266~98 1999-03-19 WO 98/15122 PCT/USg7/17412 following inputs and combines them into one broadb~md output including the scrambled national feed, national audio feed three 94 and receiving unit command feed 100.
Additional equipment may be added to the transmission systems to accommodate an increase in data flow. This equipment provides the following data lines:
Two 3.5MB Digital Video Streams 110, 112.

16 Audio Channels with 256KB per channel (not shown).
In such an event, the signals may be encoded individually before being combined.Encoder 114 encodes national tr~n~mi~sion 60. Encoder 116 encodes digital video one line.
Encoder 118 encodes digital video two line. Multiplexor 120 distributes encoded data depending on need. Combiner 98 compiles encoder lines into one tr~n.smission.
A modulator (not shown) accepts video as analog, audio as analog, and data as a digital feed, and will modulate them into a broadband signal transmitted via satellite to all receiving units 14. For the transmission, the signal is compressed, providing three video and associated audio channels, along with three additional audio channels. This compression method also supports three data channels with a 512KB transfer rate.
The portions of system 9 installed at the cable operators' sites consist of manysubsystems allowing communications from host 52, connections to auxiliary equipment, and diagnostics. Referring to FIG. 8, the broadband signal transmitted from system 9 is fed into the integrated receiver and descrarnbler, where the National Video (NFV) 88 and associated audio (NFAI 9~ & NFA2 92) are separated and descrambled. Both are then fed to receiving unit 14, along with the descrambled bro~(lb~n-i signal 122 cont~ining all of the video and audio bands.
~ The Digital IRD (not shown) is added to the existing Analog IRD. This device receives the compressed feed and provide selected access to the new digital audio and video.
The system uses an RS232 control line from systen~l 9 to determine which of the two digital data feeds will provide Dl input. On the audio side, each channel provides eight audio strearns; the control line allows system 9 to select which of these it will use.

~ , , .

CA 02266~98 1999-03-19 Delivery of Pro~r~nlmin~ to the Viewer The programming is received by the ~ffili~te and delivered to receiving unit 14 where it is processed for delivery to the viewer. Receiving unit 14 is considered an industrial automation system. It is capable of operating in an environment that is much different than a 5 residential installation. The hardware must have a certain degree of expandability.
Thus, in an illustrative embodiment, receiving unit 14 is based on a motherboardsupporting a RISC SC processor running at 180 megahertz, 64 megabytes memory, a power supply, two two gigabyte hard drives, a high speed RS-422 data port, three high speed RS-232 data ports, a GPI interface, a fast and wide SCSI interface and a video processing board.
10 Other components may just as easily be used to serve these functions. Various ports are provided for external interface, including a l00110 BaseT Ethernet port for TCP/IP access. In the illustrative embodiment, a Silicon Graphics workstation is used as the platform~ which is available from Silicon Graphics, Incorporated at 2171 Landing Dr., Mountain View, CA
94043-0837. Other platforms may be used as receiving units 14 as appropriate.
Receiving unit 14 includes software which is a multimedia playback engine, such as Evolving Video Technology's Antero presentation software. Other commercially available or custom developed presentation software may be used as desired or appropriate. It provides the basic data forrnat on which the data provided to receiving unit 14 is to be displayed. It also includes a play-list of video effects. A play-list is the sequence of how the data is 20 projected onto the screen in the applopliate location.
For instance, a typical local tr~n.smi.s.sion may comprise a template in which current weather conditions are displayed. The template is essentially a graphical design or structure with certain areas denoted as fields for particular types of data. One data field might be a title box which in one region may state the words "current conditions," and in another region 25 might display the words "present conditions." The selection of words may be made by the ~ffili~te and is programmed into the ~tfili~te data base. Furthermore, other graphical special effects may be included such as the manner in which the text appears on the screen and various other types of visual effects, such as cross fades, etc.
Receiving unit 14 provides video production on cornmand to cable operators. To 30 perform this procedure, the system requires the following inputs and outputs: Broad Band In ... .. . .. . ...

CA 02266~98 l999-03-l9 WO 98/15122 rCT/US97/17412 122 which provides command data from the host 52; Analog Video 88 which providesNational Video Feed 88 for national tr~n~mi~sion 60; Audio ~eft 90 which provides input for Audio Left (NFA I 90) for national transmission 60; Audio Right 92 which provides music for the local tr~n.cmi.~sion 16; Analog Video Out 124 which provides the video signal for the 5 cable network whether local tr~n~mi.~ion 16 or national tr~n~mi~sion 60 is passed-through;
Analog Audio Out 126 which provides the audio signal for the cable network whether local audio or national audio is passed-through; Weather Sensors In 128 which provides the attachment for local weather sensors; and RS232-In 130 which may be used with a modem.
The receiving unit software is responsible for the basic operation of receiving unit 14, 10 maintaining its database and overall m~inten~nce. The software supports a subset SQL-compatible command strategy. It interprets SQ~ slatements, first to determine whether they meet the query specifications, and second to execute their comm~n~c. The software may interpret precompiled or ASCII text versions of the command set.
The software may execute a prerecorded, downloaded list of presentation events in 15 coordination with the third-party application software. It monitors the execution of these events, down to the frame-level, and has the ability to skip forward events in the playlist if required.
The software supports a TCP /IP terrninal interface for configuration and diagnostics.
The options provided include the following:
20 Log-in: Provides secure access to the system resources SQL Command Line: A command line at which the user enters receiving unit SQL
st~telnerltc, Set Tr~ tion Log Parameters: Allows the system engineer to select the event that will be written to the log.
25 Set Transaction Log Duration: Allows the system engineer to select the amount of time events will be held before they are deleted.
Set Cloud-Net IP Address: Allows the system engineer to set the IP address of receiving unit 14.
Set Internet Assigned IP Address: Allows the system engineer to manage the true IP
-30 address of receiving unit.

CA 02266~98 1999-03-19 Reset All: Reset the system.
Reset Software: Purge all software and reload.
Print/Transfer Transaction Log: Print the transaction log to a local printer, or transfer it to the host hard disk.
View System Log: View the transaction log.
Clear System Log: Purge the error and transaction log.
Clear Current Errors: Clear the current error status, which will clear the notification icon.
Configure notification parameters: Configure notification methods such as dial-beeper, show notification icon error levels, and report to host error levels.
10 Command Query ~nterface: Allows the user to enter command query line entries. Log-out: Log-out.
The system software records the following events:
Failed File Transfers.
Failed Command Interpretations.
Operating System Errors.
Optional Events with User-Defined Duration:
Any Selected Query/Comm~n~l Any Select Data Element Access.
Actual Execution Time and Duration of Any Playlist.
Actual Execution Time of Any System Function.
Monitoring of Any Input/Output Device or Port.
The command stream between host 52 and receiving unit 14 is a TCP/UDP/IP
connection selection protocol. When in satellite transfer mode, the socket selected provides a UDP protocol with a loop-back that simulates TCP connection orientation. When a 25 connection is established over a communications line supporting TCP/IP, the connection runs under true TCP/IP. Simulating TCP/IP over the connectionless satellite communication path provides the system with the ability to receive data over the RS232 or Ethernet connections with error reporting. This facilitates diagnostics and off-line downloading of commands and data without the need of special utilities.

CA 02266~98 1999-03-19 Software loaded on receiving unit ~ 4 has a hardware abstraction layer that intermittently performs the following tasks: disk defragmentation; system database mirroring:
configurable local dial-up reporting of system errors; configurable dial-up reporting to a global system error log; configurable beeper notification of system errors; and configurable 5 display of yellow and red blinking icons to indicate that system errors have occurred requiring local-system engineers to review error log, solve the problem, and clear the error.
The system database contains all information needed for operation. It supports the insertion or deletion of data elements. Data elements allow sub-fields. Sub-fields are fully configurable and have the capacity to contain the fi~llowing data types: zero terminated 10 variable length string, byte. integer, double, variam:, and float. Weather data contains information indicating the data is valid only for a limited amount of time. The time period and time-stamp of the data are m~int~ined, and the time period is configurable.
One important goal of system 9 is to provide powerful product development tools to developers and remove custom progr~mming tasks required from support staff. All products 15 contain a presentation editing system capable of saving presentations and all effects in a useable file format. The software provides a run-ti:me engine controlled by the system software that executes the pre-developed presentation in real-time.
The editor allows smooth interaction with a Graphical User Interface developed for playlist editing. Features allow for launching the rlm-time engine with a current playlist for 20 testing and drag-and-drop editing of data elements onto the editing canvas.
The run-time engine allows full control and communication with the system software.
This control is at the frame-level. The run-time engine is able to communicate errors and allow the system software to ascertain missed frames.
System 9 provides the standard effects shown in the following table:

Crawl _ sp ay a l nes n a text ~ oc c as a s ng e ne that craw s -om eft to right across the screen.
Ease In During the first 25 percent of effects duration, effect starts slowly and accelerates to full.

Wo 98/15122 PCT/US97/17412 Ease Out During t 1e last 25 percent of effects duration, e 'fect decelerates to the effects completion state.
Chroma Use of a video signals color characteristics to cut a foreground image Key into a background image.
Page Reveal Reveals the new page as the existing page pushes off of the canvas from the direction the user specifies. Effect direction: From bottom left, bottom right, left~ right, top left, top, top right.
Push Pushes a new page on to the canvas from the direction the user specifies while pushing the existing page off. Bottom left, bottom right, left, right, top left, top, top right.
Reveal Display different objects on a page based on the order in which the user entered, until the entire page is displayed. Bottom left, bottom right, left, right, top left, top, top right.
Reverse Display all the lines of text on the page as a single line that crawls from Crawl left to right across the screen.
Reverse Roll each line of the page vertically down from the top of the screen at a Roll specified speed until the top line rolls off of the canvas. Effect direction: Top.
Reverse Zip Move each line of text on the canvas from left to right based on theorder in which the user typed the lines. All lines of text end up justified on the screen. Effect direction: Line by line from left.
Roll. Roll each line of the page vertically up from the bottom at a specified speed until the bottorn line rolls offthe screen. Roll-effect direction:
Bottom.
Wipe Wipe a new page on screen and the existing page off from the direction the user specifies. Wipe-effect direction: Top down, bottom up, center out, right to left, left to right.

CA 02266~98 1999-03-19 WO 98/lSl:Z2 PCT/US97/17412 p On Move each line of text on to the canvas f'rom right to le: ~ased on the order in which the user typed the lines. Effect direction: Line by line from right.
Multi-line Simultaneously crawl each line Oll a page in different locations on the Crawl screen. Crawl - effect direction: ~From left to right, right to left.

Receiving unit 14 is aimed at providing highly sophisticated, visually stimulating presentations of information.
Each receiving unit 14 has its own set of base maps and station identifiers. Base maps 5 have projection information allowing for the proper placement of station (city) identifiers. A
table showing a station's latitude, longitude, and name (long and short names) is stored in the database. (The latitudes and longitudes are visual latitudes and longitudes, not the actual.) Each receiving unit 14 may store the actual latitude and longitude of the cable operator, along with the visual latitude and longitude for the center of any local view ports.
Receiving units 14 support a zooming capability. At various levels of the zoom, inforrnation, such as city names and weather conditions, may be hidden or revealed. A macro scale view allows the viewer to see less density of cities, while a tight zoom-in allows the more densely clustered cities to appear in an easily readable form. Also, receiving units 14 support any map projection and are able to merge maps of differing projections.
Receiving units 14 are capable of dynamically ch~nging the products or the sequence of products within a product or "flavor," and creating a new flavor. Products are what the viewer sees. Local forecast, Regional Observations etc., are all presentations made up of different elements. Products or "flavors" consist of many types of data like template files for each page the viewer sees, sequence files that tell the pages when and how long to run, and 20 product components like bitmaps, icons, and animation's that the pages use to build a presentation. The data that makes up products are product inventory items. Again these are the templates, sequences, and graphics that make up any presentation. These can be viewed as the tool chest the presentation engine uses to produce presentations. This is true for each individual receiving unit 14, as well as universally. The local forecast flavors are smart. This . ~ .................. . . . , .. ... ~

CA 02266~98 l999-03-l9 allows event-actuated local forecast products. For example, if a particular receiving unit 14 does not have radar echoes within its specified viewport, a different product can be presented.
The logic in the programming language that wraps around the graphics rendering script allows receiving unit 14 to pick its product, generally depending on its interest list, for 5 example, Tides versus ~Im~n~c. Locations along the coast would display tidal inforrnation, while in-land areas display the ~Im~n~c.
Graphic/video functionality is provided as follows: ability to change style, speed, location, fonts, timing, and type of a crawl; ability to support real-time compositing; ability to record and playback full-motion video in real-time; ability to insert live-local presentations 10 either as pass-through or off the disk so that the presentation can be either full-screen or squeeze-zoomed to show additional weather information; ability to squeeze-zoom the national or local tr~n.~mi~.cions to show additional weather information; ability to double-box or pass-through video for two independent video sources; ability to digitize a video stream to disk; ability to adjust compression rates of incoming video stream; ability to transfer from the 15 national tr~n~mis.~ion to the local tr~n~micsion or information sereen; ability to show motion video as a background, either in real-time or off the disk; ability to make eity identifiers translucent to avoid covering them by such other items as radar information; and ability to composite (layer) images.
The logical addressing of receiving units 14 is non-hierarehieal and may be installed 20 on the disk drive prior to shipment. Because ehanges may oeeur in the seheme, the addressing is down-loadable from host 52 and addressed by maehine-readable serial number.
Receiving units 14 can reeeive and store audio or video files.
Bit-mapped graphic images, such as icons, radar data, and base maps, are received and stored in the JPEG compressed format. The quality (Q) factor of the image are m~int~ined at 25 80 percent, or better.
For National Weather Service (NWS) text bulletin data, receiving unit 14 seleetsbulletins to be stored in the ~t~b~ce based on the passing or failure of two filters: bulletin type and station list (Universal Generie Code or UGC) embedded in the WMO header (such as WFUSI and GAZ032, respectively).

CA 02266~98 1999-03-lg WO 98tl5122 PCT/US97tl7412 If a particular receiving unit 14 is interested in that bulletin type, it then parses the station list embedded in the WMO header. If the station list parsed out of the message matches a station in the receiving units' 14 interest list, it is stored in selected receiving units 1 4 ~l~t~hace A quality control routine is performed for confirming time. If the bulletin has expired, e.g., the expiration time stamp in the UGC is less than the current Zulu time, the quality control routine rejects (ignores) the message.
Certain bulletins receive special proces~ing. Special NWS-defined delimiters cause ~ certain blocks of information to be stored and displayed in one of the many effects 10 enumerated earlier. For example, a NWS Zone Forecast may contain a header that warns the public of existing watches and warnings. A process parses the useful information, stores it, and creates a special display effect such as crawl, scroll, or other appropriate format.
Properly delimited headlines used in NWS bulletins such as Nowcast, Short Term Forecasts, and 36-Hour Forecasts, are parsed out of the bulletins and stored as separate entities.
Tabular data is alpha-numeric weather condition and forecast information. Each tabular data type, e.g., Regional Forecast, Hourly Observations, etc., is accepted and stored by the receiving unit 14 based on the following: The message is a valid tabular data type, or a station in the interest list exists that matches the slation field contained in the tabular record.
All data types stored in a receiving unit 14 ~t~b~ce are time stamped by the origin~ting system. Time-stamps use the Universal Coordinated Time (UCT) or Zulu(GMT) forrnat. All ~WS tabular data types expire in the database after a specified time period. The Product Team is responsible for determining the life cycle for each data type. All NWS narrative data types are deleted upon expiral:ion of the bulletin specified in the UGC
time-stamp field. All local video and audio products recorded on receiving unit 14 have an expiration time-stamp. At the end of a product's clefined life cycle, receiving unit 14 defaults to a local forecast flavor if the system does not detect an updated or new local specific product.
Clock messages for host 52 cause receivinp unit 14 to update the time. All clockmessages are in UCT or GMT format. The clock remains on the screen in a given format despite the ch:~nging background. Receiving unit 14 supports configurable time formats CA 02266~98 1999-03-19 wo 98/15122 PCT/US97/17412 (both I 2-hour and 24-hour). This feature allows the installation of receiving unit 14 anywhere around the globe. The clock is used to generate a date and local time display, to confirm values on data received and to time-stamp locally acquired products, if any. The clock is capable (under software control) of interfacing directly with the video output for on-5 screen displays. Each receiving unit 14 maintains an offset-value in its database, allowing the calculation and display of local time on-screen. Receiving unit 14 supports update-cycles occurring as frequently as five-minute intervals. The update cycle is not hard coded, but configurable.
Receiving units 14 support animation ~appear as pass-through) of radar images stored 10 in receiving units' 14 database. Receiving unit 14 displays images one frame at a time at a controllable and programmatical rate. Receiving unit 14 m~int~in.c a table of radar images for a specified number of hours. The number of radar images stored is configurable. After a given interval, each radar image is deleted. The table is in ascending order based on the time-starnp embedded in the radar image.
Receiving unit 14 interrogates the radar information upon receipt for data that exceeds a given threshold. A flag indicating whether or not the value has been exceeded is stored in the system and accessible to the playlist inte~ Le~. If the threshold is exceeded, receiving unit 14 generates a different playlist. Thus, a radar image showing a high density of high intensity returns may generate a severe weather warning. Because the quality of radar data is 20 not controlled by its provider and the data may need to be adjusted depending on the seasons of the year, each receiving unit 14 has a mech~ni~m to filter out specified radar levels (color levels).
When a valid warning message for the area is received, receiving unit 14 creates a map, either as a bug or radar base map, that fills the affected counties with a specified color.
25 When the warning expires, the map goes back to its normal, unfilled, state. Valid warning/advisory messages are stored and placed in a crawl for display. The colors of the font background may correspond to a given warning/advisory type. For example, warnings may be displayed in red, watches in yellow, snow/cold in blue. Receiving unit 14 generates an alert tone or plays a pre-recorded audio file for each warning/advisory type. Also, each CA 02266~98 1999-03-lg receiving unit 14 has information on warning/advisory types currently in effect! allowing it to change the local forecast product depending on the type of warning/advisory Convective warnings (severe thunderstorm, tornado, and special marine) generate a short (abbreviated) form of the warning message based on the fields contained in the WMO
5 header. For example:
WFUSI = Tornado Warning GAC013 = Cobb County, Georgia 121645 = ~xpiration date and time The resultant message would be as follows: "A tomado warning is in effect for Cobb County 10 until 4:45 PM EDT. Stay tuned for details."
Receiving unit 14 support four modes of operation: Normal, No-Video, No-Data, and Reset. Norrnal Mode is the typical operating mode of receiving unit 14. It is m~int~ined until receiving unit 14 fails to receive a valid data packet for one minute, if the satellite video is lost for 45 consecutive video frames (defined as loss of genlock), or if data is received to 15 force receiving unit 14 to another mode. In norrnal mode the control of receiving unit 14 remains with the host.
No-Video Mode is entered if receiving unit 14 fails to receive satellite video for 45 consecutive frarnes. When the No-Video Mode is e ntered, receiving unit 14 is forced into a playlist designed by the product designer/programrner. No-Video Mode is canceled when 20 satellite video is restored for the required period of time and data is present. In a receiving unit 14 equipped with telephone line access, the diagnostic routine contacts the production headquarters after detecting the No-Video condition for fifteen minutes.
No-Data Mode is entered when a receiving unit 14 fails to receive clock or data for one minute and after a successful Reset. ~hen No Data is entered, receiving unit 14 is 25 forced to call a run playlist designed by the product designer/programmer. No-Data reverts to either No-Video or Normal Mode when receiving unit 14 receives sixty consecutive error-free frames, and when a complete program is resident in memory. After 15 minutes of No-Data, a receiving unit 14 equipped with telephone line access contacts the tr~n~mi.c~ion source.
The Reset Mode is invoked in one of three ways: (1) A reset command from host 5230 in which a manual reset command results from pushing the Reset button on the Main CPU

CA 02266~98 1999-03-19 Wo 98/15122 PCT/US97/17412 (2) Loss of AC and DC power where, if the start-up test procedure passes, receiving unit 14 mode changes to No-Data. (3) lf the start-up test fails, the sequence recycles.
A downloading procedure is also provided. Normally, the most recent version of the system software is installed on the disk before delivery. However, it may be necessary 5 occasionally to download new versions of the software.
Message frames cont~ining downloadable software, if correctly received at receiving unit 14 and identified as having a different version number from the current operating module, are stored on the disk. Frames incorrectly identified as having the current version number are rejected. New software is marked as "Unusable" until all frames are correctly 10 received. Database objects (playlists, configuration, interest lists, addressing table, tabular weather data, narrative weather data, graphics, etc.) is buffered temporarily before committing them to database. The system checks to see if the object is in use (currently referenced). If the object is being used, it is marked as "locked," and waits in the buffer until the working version is marked as '-'unlocked." When it becomes "unlocked," the object is 15 deleted from the database and the new version is stored. Digitized video objects, not pass-through video, is stored on disk in either a compressed or uncompressed format. Version-control need not exist, but the object is not marked as complete until all frames have been received from the host.
Receiving unit 14 supports a terminal interface (TTY). The interface allows 20 receiving unit engineers and programmers to interrogate d~t~b~es, perform self tests, change configuration items, check current version numbers of software, check physical serial number of devices, and override serial numbers. A transaction log is m~intAined for tags, weather warnings, and receipt of local forecasts. The log is accessible through the terminal interface and stored on disk. The log is purged at a programmable interval specified by the operator.
If serious errors are occurring on receiving unit 14, it will, if accessible by modem, send a notification message back to the operator. Two passwords are m~int~ined by the receiving unit database to use the interface. One is a "privileged" password for the operator allowing full access to all .l~t~ce elements. The second, a "non-privileged" password, is for ~ffili~tes permitting limited access to certain functions, such as crawl creation and scheduling.

,, .. ~

CA 02266~98 1999-03-19 Wo 98/15122 PCT/US97/17412 The affiliates can change their password, which is initialized to a default setting at the time of installation.
Using the interface specified above, affiliates are able to create a plurality of crawls.
An edit function allows operators to create, update, and delete messages, and affiliates can also activate and schedule messages. The scheduler is designed to allow the cable operator to specify the frequency of the crawl rotation or indicate that the crawl is to rotate every other local forecast segment. The default setting specifies the crawl rotation frequency. Receiving unit 14 m~int~in~ a log of when a crawl was active. This feature assists ~ffili~tes in billing their clients. Local Ad Sales text messages are capable of effects other than crawl, such as 10 fold, dissolve. and flip. The product developers decide what effects are used to display the message.
Receiving units 14 are provided three software-controlled TTI, contact closures.These closures can be used for inserting local commercial or weather warnings. The contact closures are on the Data Ingest Board.
Operation of the System As illustrated in FIGS. 10 through l lH, the processes which operate throughout system 9 are broken into a number of modules, each having distinct tasks. In order to facilitate complete modularity of design and facilitate the division of labor that accompanies 20 such a design, system 9 incorporates the concept of a "software plug." Software plugs 1 32A-n are based on Sockets, a UNIX O/S construct that has become popular with the growing influence of the TCP/IP based Internet. FIG. 12 illustrates the socket classes of system 9.
In order to provide module interchangeability and ease of use, software plugs 1 32A-n are provided in between each of the modules. Software plugs 1 32A-n provide connectivity 25 and safe transport of data from one process space to another regardless of whether that process space resides on the same m~hinP or another. In order to perforrn this function, the data proceeds down through three layers of the source socket and up again through the destin~tion socket. Referring to FIG. 13, a software plug 132 has three layers: packet type 134, packetizer 136, and socket 138. The process flows as follows: The application fills 30 packet type 134 with the appropriate data. The data is then serialized at packetizer 136, . . ..

CA 02266~98 1999-03-19 meaning that the data elements are strung together into a stream. Once streamed the data is framed into 512 Byte segments~ assigned a message number and segment number and transferred to socket 1 3X for tr~n.cmi~cion. Once transmitted the process is the opposite at the receiving side. Socket 138A receives the frame which is passed to packetizer 136A where it is reassembled. Once assembled the stream is deserialized and the elements are again populated into structure 1 34A for use by the application.
Software plugs 1 32A-n allow for standardization of objects and allow the programmer to select the communication system used based on line quality. In other words, sockets 138, 1 38A may or may not include error checking, depending on the connection type that is used.
10 For instance, if two modules are resident on the same hardware platform, sockets 138, 138A
may not employ error checking because line quality is assumed to be good. On the other hand, where the modules are located on two separate platforms and the potential for line degradation exists, error checking may be introduced at a level corresponding to the difficulty anticipated with the line quality.
Data in system 9 are stored in a structure or packet type. As illustrated in FIG. 14, three structures are defined for system 9:
The Universal Product Posti~ Structure. This structure contains the data and addressing information required to package data from external sources for use with system 9.
The Comm~nd Structure. This structure contains the blocks of data that make up files transferred to receiving unit 14 via virtual channels.
The STA~ Struct~lre. This structure contains the format for data as it is moved between modules making up receiving unit 14.
Each module in system 9 is based on a cornmon module. This module called 25 "appclass" contains all behavior common to the modules. The common functionalities are:
Signal ~n~lling Error/Even ~n~lin~
Configuration Files Basic Module Format Console Communications CA 02266~98 1999-03-19 System 9 is designed to be immune to underlying data bases. FIG. 15 defines the data base abstraction classes for system 9. The following file records are used in system 9:
Receiving Unit 14 Dynamic Information F~ile Record (See FIGS. 16-16A).
Receiving Unit 14 Mirror File Record Receiving Unit 14 ID File Record De-Queue Accumulation File Record Each module in system 9 contains a configuration record. There is only one configuration data base and one record for that data base, although the fields of the record are redefined for each module. The following tables illustrate the configuration records used in 10 system 9:
US Met Tabular Ingest Configuration Record Moon Phase 1 int Index phrase / icon list Sea Condition int Phrase list index Product Posing Module Configuration Record Re~uesterPort int Port Number for Requester Server Port Host Request Module Configuration Record QueueClientPort int Port Number for Queue Server Port.

Queue Server Module Configuration Record ~

CommandServerPort int Port Number for Comm~n-l PriorityQueue int Number of priority queues for this implementation jj Command Module Configuration Record ComandServerPort int Port Number for DeQueue De-Queue Module Configuration Record RequesterServerPort int Port Number for the product Posting Port.
Comm:~n-l~erverPort int Port Number for Queue Server Port.

CA 02266~98 1999-03-l9 W O98/15122 rcTrusg7117412 CAM Module Configuration Record - RequesterServerPort int Port Number for the product Posting Port.
CommandServerPort int Port Number for Queue Server Port.
int Product Server ~nd Host: As shown in FIGS. I l through 1 IB, data is received byproduct server 76. The data flow begins at the ingesters 140. The entry point into system 9 is ingester 140. Ingesters 140 provide an interface to the outside world for posting products of all types, converting them from their raw format into a Universal Product Posting Structure.
FIG. 18 illustrates the flow of information through. ingesters 140.
Ingesters 140 acquire the data and construct a data packet in a predetermined formats~
such as the Product Development Management System (PDMS) format. The PDMS packetincludes the data itself and other information about the data such as the address, the data length, the address length, the systems to which th,- inforrnation is to be posted, the priority of the data and the expiration date of the data.
The PDMS packets are then forwarded to product posting module 142. Here the datais held in various lists, each list being dedicated to one or more modules which acquire the data, such as host 52~ an Internet device, or other systems 192 that might be interested in the data.
As illustrated in FIGS. I lB and 19, product posting module 142 provides input into a dedicated queue from multiple sources of product data. For example US, meteorological data can originate in tabular 170, narrative 172, or map 174 file form. Each ingester 140 must package the product into a Universal Product Posting Structure and then must post that data to a single product posting queue 184 which is dedicated to a data requester, such as host 146, internet 192, etc.

CA 02266~98 1999-03-l9 The product posting process starts at the source of data, such as tabular 170, narrative 172, and maps 174. Assigned to each ingester 140 is an ingest task 176 within product posting module 142. Both ingest processes and ingest tasks 176 have configuration information indicating their Port ID's. Ingest tasks 176 have a client 178 to server 180 5 relationship with the ingest processes through software plugs 1 32A-B. A server socket simply means the UNIX port is owned and managed by the module and that multiple clients can attach to that port. The module connecting to the port is termed the client.Ingest task 176 accepts data packaged as PDMS construct. The PDMS structure is defined in the table below.

Source int Indicates the target queue number.
Priority int Indicates the priority.
Address char* Recipient STARaddress.
AddressLength int Length of address data plus termin~ting NULL
Data unsigned Product data char*
DataLength int Length of data ERStoreFlag int Indicates whether data is internally stored (T_ISTORE) stored externally from the packet (T_ESTORE) or stored remotely (T_RSTORE) ERStoreLength double Length of externally or remotely stored data EffectFlag int Data size has an effect of the total hard disk capacity of the receiving STAR, EFFECT_NOSIZE, EFFECT_SIZE
MessageNumber long Message Number MessageExpiration long Time at which the message expires.
CompressionFlag int Can data be compressed Segment ID long Segment for E_STORE transfers CA 02266~98 1999-03-19 WO 98tl5122 PCT/US97/17412 Source indicates the queue to which the product will be posted. The priority flag indicates the priority of the packet. These packets eventually are posted to a priority queue.
Address contains the full select statement and addresses of receiving units 14 to which the 5 data is targeted. Address length is the length of the address data. Data contains the data of the product. This can be one of two things, actual data or a pointer to remote or external data.
After blocking on a semaphore 182 for shared memory access, the packet is posted to queue 184. Ingester task 176 must accumulate the total data posted to queue 184 in order to track the total data in queue 184 at any one time.
Before the packet and its data can be posted to queue 184, ingester task 176 must do a look up in mirror file 154 and calculate the amounl of space required by the data. Some data on receiving unit 14 is pre-allocated and therefore has no effect on the overall disk space. In this case the Effect flag is set to EFFECT_NOSIZI.. If the size of the data must be calculated the flag is set to EFFECT SIZE. If the calculation is made and does indicate the data does not fit on receiving unit 14 an error message must be posted and the packet thrown away.
Queue 184 is a Standard Template Library :Multimap class. This class was chosen for the following reasons:
It allows Key and Data both to be stored.
It allows ordered insertions without sorting It allows ordered deletions without sorting Once packets are posted, the higher priority packets "float" to the top of queue 184 since the multi-map is keyed to priority.
The architecture on the requester side is very similar. Product posting requester task 186 is assigned to host requester process 146. They are connected by software plug 132D
where product posting module 142 acts as a server and host module 146 acts as a client. As shown in FIGS. I l B-C, the differences are two folcL. First, host module 146 sends a ready message when it is ready for the product posting requester task 186 to forward the first packet off the queue. Second, only one product posting requester task 186 runs per queue 190, unlike the Ingester Tasks 176 in which multiple tasks can post to one queue 184.

4g CA 02266~98 1999-03-lg W O 98/15122 PCT~US97/17412 Product posting requester task 186 also has the responsibility of posting a record to mirror file 154. After the packet is transmitted to host module 146 it is then written to mirror file 154. The elements required for mirror file 154 are specified in FIGS. 16- l 6A.
Product posting module 142 accommodates three types of data: Internally Stored S (I_STORE), Externally Stored (E_STORE), and Remotely Stored (R_STORE). Because there is the potential for very large arnounts of data, one of the pieces of inforrnation included in the PDMS packet is the l_STORE/E_STORE indicator. If the data packet is relatively small the data is labeled I_STORE, where the I signifies that the data portion is actually the data that is to be sent on to host 52 and eventually receiving unit 14. If the data packet is very 10 large, it is labeled E_STORE and stored on an external server. The E indicates that the data packet is merely a pointer which indicates where the data may be found. Internally stored data, or I_STORE data, is transferred via a single packet. Since I_STORE data is limited to 2- kBytes it can be sent in one packet.
When external data, or E_STORE data, is sent the process is different. First the15 PDMS packet entry is sent to product posting module 142 as it would be for any l_STORE
entry except for the fact that the E_STORE flag is set to E_STORE, the file name is contained in the data element and the E_STORE Length is set to E_STORE, the file name is contained in the data element and the E_STORE Length is set to the length of the file. After receiving the packet the product posting module 142 evaluates the E_STORE flag for the 20 value E_STORE. If this flag is true then ingest task 176 expects the file to follow in 2048 byte segments.
The file is posted by absolute file narne in a directory narne based on queue 182. The naming convention is:
~Current Directory]/queue[Queue Number]/[File Name]

For example, a file named 091502.96t. for queue 182 one be written to:

./queuel/091502.96t.

CA 02266~98 1999-03-lg Internally stored data is contained within the Universal Product Posting Structure.
This is usually f'ree from text data of the size that c.m be accommodated by the structure.
Usually text data should be limited to a configurable amount to insure that no single record eats excessive memory before it is cached to disk. Currently the system restricts internally 5 stored data to 10,000.
Exception handling - in the event that the queues contain too much data for the system to handle, the product posting requester task 186 purges all non-priority I data from the queue. The determination of how much data is too much is configurable, but when this threshold is met all data excepting priority I data is purged from the file. Currently 20 10 kBytes is the maximum I_STORE data length. If a port is lost, all ports should drop into a 10 second loop looking for connectivity when a port is dropped. Any port drops should be reported to the error log.
Product posting module 142 provides more ~han just a universal conversion of data. It provides a standard staging area for all commz~ and data that must be transported through 15 system 9 to receiving unit 14 or from one machine to another. The reason for this is that a product may contain many sub-products, all of which must be moved around in system 9 in varying degrees and transported over different comrnunication lines. Many products may not even need to be produced before being transported. Product posting module 142 provides a central repository or central control area for items to be manipulated on their way to their 20 final destination.
Host module 146 picks up the PDMS packet from the product posting module 142 and breaks it into two packets. The first packet is the address and the second packet is the data. This system allows receiving unit 14 to operate more efficiently. When the information gets to receiving unit 14 only the first packet is read. If the address indicates that the data is 25 for that receiving unit, it then proceeds to store that data that follows the address. If the address is not directed to that receiving unit, it ignores all data until the next address packet arrives. This is important because it saves time that would be required for the receiving unit - to parse through data. In order words, the receiving unit has only to parse, unpack or decompress the address packet to determine whether the data is directed at it. It does not 30 need to decompress or reassemble any of the data, which may be time consuming.

CA 02266~98 1999-03-19 As illustrated in FIGS. I l C and 20, host requester module 146 requests data from the product posting module 142 and processes into command packets to be transferred to queue server 148 to be staged for tr~ncmi~.sion.
Upon start up, host requester 146 opens its configured port for access to an assigned product posting queue 184. This relationship is over a software plug 132D with the product posting module 142 acting as a server and the host requester 146 acting as client. The system allows multiple requesters to be attached to product posting module 142, but each requester is married to one product posting queue 184.
- Host requester 146 receives a new message for processing. Processing in this case means compressing the data of the message, if necessary, and breaking the message into chunks of comm~n(l data.
Requester task 194 requests data from its assigned queue 184 in product posting module 142 which is fed to it via a PDMS structure. Requester task 194 uses two work areas in memory so that one can be loaded while the other is unloaded. First the requester task checks an 'A/B' flag 196 to determine which queue 190 is open and then begins to chunk data and load it into that queue 190.
In order to understand the chunking process, the anatomy of a command message isillustrated in FIG. I l D. Generally any message is broken into four layers - command layer 198, address layer 200, data layer 202, and optional file layer 204. Any message always contain address-200 and data 202 layer. Additionally if a file download is being executed it can be appended to the bottom. First, command layer 198 is written and the LayerFlag element is set to 0. Then the address 200 is broken into chunks of 512 bytes incrementing the segment number and setting the LayerFlag to 1 to indicate the address layer. Next the data is evaluated for length. If it exceeds 5 k Bytes, it first compresses the chunked into 512 Byte segments. Again the segment number is incremented appropriately and the LayerFlag is set to 2. If a file transfer is called for the host requester 146 sends a "RF" message loaded in the Data element of the PDMS structure. The table below defines the structure of the command data packets.

CA 02266~98 1999-03-19 WO 98/15122 PCT/USg7/17412 MëssageNumber long The message number Data/Message Length long Length of data/Total number of segments in the rnessage if LayerFlag=o.
- LayerFlag BYTE 0=Command Layer 1-Address Layer 2=Data Layer 3=File Layer Segment Number long The number of this 512 Byte segment Data void Data of the message Priority int* Massage Priority Once complete the Requester Service task sets the A/B flag to B and signals the queue server task 206 that data is ready on queue 190. Queue server task 206 transfers the message chunk by chunk to the queue server module 148 which in turn populates it into a queue based on 5 priority~
Once the PDMS packet is properly formatted, it is forwarded to the queue server 148 which has several queues, one for each class of data. Queue server 148 acts as a priority based staging ground for processed data ready for tr~n.~mi~sion to receiving units 14. FIG.
I lE illustrates the function of queue server 148.
Host module 146 establishes a client relationship via software plug 132E with queue server 148 where host requester service 208 thread requests pre-processed data chunks from host requester 146. Host module 146 provides messages as a series of command packets which are loaded into a queue.
There are three types of queues: Y-queue 156, C-queue 160, and one or more priority queues 158. C-queue 160 is the command queue. Messages in C-queue 160 go out irr~nediately after reception. The priority number of C-queue 160 is one. Y-queue 156 is the cyclical queue. Y-queue contains 156 the lowest priority data but the most critical data where lossiness is concerned. Files whose integrity must be guaranteed are placed in Y-queue 156 in order to be transmitted a number of times thus insuring error free transfer. Y-Queue 156 .. . ...

CA 02266~98 1999-03-19 WO 98/15122 PCr/USg7117412 priority number is two hundred and fifty six. Priority queues 158 accept a configurable number of priority messages. When configuring the system, the number of priority queues 158 can be specified. The number of priority queues 158 specified is for error checking only~
since any message entering queue server 148 that has an unallocated priority queue will, after 5 checking the number of queues, automatically have one allocated for it. Command module 150 provides the tr~n~mi~.~ion of comm~ntlc and data. This is its only function since this function is so important and susceptible to delay.
As illustrated in FIGS. I IE and 21, command module 150 requests data from queueserver 148 and transmits that data to De-Queue module 163 at receiving unit 14. Queue 10 server 148 feeds data to command based on a strict algorithm that insists that high priority data be cleared from queues 156, 158, 160 as a soon as possible. As discussed in previous sections, commands can be sent through the system origin~ting at any ingester 176. The problem that arises is the delays imposed by processing. Some commands require close coordination between broadcast production where delays of a less than a second are unacceptable. Therefore the command task 216 is assigned a schedule log 152 so that real time comm~n-lc can be sent in the quickest and most efficient manner possible.
Schedule log 152 accepts comm~n~ from the automation system 72. These comm~n~l~ are be executed at a particular time by impulse from a binary switch, also origin~ting from the automation system 72. Command task 216 attempts to anticipate the next command and insures that it has time to clear the passageway to de-queue module 163.
Comm~nd module 150 sends commands from schedule log 152 and data from product posting module 142 to receiving unit 14 whose address it gets from the High Speed Addressing File. Command module 150 periodically runs through queues 156, 158, 160 and selects the data according to a set of rules.
Product data comes in three forms based on priority. The first source of product data is weather warnings and comrnand data that must go out to receiving unit 14 immediately -this is C-queue 160 data. The second form of data is standard Meteorological Data which, although perishable, can get to receiving unit 14 in a reasonable amount of time after C-queue 160 data have been sent. This is priority queue 158 data. The final form of data that must get to receiving unit 14 is programs, products, and configuration information, i.e., Y-queue 156 CA 02266~98 1999-03-19 wo 98/15122 PCT/US97/17412 data. Cyclical data is sent over and over again in predetermined cycles to insure that it gets to receiving unit 14 in error-free form.
Host module 146 increments through the product posting module 142 on product server 76 looking for priority queue and Y-queue data. If these types of products are found - 5 and they are in excess of 4096 bytes then they are compressed. The compressed product is broken into transfer packets of 512 KB with a 64-bit CRC appended. Each transfer packet is then written to the appropriate queue priority data is ~,vritten to priority queue 158 and cyclical data is written to Y-queue 156.
An exception is made for C-queue data. If this type of data is written to the product l 0 posting module 142, a trigger is called that interrupts host module l 46 and passes it a physical record address. Host 52 records its current increment and goes directly to the record in question and posts it to C-queue 160. Once posted, the host module 146 continues at the previous increment.
An example of C-queue data is priority command data, i.e., data that must be sent to receiving unit 14 in real-time. Real-item commancl data originates in MDS 68 and is written to the Schedule Log 152. Also, any changes to log 152 are posted to host 52 from MDS 68.
Schedule log is a queue with a pointer to the current comm~nd An additional General Purposes interface (+5,0 volts) ori~in~ting at automation system 72 goes high in order to signal host 52 to increment its command pointer and to send the command located there.
Command module l S0 responds immediately to the signaling of real-time priority data by the movement of the schedule command pointer. Command module 150 checks the priority command queue 160 for information. If there is inforrnation there, it sends it until queue 160 is empty.
When the priority command queue 160 is empty and schedule log 150 is not incremented, command module 150 checks priority queue l 58. If there is information there it sends a packet, then checks for new priority comm~md data. If no priority command data exists and no schedule interrupt is received, then cc,mmand module 150 sends the next packet.
It essentially sends a packet of data and checks important priorities, if no important priorities exist it sends another. Finally, the monitoring of cyclic queue 158 works essentially the same .. . . ~ .

CA 02266~98 1999-03-19 WO 98/15122 PCT/US97tl7412 as with priority queue 158 except that if any priorities exist above it they are completely serviced before any cyclical packets are sent.
Command module 150 also looks to schedule log 152 of MDS 68 and, if it notes that an event is coming which will consume tr~n.smi~sion bandwidth, it may decide to hold the transmission until impending events are over.
There is also a receiving unit mirror file 154 located on the product posting module 142. This file records everything that is sent out to each individual receiving unit 14. It then creates a log of everything that is resident on the receiving unit 14. This is necessary because the transmission system is an open loop which does not allow the system to know whether the 10 data transmitted was ever actual received by the receiving unit 14. Thus, receiving unit mirror file 154 allows the system to know how full the hard drive of the receiving unit 14 is and if necessary send. delete or erase commands to elimin~te stale data so that new data may be transmitted.
The Receiving Unit: As illustrated in FIGS. I lG-H and 22-26, receiving unit 14 has 15 four modules - de-queue module 163, command application module (CAM) 162, presentation application layer (PAL) 164 and hardware abstraction layer (HAL) 166.
As illustrated in FIG. 11 G, de-queue module 163 is~the entry point for the system into receiving unit 14. It deals with receiving, interpreting, assembling, and transferring packets from and to command module 150 and CAM 162.
Data messages are broken into command packets and stored in queue server 148.
Packets are stored in a single message made up of two sections. The front section is the address section and the back section is the data section. Each section is broken up further into frames of 512 bytes. Since command module 152 can remove packets with different message numbers from the queue 148 it is possible for the packets to be interleaved De-queue 25 module 163 therefore performs two tasks - first it resolves addresses for receiving unit 14 and then reassembles packets into messages if they are targeted a the particular receiving unit 14.
Command module 150 opens a client relationship through a software plug 132G withde-queue server 163. The message top is reassembled in a disk queue and evaluated for true by look up in the Interest List section of Dynamic Inforrnation File 220. If the message is 30 intended for the particular receiving unit 14 then de-queue module 163 continues to build the CA 02266~98 1999-03-19 message from the incoming packets. If the message is not intended for the particular receiving unit 14, then any received packets are discarded.
When messages are complete they are transferred to CAM 162 through software plug132H after being converted to a data packet, as ilhlstrated in the table below. The relationship between CAM 162 and de-queue 163 is one of "Priority Request." First, CAM
162 indicates to de-queue module 163 when it is ready to receive any message by transmitting a ready string. This ready string can be of two types. The first is "RA" which means 'ready for all messages.' This indicates that CAM 162 is not extremely busy with other tasks. The other possible flag is an "RC" which indicates that CAM 162 can only 10 receive command messages. This flag indicates that receiving unit 14 is probably in broadcast production and cannot be disturbed except for the most important information.

Target - HAL char*32 Indicates the target HAL for the Message.
Data void* Data of the message.
Data Length long Length of data.

De-queue module 162 accepts messages from command module 150 based on the top of the 15 message which is addressing information. Addresses are evaluated in the following format:
SELECT [ALL,*] [WHERE [FieldName] [=,=>,c=,!=]
[FieldValue 1] [OR,AND] [FieldValue ..n]]
The above expression simply states that the address is to select all (alternatively*) receiving units 14 that meet the certain qualifications. The SELECT ALL statement by itself has the 20 effect of broadcasting to all receiving units 14 in the field. For example SELECT *
and SELECT ALL
would have the effect of passing the message to all receiving units 14 in the field since it 25 would be evaluated as true.

CA 02266~98 1999-03-19 The SELECT statement can be modified by the WHERE token to indicate that the whole statement needs to be evaluated for TRUE. The queue evaluates a ~ïeldName for a some operation of a Field Value. This means that the ~ieldName can be evaluated as being equal to, less than, more than, or not equal to, a particular value. For example, SELECT * WHERE MOUNTAIN_COUNTRY = 1 would pass in receiving units that had the Field Narne MOUNTAIN_COUNTRY set to a value of I . Alternatively SEL3~CT * WHERE MOUNTAIN_COUNTRY ! =
would pass in all receiving units 14 not containing the Field Name MOUNTAIN_COUNTRY
set to a value of 1. SELECT parameters can be compound also.
As illustrated in FIG. I lH, CAM 162 provides data base updates and communications routing services for the many modules running in front and behind it. All communications traffic is routed through CAM 162.
CAM 162 accepts data and command concurrently from two sources: the standard satellite command feed from command module 150 and the service terminal 86. Each of the data feeds must interface with a separate de-queue module 163 married to the port of entry.
Both attach to CAM 162 via software plugs 132H-I.
After filtering messages not intended for receiving unit 14, de-queue converts the command data packet into a receiving unit data packet and forwards it to CAM 162.
CAM 162 responds to a limited number of commands. One set of comm~n-l~ tells CAM 162 to send the data to presentation application layer (PAL) 164. The second set of commP~n-1~ tells CAM 162 to send the information to hardware abstraction layer (HAL) 166.
PAL 164 is a interface between CAM 162 and presentation engine 168. This allows presentation engine 168 to be replaced easily.
HAL 166 consists of multiple layers which are small modules that can be written and run from CAM 162, including such desirable utilities as defragmentation routines, debugging routines, etc. By using many layers, each utility or function is a small piece of software. This allows new software to be easily downloaded to receiving unit 14 over the tr~n.~mi~sion signal.

CA 02266~98 l999-03-l9 WO 98/15122 PCT/US97tl7412 CAM 162 contains application modules that provide most of the external activity of receiving unit. Commands enter the system in the SQL Command Query language subset.
Configuration and weather data entering the system is written to the Dynamic Inventory File (DIF) 220, illustrated in FIG. 27. A.lso as the inforrnation in this file is need 5 for other processes, chiefly the presentation software, this layer provides access to the DIF
220 records. It is from CAM 162 that the third party presentation layer is called~ executed, and monitored.
HAL 166 contains kernel modules that service and monitor the system at the lowest level. The following modules make up this layer:
Disk l\~n~ement. Due to the heavy disk usage in multimedia applications and to the fact that receiving unit 14 is an automated system the hard disks must be constantly monitored and serviced. This module monitors for disk problems in low periods and de-fragments in off times.
Di~nostics. Very low level diagnostics must be performed periodically and during15 certain events, such as the completion of a presentation to ensure that memory leaks have not occurred. This module performs diagnostics in an automated fashion or can be called by the Service Daemon for remote debugging.
The Dynamic Inventory. All inforrnation involved in the system is reduced to a dynarnic inventory. The configuration of DIF 220 is a flat indexed database which consists of 20 two fields - Field Identifier and the Field Value. The relationship between receiving unit 14 and product server 76 is shown in FIG. 16- 16A.
The Field ID and Data are meaningful depending on the context of the data. FIG. 29 illustrates the data types used by system 9. If the data is program data, the Field ID represent a running program. If the data is weather data, the F ield ID represents display data. This 25 strategy provides an extremely simple design where the DIF 220 requires only three fields per record. This file allows the entry of new data types facilitating the expansion of product and weather data that can be presented and the number of effects that can be displayed. The format of DIF 220 is illustrated in FIG. 27.
The parent record contains four fields as listed in FIG. 28 and the child contains one 30 field listed in FIG. 28, as well. The above design accommodates variable length data by CA 02266~98 1999-03-19 breaking the data into segments. This approach has a further advantage in that DIF 220 can be pre-allocated on the receiving unit 14 hard disk Other modules may be included in HAL 166 as appropriate or necessary for the operation of receiving unit 14.
Each receiving unit contains elements of configuration data. This data mostly tells receiving unit 14 who it is, where it is, and how its hardware and software should be configured. Data is transmitted to all receiving units 14 during any command transmission.
In order to direct specific data to a receiving unit 14 the address must be contained in the message. If the receiving unit "sees" its address in the message packet, it "knows" that the 10 message is directed to it.
DIF 220 keeps track of local conditions, forecasts, and notifications. This information is combined with the effects to produce the local weather products. DIF 220 keeps a list of utilities that are HAL I 66-compatible. A record of where the prograrn is located is required to execute these programs remotely.
Receiving unit 14 must ingest all of the data being transmitted by host 52. First the incoming packets must be disassembled then the address header is resolved by a lookup in the DIF interest list to deterrnine whether the message is intended for the specific receiving unit 14. This activity takes place at CAM 162. If CAM 162 deterrnines that the message is intended for it, it then determines what type of data it is being sent by evaluating the SQL
comm~nd There are only three possible comm~n(l~ - one to set data values, one to execute a HAL/PAL command, and one to execute a CAM command - just as in any SQL language.The format for setting a value is as follows assuming there is a DIF element named CURRENT_TEMP
CURRENT_TEMP = 7 0 CAM 162 determines that the message is intended to set a value in the DIF file. CAM
162 first looks for the DIF FID. If the DIF FID is not present it then adds it and sets the value. If the DIF FID is present it simply replaces the current value.
The format for executing any command is as follows.

CA 02266~98 l999-03-l9 Assuming that AD01 is a product (say current observations). CAM 162 looks up AD01 in the DIF file with the understanding that since it was preceded by a CALL statement that either a command is sent to the HAL 166 or PAL 164. Once found, CAM 162 evaluates the data type. If the data type is a program the command is sent to HAL 166. If the data type ~ 5 is product then the command is sent to PAL.
Some commands CAM 162 recognizes imrnediately. Those commands are listed in FIG. 30. Commands set to HAL 166 are intended to executed custom modules. These modules are developed on top of a common platfor~n so that they can report information back to CAM 162 via software plug 132.
Commands sent to PAL 164 are intended to either CAM 162, a product or to executeone of the limited comm~n~ PAL 164 understands. Commands PAL 164 understands areshown in FIG. 31. PAL 164 executes products by passing the command to the Presentation Engine 168. Any monitoring information that musl be passed back to CAM 162 is sent via queue-socket 132.
Although the foregoing is provided for purposes of illustrating, explaining and describing embodiments of the present invention, modifications and adaptations to these embodiments will be aL)parent to those skilled in the art and may be made without departing from the scope or spirit of the invention.

Claims (8)

What is claimed is:

1. A method for distributing weather related video programming to each of a plurality of geographically disparate locales comprising the steps of:
a) collecting meteorological data from each of the locales;
b) transferring the meteorological data to a central processing facility;
c) formatting the meteorological data to create programming products;
d) transmitting the products via a transmission channel to information distribution centers in each of the locales;
e) dynamically scheduling the transmissions to optimize utilization of the channel; and f) selectively displaying, via the information distribution centers and in accordance with geographic criteria, the products to provide weather-related video programming specific to each of the locales.

2. The method of claim 1 further comprising the steps of a) providing non-meteorological programming products;
b) transmitting the non-meteorological products via a transmission channel to information distribution centers in each of the locales;
c) dynamically scheduling the transmissions to optimize utilization of the channel; and d) selectively displaying, via the information distribution centers and in accordance with non-geographic criteria, the non-meteorological products to provide video programming specific io each of the locales.

3. The method of claim 1 in which the step of dynamically scheduling the transmissions further comprises maintaining a record of all products sent to each distribution center and a schedule of activities for each distribution center.

4. A system for distributing information to a plurality of receivers in which the information comprises a first portion to be received and processed by all of the receivers, a second portion which further comprises a plurality of combined data subsets each having a first address packet and a data packet, in which selected combined data subsets may be addressed to selected receivers and a third portion which further comprises a plurality of bifurcated data subsets, each having a second address packet and an associated data stream, in which selected bifurcated data subsets may be addressed to selected receivers, the system comprising:
a) a production system responsive to an automation system and which transmits the first portion and the data streams of the third portion through a first channel;
b) a host responsive to the automation system, and which transmits the second portion and the address packets of the third portion through a second channel;
i) in which each receiver receives the first portion and delivers it to a corresponding re-distributing system;
ii) in which each receiver receives the second portion and, if the first address packet of one of the combined data subsets corresponds to an address of a particular receiver, the particular receiver periodically selectively interrupts delivery of the first portion and processes and delivers the data packet of the one of the combined data subsets to the corresponding re-distributing system;
iii) in which each receiver receives the third portion and if the second address packet of one of the bifurcated data subsets corresponds to the address of a particular receiver, the particular receiver receives the data stream associated with the address packet; and c) a dynamic scheduler which coordinates the transmission of the data stream and the second address packet of the third portion, the dynamic scheduler further comprising a record of all information sent to each receiver and a schedule of functions to be performed by each of the receivers.

5. The system of claim 4 in which the receiver passes the data stream through to the redistribution system.

6. The system of claim 4 in which the receiver stores and processes the data stream.

7. The system of claim 4 further comprising a two-way communication link between and the receiver through which the scheduler queries the receiver in order to create the record.

8. The system of claim 4 in which the scheduler creates the record by maintaining a record of all information transmitted to the receiver and all scheduling commands transmitted to the receivers.