WO1997034384A1

WO1997034384A1 - Broadcast system using adaptive data structure

Info

Publication number: WO1997034384A1
Application number: PCT/US1997/003820
Authority: WO
Inventors: Tsutomu Takahisa; Koyo Hasegawa
Original assignee: Digital D.J. Incorporated
Priority date: 1996-03-13
Filing date: 1997-03-12
Publication date: 1997-09-18
Also published as: AU2076197A

Abstract

A broadcast system includes a device to compare program material to be transmitted with a database of known material, and to transmit along with the program material data corresponding to that program material. A corresponding receiving system stores the data in memory and displays, at the selection of the user, the data corresponding to the program material. The user selectively stores the data on a magnetic recording card for electronic coupon or other uses. Various modes of operation are selectable by the user, and the data may be used as electronic coupons, or to control attached equipment, or to sound alarms, or for other applications. Broadcast of the associated data commences earlier than that of the program material so that such data are available for display on a receiver when the program material is first received. The receiver is connectable to remote terminals for the collection of information relating to a user's pattern of storing and accessing the broadcast data. The receiver is implemented as a module that is connectable to displays of various sizes, and the receiver self-configures so that the signals it sends to the display are appropriate for the size of the display.

Description

BROADCAST SYSTEM USING ADAPTIVE DATA STRUCTURE

BACKGROUND AND FIELD OF THE INVENTION

This invention relates generally to broadcasting systems, and specifically to a system for transmitting data associated with audio or video program material to provide a listener or viewer with useful information regarding the program material. Many radio broadcast systems are known to exist in which digital data are transmitted along with audio program material. For example, the United States Radio Broadcast Data System ("RBDS") Standard, published by the National Radio Systems Committee and sponsored by the Electronics Industry Association and the National Association of Broadcasters, describes a system for broadcasting a variety of program- related information on a subcarrier of a standard FM broadcast channel. The RBDS standard teaches a system for transmitting station identification and location information, as well as time, traffic and miscellaneous other information. U.S. patent no. 5,491,838 to Takahisa et al., the contents of which are incorporated herein by reference, discloses a system that automatically recognizes program material being broadcast and transmits associated data related to such program material. For instance, if a musical piece is being broadcast, data concerning the composer and performers of the piece are also broadcast.

One hurdle to be overcome by any broadcast data system is the constrain imposed by the limited bandwidth allocated to the data transmission in the system. Currently, modern transmission systems permitting the simultaneous broadcast of data along with program material on a single FM broadcast radio channel are limited to a data rate of approximately 16 kilobits per second. This limitation constrains the amount of associated data that can be broadcast within any given time period. Another practical constraint on broadcast data systems is the amount of memory, if any, provided for such data at a receiver. In one possible configuration, a receiver has no memory whatsoever and simply displays data as they are received. Greater usefulness is achieved by permitting the receiver to store received data in a memory, either upon user command or automatically. In known systems, user command storage operates when the user of such a receiver is provided with a button or other selection means for actuation when data that may be of later use appears on the display of the user's receiver. For instance, such information might take the form of an ordering number for a compact disc from which the currently broadcast program material comes. Known systems providing automatic storage accumulate the associated data as it is broadcast, and using a fixed data structure permit user selection among such data.

Although the cost of memory device has declined markedly in recent years, it remains beneficial to reduce the cost of receivers by minimizing the amount of memory that they carry. For instance, in order to make moderately priced receivers capable of decoding both program material and associated data, it may be reasonable to impose an upper bound of 1 megabyte of data memory for such receivers. Using known systems and techniques, this effectively constrains the type and amount of data that can be usefully transmitted with the program material.

Notably absent from the known art is a system for broadcasting program material and associated data that overcomes the inherent constraints of data channel bandwidth and available memory to increase the amount and type of data that can be provided to users of corresponding receivers.

SUMMARY OF THE INVENTION In accordance with the present invention, a broadcast transmission system includes a conventional source of program material, a data encoding processor for adaptively constructing a data structure in response to selected parameters, and a transmitter for transmission of the program material and a data stream corresponding to the data structure.

In another aspect of the invention, the selected parameters include the time of day, weather conditions, the type of program material being transmitted, or advertising traffic. In still another aspect of the invention, the data encoding processor includes a refresh rate calculator for adaptively refreshing data in the data stream in response to the selected parameters. In yet another aspect of the invention, the data encoding processor includes a data depth calculator for adaptively determining a depth for the data structure in response to the selected parameters.

Also in accordance with the present invention, a receiver includes a program material decoding processor for reproducing transmitted program material, and a data decoding processor for adaptively decoding transmitted data in response to selected parameters.

In another aspect of the invention, the data decoding processor includes a data structure decoder for determining a structure pursuant to which the transmitted data were transmitted and for processing the transmitted data according to that structure.

Instill another aspect of the invention, the data decoding processor includes a data caching processor for determining user characteristics and storing portions of the transmitted data responsive thereto.

Also in accordance with the invention, a method of transmitting program material and data includes adaptively determining a data structure for the data in response to preselected conditions.

Further in accordance with the invention, a method of receiving transmitted program material and data includes selectively storing portions of the data in memory in response to user characteristics. The features and advantages described in the specification are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of a system (100) for transmission and reception of program material and associated data, in accordance with the present invention.

Figure 2 is a block diagram of a data encoding processor (113), in accordance with the present invention. Figure 3 is a flow diagram of setup processing for data encoding, in accordance with the present invention.

Figure 4 is a flow diagram of data encoding, in accordance with the present invention. Figure 5 is an illustration of an exemplary data structure used in accordance with the present invention

Figure 6 is an illustration of a data decoding processor, in accordance with the present invention.

DESCRIPTION OF A PREFERRED EMBODIMENT

The figures depict a preferred embodiment of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

Referring now to figure 1, there is shown a transmission and reception system 100 in accordance with the present invention. The operation of the transmission and reception system 100 is illustrated by discussion of the component parts illustrated in figure 1. In a preferred embodiment, a transmission system 110 uses conventional audio sources such as microphones, compact disc players, and tape cartridge players interconnected through a conventional audio mixing board, collectively referred to as program material source 112, provide program source audio to transmitter 11 for transmission via antenna 124. Examples of program material source 112 and transmitter 111 are disclosed in U.S. patent no. 5,491,838 to Takahisa et al, the contents of which has been incorporated by reference above. A receiver 120 includes a conventional antenna 124, a demodulator 121, program material decoding processor 122, and data decoding processor 123. Except as otherwise discussed herein, the subsystems of transmission system 110 and receiver 120 are implemented in a conventional manner using known circuitry. Data encoding processor 113, discussed in greater detail below in connection with figure 2, accepts and processes data to be transmitted with the program material provided by program material source 112. Such data may relate directly to the program material, for instance by way of text naming a musical piece currently being broadcast, its composer and performers, the record label and ordering information for the piece, its lyrics, a biography of the composer or performers, etc. In other applications, non-text data may also be transmitted, such as a digitized still or video picture or other graphic of the composer or performers. In addition, or even instead of such data related to the program material, unrelated data may also be broadcast. For example, text data providing weather or traffic reports, stock quotes, or advertising may be transmitted, depending on the wishes of the broadcaster.

The amount and type of data that a broadcaster wishes to transmit may change depending on an almost infinite number of factors. A primary constraint is available bandwidth for transmitting such data. Systems currently authorized for transmission on subcarriers of U.S. broadcast band FM radio channels are typically limited to less than 20 kilobits per second of data. This fundamental constraint gives rise, in turn, to other constraints. For instance, if a musical piece such as a popular song is only three minutes in length, and if it is considered acceptable to send data corresponding to the musical piece only once during the piece, a limitation of 2880 kilobits of data is imposed for data associated with that piece. Typically, it would be desirable to send such data not once but several times during a musical piece so that listeners tuning in midway through the piece can get data and so that data errors resulting from noisy transmission can be corrected. Thus, accounting for desired redundancy in transmission, it may only be desirable to transmit text or graphics totaling 1000 kilobits or less of data during such a musical piece.

Still another factor impacting the type and amount of data that a broadcaster will want to send is the time of day. Early in the morning, traffic and weather data may be most important to listeners, so broadcasters may want to use a significant portion of the data capacity available to them for frequently updated textual or graphical traffic and weather reports. Listener interest in traffic reports may significantly decrease later in the morning, only to increase again in the mid to late afternoon. During times when data demands are not at a peak, broadcasters may find it advantageous to transmit data corresponding to advertising promotions in order to maintain listenership. For instance, in one application a broadcaster may offer to broadcast, over a number of minutes, a digitized picture clip from a new motion picture that may be of interest to listeners. Alternatively, for properly equipped receivers the broadcaster may transmit a free software program that users can transfer from their receiver to their home computer. These examples illustrate that both broadcasters and listeners have data needs that are not fixed, but that instead may vary significantly with time. Since both data channel capacity and available receiver memory are practical constraints on the presentation of such data to users of receivers, a conventional fixed data structure for the transmission of such data is found to provide only a compromise solution that does not maximize the possible data throughput and usage of broadcast data systems.

Referring now to figure 2, there is shown the principal components of the data encoding processor 113 illustrated in figure 1. Data encoding processor 113 includes a data source subsystem 220, a data refresh rate calculator 212, a data depth calculator 213, and a data structure generator 214. Data source subsystem 211 provides and prioritizes data to be broadcast by transmission subsystem 110. In a preferred embodiment, data source subsystem 220 provides data from a number of sources. An automatic program material recognition subsystem 221, implemented in a known manner as described, for instance, in U.S. patent no. 5,491,838 to Takahisa et al., provides text or other data related to program material that is being broadcast on the main audio channel of transmission subsystem 110. News, weather and traffic data source subsystem 222 is conventionally implemented to provide text or other data on current events, such as might be provided by a conventional teletype news service. Advertising source subsystem 223 is conventionally implemented to provide text or other messages from advertisers, advertiser coupons, radio station promotional materials, and the like. Paging data source subsystem 224 is conventionally implemented to permit a broadcaster to end point-to-point messages to selected listeners, based on an identification code stored in the receiver 120 of each such listener. Special data source subsystem 225 is conventionally implemented to provide specialized data of interest to a portion of a broadcaster's audience, for instance stock reports for investors or snow conditions for skiing enthusiasts. Emergency data source subsystem 226 permits a broadcaster to send data corresponding to extremely high priority information, such as severe weather warnings and disaster information. Manual input subsystem 227 is conventionally implemented to permit a broadcaster to directly input data for transmission, for instance using a keyboard.

A data prioritizer subsystem 228, operable by the broadcaster's personnel, is a computer-implemented facility that collects the various data provided by subsystems 221-227 and allows the broadcaster's personnel to assign priorities to various portions of such data. These priorities may be varied as desired by the broadcaster. For example, the broadcaster may set up a priority scheme as follows, using 1 as highest priority:

TIME DATA TYPE PRIORITY

6 a.m. to-9 a.m. Traffic 1

Weather 2

Program-Related Data 3

News 4

Advertising 5

Special Services 6

10 a.m. to 3 p.m. Program-Related Data 1

Special Services 2

Weather 3

Advertising 4

Traffic 5

3 p.m. to 7 p.m. Traffic 1

News 2

Advertising 3

Weather 4

7 p.m. - 6 a.m. Program Related Data 1

Manual Input 2

Advertising 3

Weather 4

News 5

Special Services 6 In a preferred embodiment, whenever emergency information is to be sent using emergency data source 226, such is automatically assigned the highest possible priority. In some applications where emergency information is not of an immediate nature or is only of interested to selected groups of listeners, for instance information about an ongoing forest fire in one portion of a listening area, it may not be appropriate to assign the information the highest priority at all times.

As explained in greater detail in connection with figures 4 and 5, after the broadcaster's personnel have assigned priorities for each time period, data source subsystem 220 obtains the data for which broadcasting is desired from subsystems 221- 227 and applies this data, in conjunction with the priority assignments, to data depth calculator 213 and data refresh rate calculator 212. Data depth calculator 213 determines the number of levels in which the data to be broadcast are to be structured. For example, if four types of data are to be broadcast (traffic, news, advertising and weather), the data might initially be structured along four paths, one for each. The traffic data might be provided by data source 222 already categorized into "city traffic" and "suburban traffic". The news might be provided by data source 222 already categorized into "headlines," "local," "national," and "international." Each of the latter three categories might be divided into "economic," "political," and "human interest." Advertising data, as provided by source 223, may not be further categorized at all. The weather data provided by data source 222 might be categorized as "local," "regional," and "national," and each of those categories may further be divided as to "short-term," "24-hour," and "long-range."

Data depth calculator 213 examines the categories available for the data to be transmitted, compares that information with the priorities assigned by prioritizer 228, and determines an overall number of data levels in which data are to be broadcast. Using the example above, if news has a low priority data depth calculator 213 may determine to ignore all but the headline category of stories. Similarly, if very detailed program-related data are available, but priority for the program-related data is low, data depth calculator may choose to ignore all but the top-level information.

In one embodiment, data depth calculator 213 operates based not only on the predetermined priorities provided by data source subsystem 220, but also on information provided inherently by the data. For example, program material data may indicate that the musical piece currently playing has a duration of only two minutes, but there may be six levels of program-related data available for this piece. Given the short duration of piece, it would be unlikely that a user of a receiver would be able to access all of the available information, so all but the first level of information mig t e ignored.

Pseudocode describing operation of an exemplary data depth calculation process provided by data depth calculator 213 is provided below as an additional disclosure.

Process DepthCalculation

Function Getlevels(tyρe) Begin {Getlevels} If data type = News then If priority = 1, 2, or 3, take all levels

If priority < 3, take Headline level only; If data type = Weather then

If priority = 1, 2, or 3, take all levels If priority < 3, take Headline level only; If data type = Program-related data then

If duration > 4 minutes then

If priority = 1, then take all levels If priority = 2, then take first 3 levels If priority = 3 or 4, then take first 2 levels If priority < 4, then take first level only;

If duration < 2 minutes then

If priority = 1 or 2, then take first 3 levels If priority = 3 or 4, then take first 2 levels If priority < 4, then take first level only; End {Getlevels};

Begin {DepthCalculation}

Obtain list of data types desired for current time period Repeat

Get next data type from list as currenttype Getlevels(currenttype)

Until no more data types Add total number of levels obtained While total number of levels > maximum

Search for lowest priority data type with >1 level taken Remove lowest level from that data type

Create record of data levels taken for each data type End {DepthCalculation} Data refresh rate calculator 212 determines the frequency with which each item of data from data source subsystem 220 is retransmitted. Preferably, data items within each selected data type are retransmitted, or refreshed, sufficiently often that users of receivers who tune in the broadcaster's signal do not have to wait very long to obtain the data, and sufficiently often that the data at the user's receiver is not so out of date to be unusable. The rate at which it is desired to refresh data items depends on a number of factors, such as (i) the temporal nature of the data, (ii) the importance of the data item within the data type, and (iii) the priority assigned to the data type. Illustrating (i), if a radio station desired to send as data a textual printout of the current time, accurate to the minute, that data would need to be refreshed at least once per minute. As to (ii), the top-level of program-related data for musical pieces would probably include the name of the piece, and this should be retransmitted more often than lower-level information such as, for instance, biographical information about the composer. As to (iii), if traffic information has been given a low priority and stock price information has been given a high priority, stock price information should be updated more often than traffic information.

Based on such factors, data refresh rate calculator 212 determines, for each item of data to be transmitted, how often such item is to be retransmitted. In a preferred embodiment, it is assumed that all transmitted data are refreshed at least once every 45 seconds. First level program-related information such as the title of a musical piece and its composer/ performers are updated at least once every ten seconds. It should be recognized that in other applications, different data refresh rates may be appropriate. Using these constraints, data refresh rate calculator 212 determines how often each data element can be retransmitted. If the constraints are easily satisfied, data refresh rate calculator 212 increases the frequency of refresh proportional to the priority and level of each data item. In another embodiment, data refresh rate calculator 212 signals data depth calculator 213 when minimum refresh constraints are being easily satisfied so that data depth calculator 213 adapt its rules and allow additional levels of data to be transmitted. Conversely, in this embodiment if data refresh rate calculator 212 is unable to satisfy all of its constraints, it notifies data depth calculator 213 of this so that fewer levels of data are selected. In still another embodiment, data refresh rate calculator 212 determines a refresh rate for a particular item of data based on whether the data is stable or is rapidly changing. For instance, data corresponding to the score of a tennis game may be updated more frequently than data corresponding to the score of a baseball game. In a related application, data refresh calculator 212 may refresh data immediately upon change of the data. For instance, even if data corresponding to a baseball score is normally set for an update once per minute, the data are immediately refreshed in response to change in the score. In this manner, receiver users can, for example, have a constant and up-to-date display of the score of the game to which they are listening. In some applications, it may be appropriate for personnel operating system 100 to have manual control of when certain items of data are re-transmitted. In such applications, conventional software or hardware subsystems may be applied to system 100 to force certain data items to be resent at any particular time.

Thus, data refresh rate calculator 212, data depth calculator 213, and data source subsystem 220 interact so as to produce signals providing the number of categories of data to be transmitted, the depth of the data in each such category, and the frequency with which items at each level in each category are to be refreshed. All of these signals, along with the data itself, are provided as input to data stream generator 214, which continuously assembles the data according to the selected categories and levels, and retransmits each item of data at the appropriate refresh rate.

Data stream generator 214 produces data according to an addressed data structure that is not fixed, but that changes continuously with the output of data source subsystem 220, data refresh rate calculator 212 and data depth calculator 213, as described herein. Referring now to figure 3, there is shown a flow diagram describing operation of data source subsystem 220 to set up priorities for data to be transmitted. After an operator (typically, from the personnel of the broadcaster) directs setup processing to begin 301, the operator selects 302 a time frame of interest, for instance the 6 a.m. to 10 a.m. time frame. The operator then selects 303 the types of data, e.g., news, program- related data, etc. that are desired to be transmitted during this time period. The operator then prioritizes 304 the data. In one embodiment, each data type is given a unique priority level. In an alternate embodiment, data types may share the same priority levels. The data types and associated priorities are then stored 305 for later use. If the operator determines 306 that there are more time frames of interest, processing is reverted to 302. Otherwise, setup is complete 307.

Referring now to figure 4, there is shown a flow diagram showing processing by data encoding processor 113 once setup, described in connection with figure 3, is completed. After processing commences 401, data encoding processor 113 determines

402 which of the possible data types have been selected for the current time frame during the setup process. Current data corresponding to those types are then obtained

403 by data source subsystem 220 using the appropriate data sources 221-225. Data source subsystem 220 then associates 404 the data so obtained with the corresponding priorities determined in the setup process. Signals corresponding to this information are then provided as input to data depth calculator 213, which calculates 405 an appropriate data depth based on the characteristics of the data and the priority assignments, as described elsewhere herein. Similarly, data refresh rate calculator 212 determines 406 an appropriate refresh rate for each item of data to be transmitted, again based on the characteristics of the data and the priority assignments. Data stream generator 214 then determines 407 an appropriate data structure for the data to be transmitted, and the data are then transmitted 408 in accordance with the data structure, completing 409 this process. Referring now to figure 5, there is shown an exemplary data structure 500 used by system 100. Data structure 500 provides a user of receiver 120 with a number of screens of data, e.g., 501. In the embodiment illustrated in figure 5, data structure 500 provides an initial index screen 501, indicating to the user what information is available through data structure 500 and where it may be found. The embodiment illustrated in figure 5 shows a second index screen 502 that is used when a single screen is insufficient to provide the index of available information. In one embodiment, the form of the index may be as a table of contents; in another embodiment a "tree" diagram showing a skeletal diagram of structure 500, appropriately labeled, may be used to implement screens 501, 502. From the index screens 501, 502, four main screens 510, 520, 530, 531 are accessible to the user. In a preferred embodiment, screen 510 is maintained as an access point to a spare portion of the data structure reserved for uses that may be desired in the future. The use of a dashed line underneath selected screens, e.g., 510, indicates that other screens may be accessible beneath that screen, in conventional hierarchical fashion. A fallback screen 520 is a primary screen for providing access to listener information. In the structure illustrated at figure 5, three screens are accessible from fallback screen 520: a traffic screen 5201, an events screen 5202, and a weather screen 5203. It should be recognized that, as described above and in the referenced U.S. patent, various other types of information could be presented through other screens at this level of data structure 500. For instance, a screen pertaining to information about the audio program material currently being broadcast by transmitter 111 could be provided.

From each of these screens, further screens providing yet more detailed information are accessible. For instance, the weather screen 5203 may be used to access a local forecast screen 52031, a regional forecast screen 52032, and an extended forecast screen 52033. In a preferred embodiment, the screens accessible from fallback screen 520 are generally available to any user of a receiver, e.g., 120. Data structure 500 includes two other screens that are not generally available, but are instead available only by user subscription. Any conventional subscription mechanism, such as registration of a receiver identification code with the broadcaster and subsequent transmission of a receiver-specific "unlock" code, may be used to implement access limitations for the subscription screens 530, 531.

Subscription screens support a variety of subscription services. For example, subscription screen 530 may provide financial data including stock and bond quotes, bank rates, and the like. Subscription screen 531 may provide detailed sports information for enthusiasts.

It should be recognized that many variations on the structure 500 illustrated in figure 5 may be used, as desired by the broadcaster. In a preferred embodiment the screens 510, 520, 530, 531, are referred to as "mode screens," as each may provide a different mode of service. In one such embodiment, the mode corresponding to screen 510 is unused, the mode represented by fallback screen 520 includes a number of additional screens accessible hierarchically through fallback screen 520, and the modes represented by subscription screens 530, 531, each also provide access to a number of screens of information for that mode.

Navigation among the screens of data structure 500 is performed conventionally in several ways. In a preferred embodiment, each "child" screen, e.g., screens 5201, 5202, 5203 is accessible via a user display button icon from the parent screen, e.g., 520. In some applications, hardware-implemented function keys on receiver 120 may also be used to select child screens.

In a preferred embodiment, structure 500 is implemented by assigning each of the screens in each mode a unique identification number, and by assigning corresponding identification numbers to the buttons that permit access to child screens from a parent screen. By establishing correspondence between parent and child screens in this manner, structure 500 may be adapted as needed for any particular application. It should be recognized that screens previously used for one mode, if no longer needed for that mode, may be used for another mode. In a preferred embodiment, refresh may be calculated as described above independently for each screen of data structure 500, although in many applications it may be desirable to group screens together for purposes of determining when they are to be refreshed.

Referring now to figure 6, receiver 120 is also configured to maximize the efficiency of data transfer through adaptive techniques. Specifically, data decoding processor 123 of receiver 120 includes a data structure decoder 611, a memory subsystem 612, a data caching subsystem 613, and a user interface subsystem 614.

Data structure decoder 611 responds adaptively to the data structure provided by transmission system 110. In particular, data structure decoder 611 creates a data map based on the data provided by data stream generator 214. Received data are then stored in memory subsystem 612 according to this data map. A user interface subsystem 614 includes a display and user input facility (e.g., touch screen or programmable buttons) that allows the user of receiver 120 to select data for display as desired, for instance in the manner set forth in U.S. patent no. 5,491,838 to Takahisa et al., the contents of which was incorporated by reference above.

In many applications, received data may be more voluminous than can be stored in memory subsystem 612. In such case, top-level data are stored as a matter of course, and lower-level data are stored in response to user request of such data. For example, program-related data may provide a top-level menu of information on composer and performer name, and provide a menu selection for a lower-level of data providing a biography of the composer. Upon the user's selection of the biography information, user interface subsystem 614 will request memory subsystem 612 to store such data the next time it is transmitted.

In one embodiment, a data caching processor 613 records the user's selections made via user interface subsystem 614 and predicts therefrom certain characteristic preferences of the user. Based on such preferences, data caching processor 613 instructs memory subsystem 612 to store information that the user is likely to request in the near future. For example, a particular user may repeatedly operate user interface subsystem 614 so as to first display traffic data, and then to display weather data. Based on this pattern of usage, as soon as the user requests traffic data, data caching processor 613 will instruct memory subsystem 612 to store the weather data the next time it is transmitted. In this manner, the user does not have to wait for data that are requested in accordance with the user's typical preferences.

Conversely, data caching processor 613 also instructs memory subsystem to not store information that is rarely or never requested by the user. For example, if over a period of time the user has never requested stock price data, caching processor 613 instructs memory subsystem 612 not to store such data but to use that same memory to store other, more frequently requested data. If the user thereafter does request stock price data, such data will be stored in memory subsystem 612 and prepared for display on user interface subsystem 614 the next time it is transmitted. In one embodiment, data not likely to be used are only ignored as described above when memory requirements begin to approach receiver memory capacity. Thus, where a station broadcasts relatively sparse information, there may be no need for such selective storage; where a station broadcasts a great deal of data, selective storage may be critical to avoiding running out of available receiver memory. In still another embodiment, a user specifies, through user interface operations, certain categories of information that are high priority, and caching processor 613 instructs memory subsystem 612 to store all information in that category. In yet another embodiment, the user can force storage of any particular screen regardless of a category priority. For instance, if a broadcaster transmits a screen that indexes the information provided by other screens, the user is able to select from that index certain screens that should always be stored in memory subsystem 612. Through these techniques, scarce memory resources in the receiver are used in the manner most beneficial to the user. From the above description, it will be apparent that the invention disclosed herein provides a novel and advantageous improved broadcast system with associated data capabilities, in which adaptive techniques are used to make efficient use of limited bandwidth and memory. The foregoing discussion discloses and describes merely exemplary methods and embodiments of the present invention. It should be recognized that the data referred to herein need not be limited to text, but could correspond to graphics, video, sound, computer code, or any other digital code. It should also be recognized that the invention could also be used in different applications than FM subcarrier data transmission. Furthermore, it should be recognized that the structures and processes disclosed herein could be advantageously used in situations where multiple entities share a finite portion of a large bandwidth communications channel.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

What is claimed is:

1. A system for simultaneously transmitting program material and data, comprising: a program material source providing said program material; a data source providing said data; a data encoding processor operatively coupled to said data source, said data encoding processor adaptively constructing from said data a data structure; a transmitter operatively coupled to said data encoding processor and said program material source, for transmission of said program material and a data stream corresponding to said data structure.

2. A system as in claim 1, wherein said data encoding processor is responsive to selected parameters.

3. A system as in claim 2, wherein said parameters include time of day.

4. A system as in claim 2, wherein said parameters include weather conditions.

5. A system as in claim 2, wherein said parameters include a parameter corresponding to the program material.

6. A system as in claim 2, wherein said parameters include advertising activity.

7. A system as in claim 1, wherein the data encoding processor includes a refresh rate calculator for adaptively refreshing data in the data stream in response to selected parameters.

8. A system as in claim 1, wherein the data encoding processor includes a data depth calculator for adaptively determining a depth for the data structure in response to selected parameters.

9. A system for simultaneously receiving transmitted program material and data, comprising: a program material decoding processor for reproducing said transmitted program material; and a data decoding processor for adaptively decoding said transmitted data.

10. A system as in claim 9, wherein the data decoding processor adaptively decodes said transmitted data in response to selected parameters.

11. A system as in claim 10, wherein the selected parameters include a parameter relating to available memory.

12. A system as in claim 9, wherein said data decoding processor includes a data structure decoder for determining a structure pursuant to which the transmitted data were transmitted and for processing the transmitted data according to the structure.

13. A system as in claim 9, the data decoding processor further comprising a data caching processor for determining user characteristics and storing portions of the transmitted data in response thereto.

14. A method of transmitting program material and data, including: adaptively determining a data structure for said data; and transmitting said program material and transmitting said data according to said data structure.

15. A method as in claim 14, wherein said data structure is determined in response to preselected conditions.

16. A method as in claim 14, further comprises retransmitting portions of said data on an adaptive basis.

17. A method as in claim 14, further comprising retransmitting portions of said data at an adaptively determined refresh rate.

18. A method as of receiving simultaneously transmitted program material and data, comprising: determining a data structure according to which said data were transmitted; and organizing said data for display according to said data structure.

19. ^~A method as in claim 18, further comprising selectively storing portions of said data in memory in response to user characteristics.

20. A method as in claim 18, further comprising selectively storing portions of said data in memory in response to memory availability.