WO1999039466A1

WO1999039466A1 - Apparatus, systems and methods for providing on-demand radio

Info

Publication number: WO1999039466A1
Application number: PCT/US1999/002034
Authority: WO
Inventors: Daniel S. Kwoh; Kenneth Li; Kevin Tso
Original assignee: Kwoh Daniel S; Kenneth Li; Kevin Tso
Priority date: 1998-01-29
Filing date: 1999-01-29
Publication date: 1999-08-05
Also published as: AU2487099A; WO1999039466A9

Abstract

It is the desire of the present invention to provide the radio listener with personalized, on-demand access to news, entertainment, and other information in an audible form ('On-Demand Radio' or 'ODR'). The present invention discloses methods and systems such that information, according to the user's preferences, will be downloaded and/or broadcasted to the user, stored in the memory of the user/listener's individual ODR unit device, and converted into audible signals for delivery to the user. The ODR unit delivers information in an automatic play sequence which is defined by the user. The user can navigate through the play sequence of the stored information using only a few contextually-sensitive keys, or in an alternative embodiment, through spoken commands. Downloading/broadcasting of the information can be accomplished in a variety of ways, including but not limited to: radio broadcast, subcarrier broadcast, satellite transmission, downloading from the Internet, and/or downloading from an information service through a computer and/or computer network. Information transfer to the ODR can be accomplished in a variety of ways, including but not limited to: through a radio receiver in the ODR; through infrared communication devices, computer communications using, e.g., a modem, and/or through a memory medium such as, but not limited to, a flash memory card, hard disk, and the like.

Description

APPARATUS, SYSTEMS AND METHODS FOR PROVIDING ON-DEMAND RADIO

FIELD OF THE INVENTION

The present invention relates generally to radios, and more particularly, to providing the radio listener with the capability to access audio information in an "on-demand" format, and with the further capability to specify personalized format for the demand.

BACKGROUND

Currently, radio listening is a non-interactive, passive, relatively unpersonalizable activity. Once a listener tunes to a particular station, be it AM or FM. the typical listener does not frequently change stations. Rather, the typical radio listener receives whatever music, news, chatter, talk shows, interviews or other audible communication that is broadcast by the radio station to which the listener's radio is tuned. Furthermore, the typical listener receives such audible communication in whatever order the station to which the listener's radio is tuned chooses to broadcast the audio signals. The passiveness of present-day radio listening is remarkably similar to the passiveness of television viewing prior to the introduction of certain advances for televisions, including among other things, remote control devices and on screen electronic program guides. In the pre- remote-control days of television viewing, a family typically selected a television station and remained tuned to that same station for an extended duration of time ~ for instance, the duration of one or more programs broadcast by that station. In those days, changing stations required the viewer to physically leave the comfort of the viewer's armchair and walk to the television in order to tune to a different channel. In the early days of television viewing, the viewer could not merely change a channel by switching a channel selection dial from one channel to the next. Instead, in the early days, the viewer needed to rotate a dial to locate the next receivable television frequency, much like today's dial-tunable radios. Later advances provided a channel selection dial that would allow the viewer to select from a limited number of UHF and VHF channels. Today, of course, television viewers use their remote control devices to surf hundreds of stations, delivered by broadcast, satellite, and cable services, all from the comfort of their armchair. Today's television viewer further uses the remote control device to navigate through an on screen electronic program guide in order to select television programs of interest to the viewer. Like the pre-remote-control television viewer, today the typical radio listener is frequently content to choose a single station, for instance, for its genre of music, and to stay tuned to that same radio station for an extended period of time, for instance for the duration of the listener's commute to work. Like the early televisions, many radios today continue to require the listener to rotate a tuning dial in order to locate the next available receivable radio frequency, over which a local station broadcasts. More advanced radios provide a "seek" tuner which finds the next available receivable station. Many radios, especially car radios, provide "Memory" buttons so that the listener can program a particular key to tune a particular station.

Today's radio buttons provide a similar capability to the pre-remote television channel dial. That is, the radio listener can program a limited number of buttons, typically six, each button corresponding to a particular radio frequency over which the listener's top six local radio stations are broadcast.

Typical radios provide the listener with the ability to select either AM frequencies or FM frequencies. The selection can be made on some radios with a single two-position button; other radios provide two buttons ~ one for AM, and another for FM. Some radios provide the capability to select two different stations for the same memory button ~ one for AM; another for FM.

Most radios today, provide a window of typically small size, to display the radio frequency to which the radio is currently tuned. Many radios today, when turned off, display the current time. Even with memory button capability, today's typical radio listener often stays tuned to a single station for an extended duration of time. For instance, the radio-listening automobile driver, concerned about avoiding the day's worst traffic snarls, might be content to tune to the listener's most favored traffic and news station for the entire duration of the listener's commute. The commuter-listener's main goal, in this case, is to gain the insight necessary to navigate through the obstacle course of traffic jams, detours and other delays in store for the listener's commute that day. In this example, the traffic-concerned listener is not especially interested in the news and/or chatter that fills the station's broadcast between one traffic report and the next. Even though the commuter-listener is not especially interested in the news broadcasts, the commuter-listener resists changing the channel to a favorite music station during the news broadcasts because the commuter-listener does not know exactly when the traffic station might broadcast the most up-to-date information concerning the commuter-listener's particular traffic route. As another example, a commuter-listener is especially interested in news, quotes and information concerning stocks and investments held by, or of interest to, the commuter-listener. The commuter-listener in this example, tunes to a financial station to garner any information available about a small number of stocks held by the commuter-listener. The other information broadcast by the financial station is not of interest to the particular commuter-listener. However, because the commuter-listener has no way of knowing when the station may provide updated news, stock quotes or other information concerning the particular investments of interest, the commuter-listener resists changing the stations to a favored music station.

Some listeners may instead prefer to fill the commute time with business news; some may prefer international and national news, while others may prefer local news. A sports fan may be impatient to get scores of games that are in progress or are already over.

A typical news radio station will "loop around" on a periodic basis, for instance, every 20 minutes. Within the typical "loop" period, the typical news radio station will cover a certain, limited number of individual "stories," for instance 40 individual "stories." During the next loop, some stories may be repeated, while some may be replaced by new ones. Since radio is a broadcast technology, the news station editorial staff will select stories which meet the lowest common denominator of interests of the station's perceived listeners. As such, many story topics will be of little interest to a particular listener. In the case of a story that is of interest to a particular listener, the station's need to cover as many stories as possible causes the station to provide only highlights of the story, not the detail. Accordingly, depending upon the interests of the listener, the listener may feel unsatisfied with the amount of information content available for a story of great interest to that listener.

As with radio news broadcasts, typical current day television news broadcasts are similarly limited to covering a certain limited number of stories that the station perceives to be of common interest to the station's, or a network's, listeners. Of course, television has the distinction from radio news broadcasts of presenting video in addition to audio coverage. However, even with the video distinction, television news coverage is typically an unsatisfactory news source for a viewer with specific interests.

Newspaper coverage of news stories is somewhat more comprehensive. Because of the low cost of newsprint paper, newspapers can cover a larger number of stories, each in more detail than typical current day television or radio coverage. Nevertheless, any one individual newspaper can fail to satisfy the interests of readers with specialized interests. Accordingly, many newspapers today specialize. For example, the Wall Street Journal concentrates on business news and analysis. Larger cosmopolitan area papers like the New York Times and Los Angeles Times, often concentrate on international and national news, while small town local newspapers concentrate on local news. Hard copy newspapers are typically published daily; such papers are not able to keep up with late-breaking news throughout the day.

The Internet provides many desirable attributes for news delivery. All news stories can be made available in great detail as they break throughout the day. The number of news stories per day is quite staggering ~ Reuters, for example, reportedly has an average of over 1 ,000 stories per day. Screening through just the headlines can be a time consuming effort.

Fortunately, the Internet is an electronic medium with which a profile can be established by a reader to pre-filter the number of stories. Pre-filtering allows the reader to downsize the number of stories of significant potential interest down to a manageable number, for instance, about 100 stories per day. The reader can then scan through the headlines of the pre-filtered stories in order to decide which ones to read. Pre-filtering is the approach taken by PointCast and other news delivery organizations on the Internet.

As with Internet news, the Internet has general information advantages for the inquisitive user. That is, the Internet user can search for information concerning particular topics of special personal interest. For instance, the Internet user can search, in an on-demand fashion, for information concerning personal stock holdings or stock in which the user has some special interest. The Internet user can expand the search for related information to include information concerning the company for which the stock pertains, executives that manage the company, related companies, and other companies in the same industry.

If the Internet user is interested in weather, the user can access specialized web sites devoted to the collection and communication about weather in countries around the world.

Whatever the Internet user's interest, chances are that somewhere on the Internet, there exists one or more web sites that contain information concerning the topic that is of particular interest to the Internet user.

Use of the Internet is becoming more and more a part of the daily routine for many people. Increasing, is usage of the Internet for specific information inquiries as well, as for browsing for general information.

Due to the limitation of data transmission speeds, there are several tools, e.g. PointCast, Freeloader, etc., which allow users to download needed information ahead of time. For example, users can request that information be downloaded during the middle of the night and the user retrieves the information in the morning. With such tools, users are also allowed to set-up preferences such that information is downloaded according to the specific interests of the individual user. Using the tools described above, a typical user might retrieve the information for on-screen display and then print interesting sections for later reading.

For many people, there are extended periods of time during which the user cannot read, for instance when driving, or jogging. During such times, many people enjoy listening to the radio. For example, a commuter driving to work may listen to the radio for the latest news or stock quotes. The radio station provides information in a particular sequence and format chosen by the station. As a result, much of the information may not be of interest to the listener.

With all of its advantages and potential, Internet news, information and entertainment has a major handicap - it is currently accessible only in front of a computer or computer-linked device (desktop, lap-top, Web-TV, etc.) which must have an optically readable and/or viewable display device. The computer or computer-linked device typically requires some method of physical user input, such as a mouse, track-ball, and/or keyboard.

SUMMARY OF THE INVENTION This application claims priority of U.S. Provisional Patent Application Nos. 60/093,096

("ON-DEMAND NEWS RADIO"), and 60/073,026 (ON-DEMAND NEWS RADIO"), the disclosures of which are attached to this application as Appendices A and B respectively and which are incorporated herein by reference, as if fully stated here, for all purposes.

It is the desire of the present invention to provide the radio listener with personalized, on- demand access to news, entertainment, and other information in an audible form ("On-Demand Radio" or "ODR"). Many different types of embodiments or models of the present invention are possible. The following list of different types of models is exemplary and is not meant in any way as a limitation of the invention. For instance, On-Demand Radios will be useful in the following types of models including, but not limited to: automobile, Walkman, kitchen counter, table, shower, part of clock-radio-alarm, etc.

The present invention discloses methods and system such that information, according to the user's preferences, will be downloaded and/or broadcasted to the user, stored in the memory of the user/listener's individual radio unit device, and converted into audible signals for the user. References in this application to "memory" storage include, but are not limited to: random access memory, magnetic storage devices and optical storage devices. The user can navigate through the stored information using only a few contextually-sensitive keys, or in an alternative embodiment, through spoken commands. Downloading/broadcasting of the information can be accomplished in a variety of ways, including but not limited to: radio broadcast, subcarrier broadcast, satellite transmission, downloading from the Internet, and/or downloading from an information service through a computer and/or computer network. Information transfer to the ODR can be accomplished in a variety of ways, including but not limited to: through a radio receiver in the ODR; through infra-red communication devices, computer communications using, e.g., a modem, and/or through a memory medium such as, but not limited to, a flash memory card, hard disk, and the like.

As an example, it is the purpose of the present invention that a radio listener, for instance, a typical worker that spends one to two hours commuting every day, with access to news stories in which the listener is specifically interested, in the amount of detail which satisfies the listener's interests, and at the time that the listener is prepared to listen.

According to the present invention, a broadcast delivery service is created (the "Broadcast System"). The function of the Broadcast System is to provide information to the individual listener's radio unit in which the individual listener is interested.

According to the present invention, a mechanism is provided by which the individual radio listener identifies the radio listener's individual radio unit, personal interests, personal preferences and individualized settings and options ("Control Set-up Specifications").

According to the present invention, certain or all aspects of the listener's Control Set-up Specifications can be used by the Broadcast System to narrowcast information to the listener's individual radio unit ("On-Demand Narrowcasting"). According to the present invention, and as an alternative to or in combination with, On-

Demand Narrowcasting, the Broadcast System transmits certain or all aspects of the listener's Control Set-up Specifications which are received by, and installed in, the listener's individual radio unit ("In-radio Set-up Specifications," also referred to as "In-unit Profile")). In an alternative embodiment, the user communicates to the ODR unit the user's In-unit Profile information.

According to the present invention, the listener's In-radio Set-up Specifications (also referred to as "In-unit Profile") can be used by the listener's individual radio unit to automatically select information delivered by the Broadcast System according to the individual listener's specified interests ("On-Demand Reception"). According to the present invention, methods and systems are provided for downloading data from a host computer, several host computers, or one or more web sites to a radio unit device with memory (such as random access memory) sufficient to hold said data. In accordance with Control Set-up Specifications and/or In-radio Set-up Specifications, the data will be transmitted to, selected by, and/or stored in the memory of the listener's individual ODR unit.

According to the present invention, the listener's individual radio unit provides methods. systems and apparatus ("User Interface") by which the listener can request specific information stored in, or received by, the listener's individual radio unit.

According to the present invention, when the listener requests information stored in the memory of the listener's individual radio unit, the specified information is retrieved ("On- Demand Delivery"). If audible data has been stored in a compressed form, the audible data is decompressed. If digital data, with non-audible attributes has been stored, the data is converted into audible information through the use of a speech synthesizer. The resulting audible data is then delivered through the radio's auditory speaker mechanism for the listener's individual reception.

According to one aspect of the invention, some or all of the information to be stored in the ODR unit is delivered in digital form. The digital form of the information is converted and stored in memory as an audio signal that will then be available to be recalled from the memory and output to the radio sound system in audio form. Alternatively, the digital form of the information is stored in memory, and at the time that the information is to be delivered in audible form, a lookup table is used to convert the digital information to audio signal form for delivery through the radio sound system. This aspect of the invention can be performed in combination with other forms of delivery and storage. This aspect of the invention saves memory and transmission requirements for regularly used words such as alphabetic, numerical, and common phrases, and names, such as those used in stock reports and traffic reports. For example, reading all of the more than 7000 stock symbols traded in the United States would take a very long time. Under this aspect of the invention, the stock symbols and prices can be broadcasted in digital form. According to the user's predefined In-radio Profile (explained more fully below), only stock symbols and prices matching the user's Profile are selected for storage in the memory of user's ODR unit. The stored digital information will be used to look up the stored audio signal. and the corresponding stored audio segments of information will then be delivered to the user through the user's radio sound system. In one embodiment of the invention, the digital information is also delivered to the user by displaying the digital information on. for instance, the LCD display of the user's radio device.

It is not a limitation of this invention that any or all of the data transmitted to, and/or received by, and/or stored in the radio unit can be converted to audible data. In an alternative embodiment of this invention, the display window of the radio can be used to display, in textual and/or graphic form, information to the user. In the embodiments of the present invention, that are integrated with palm computers, laptop computers and like devices, the present invention is capable of delivering programming and/or related information in the display feature of the mentioned-device. As an example, and as discussed in further detail below, stock information will be made available to the user that expresses interest in such information. Stock symbols can be displayed as textual information in the radio display window and/or can be converted to audible information. The present invention therefore, provides the ability to deliver the information to the user in audible, textual/graphical, and/or both forms of communication.

According to the present invention, many different types of information can be made available from which the listener/user can select ("On-Demand Content").

The following glossary of terms will be helpful in understanding the following description. Glossary of Terms

DESCRIPTION OF THE DRAWINGS These and other features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where:

FIG. la is a schematic diagram depicting one embodiment of an overview of the Broadcast System. FIG. lb is a schematic diagram depicting an alternative embodiment of an overview of the Broadcast System.

FIG. 2 is a graphical representation of one embodiment of the user Control Setup Specifications access and completion.

FIG. 3 is a conceptual diagram representing the information potentially maintained for each user/radio unit.

FIG. 4 is a graphical representation of an embodiment of a log-in screen. FIG. 5 is a graphical representation of an embodiment of a metropolitan area designation screen.

FIG. 6 is a graphical representation of an embodiment of a Traffic screen for a typical metropolitan area.

FIG. 7 is a graphical representation of an embodiment of a custom commute route screen.

FIG. 8 is a graphical representation of an embodiment of a Stock selection screen that provides the user with the option of identifying major stock exchanges. FIG. 9 is a graphical representation of an embodiment of a General News screen.

FIG. 10 is a graphical representation of an embodiment of a Business News screen. FIG. 11 is a graphical representation of an embodiment of a Sports News screen. FIG. 12 is a graphical representation of an embodiment of a Sports Score screen. FIG. 13 is a graphical representation of an embodiment of an Entertainment News screen.

FIG. 14 is a graphical representation of an embodiment of a Science News screen. FIG. 15 is a graphical representation of an embodiment of a Health News screen. FIG. 16 is a graphical representation of an embodiment of a Travel News screen. FIG. 17 is a graphical representation of an embodiment of a Technology News screen. FIG. 18a is a flow diagram of one embodiment of the way in which narrowcasting is accomplished. FIG. 18b is a flow diagram depicting one embodiment of the way in which In-Radio

Profiles are established so that narrowcasting can be accomplished.

FIG. 18c is a flow diagram of one embodiment of the way in which narrowcasting is accomplished using In-Unit Profile information.

FIG. 18d is a block diagram of one embodiment of ODR Unit logic using In-Unit Profile information to store information matching the In-Unit Profile.

FIG. 18e is a flow diagram of an alternative embodiment of the way in which the user establishes an In-Unit Profile.

FIG. 19a is a graphical representation of one embodiment of an On-Demand Radio unit apparatus. FIG. 19b is a block diagram representing one embodiment of On-Demand Unit components.

FIG. 20 is a state transition diagram of one embodiment of an On-Demand Radio unit play back system.

FIG. 21a is a block diagram of one embodiment of an ODR unit depicting communications with multiple devices.

FIG. 21b is a block diagram of one embodiment of an ODR unit capable of communicating with multiple devices.

DETAILED DESCRIPTION A. The Broadcast System

According to the present invention, a broadcast delivery service is created (the "Broadcast System"). The function of the Broadcast System is to provide information to the individual listener's radio unit in which the individual listener is interested. That is, a radio Broadcast System is provided, together with radio receivers that will allow listeners to selectively listen to news stories and other information of the listener's choice. Information will be made available with progressive levels of detail. FIG. la is a schematic diagram depicting one embodiment of an overview of the news collection and Broadcast System.

In one embodiment, individual radio and/or television stations and/or other news gathering services such as newspapers and/or news services (10) will be used to collect news data (20). Each participating news gathering service prepares basic news stories (30) and formats the news story in accordance with Broadcast System requirements (40). In one embodiment, the news gathering service edits each story (50) to add intelligence in the form of key words about the content of story. Content coding will be done in accordance with

Broadcast System specifications. In one embodiment, each story will be constructed to consist of a summary (optional), a brief version of the story (optional), a detailed version of the story, certain keywords (e.g., sports, basketball, Lakers, Knicks) and other details such as version number (a story may evolve during the day and a second version may need to be sent) and time. In one embodiment, at each of the news gathering services mentioned above, a data inserter (60) will be installed to insert the data prepared by that news gathering service. In one embodiment, the data inserter is a PC based machine.

Each inserter receives news stories in the form of data files either by modem download (e.g. from a national center or from news services such as AP, Reuters, etc.), or by local input from the station staff.

In an alternative embodiment, a National Operational Center ("NOC") is established. FIG. lb is a schematic diagram depicting an alternative embodiment of an overview of the Broadcast System in which an NOC is used to receive, prepare and transmit ODR information. In this embodiment, NOC is staffed with engineers, editors and announcers. For output, NOC will be linked by dedicated telephone line, satellite link or other communication to an FM station in each target city. An inserter will be provided to each FM station. Local news inputs to NOC can be provided in a variety of ways (10-30), including but not limited to: a) Dedicated telephone lines to local news radio stations; and/or b) telephone, electronic, satellite, and/or Internet links to local newspapers and/or to other news services, including news sources for world news, national news, business news, traffic, stocks, sports. Formatting and editing (40-50) will be performed at the NOC for final insertion (60) and broadcasting.

Stories are stored in the memory of the inserter and queued for broadcast. The queuing is dynamic and may change. Important late breaking stories and time-urgent information such as traffic may be moved up the queue at the control of the news editor of the station.

In one embodiment, the editor (such as the NOC editor, or a local news editor) will attach special coding to certain emergency information such as information regarding tornados, hurricanes, high-speed freeway chases, etc. The ODR unit will receive and recognize the specially coded messages and will deliver an "Alert" to the user. Alerts regarding such emergency information are referred to as Standard Alerts. Alerts will be capable of interrupting ODR programming, and/or regular radio, e.g., AM and/or FM. Alerts can also be customized. For example, the user can request an Alert if a certain stock's price falls below a certain point or rises above a certain point. As another example, the user can receive traffic condition Alerts for the user's custom traffic route. Customized Alerts will carry the special interrupting code and will cause delivery immediately upon receipt. Standard Alerts and Customized Alerts are described more fully below.

Data may be broadcasted with existing technologies, such as FM Subsidiary Communications Authorization ("SCA") subcarrier, Radio Data System ("RDS"), Data Radio Channel ("DARC"), etc. Such technologies do not interfere with the station conducting its regular broadcast business. Currently, SCA and RDS are capable of about 600-2400 bits-per- second (bps) data rates. For the preferred embodiment, a subcarrier using the FM subcarrier Information Service (FMSS) format will transmit unformatted, uncorrected data at a rate of approximately 16 kbps. Depending upon the signal condition and amount of error correction needed, the actual usable rate will be approximately 8 kbps to 10 kbps. Alternatively, a full FM or AM station may be devoted to data broadcast, provided FCC approval is obtained. Any other means of wireless communication can be used, including but not limited to: digital radio broadcast, digital television broadcast, and/or the vertical blanking interval of analog television broadcasts (VBI).

In an alternative embodiment, or in combination with the above embodiment, news stories are received in audible form and are stored as voice files in the inserter. The stories are "formatted" using voice commands by the news editor; key words are added verbally. Similarly, news stories received in text can be read by the news gathering service or Broadcast System editors and stored as voice files in the inserter.

In one embodiment, new stories are broadcast by the Broadcast System in voice throughout the day. According to this aspect of the invention, the Broadcast System acts like a typical radio station, i.e., a normal radio tuned to this station will have access to all stories transmitted. Each news story is broadcast with a header that precedes, or is attached to the story in the broadcast signal. The header can be heard as a short audio "blip." The audio "blip" is actually the data header that contains intelligence about the particular news story. For instance, the header will contain several bytes of information indicating, for instance, the category, sub-category, version number, etc. for the particular news story, For example, the header may contain coding that indicates that the following story is a story about "Sports- basketball-Lakers." Alternatively, information in the header may be sent by SCA subcarrier or RDS instead of an audible "blip". In another alternative embodiment, voice files are transmitted in compressed voice data form. In one embodiment, some portion, up to and including all, of the information that is broadcast by the Broadcast System is encrypted prior to transmission.

In the preferred embodiment of the invention, a specially constructed radio receiver will be built into the individual listener's radio unit (an On-Demand Radio ("ODR") radio unit), for instance, the listener's car radio or Walkman-type radio. The built-in receiver provides a memory and voice reproduction and/or synthesis circuitry.

In another embodiment, a standalone ODR unit is built to accompany the listener's radio unit. The standalone unit provides a receiver, memory, microprocessor, and voice reproduction circuitry and/or voice synthesis circuitry. The standalone unit can be in the form of including, but not limited to: a) an integrated audio-cassette unit where the electronics are built inside an audio-cassette casing with a face panel attached to the casing; b) a standalone unit with audio-cassette tape player adapter or, c) standalone radio frequency rebroadcast interface. In the case of an integrated audio-cassette unit or a standalone unit with audio- cassette tape player interface, the audio-cassette unit or audio-cassette adapter would be plugged into the audio-cassette player of the individual listener's radio unit in order for the information to be played in an audible form.

A standalone integrated audio-cassette unit could provide accessible hardware to the user in the form of specialized buttons on the face of the unit. In a Radio frequency rebroadcast interface embodiment, the user would tune, for instance, the FM radio to receive a particular FM frequency, as required by the rebroadcast interface; the FM rebroadcast interface will then rebroadcast the information to the radio unit. The rebroadcast can occur automatically and continuously, or can be initiated by the user for instance, by pressing a particular button on the standalone unit and or on the radio unit. The above described embodiments of a standalone unit interface are exemplary only, and are not in any way a limitation of the present invention. As is described in more detail below and as depicted in FIG. 21a, both the ODR radio unit embodiment and the ODR standalone (1300) unit embodiment can communicate with many types of devices, including, but not limited to: different models of radios (1310), cassette players (1320), C/D players (1330), a cellular telephone (1350), palm computer (1383), hand-held computer (1380), laptop computer (1381) and/or desktop computer (1382). FIG. 21b is a block diagram of one embodiment of an ODR unit capable of communicating with multiple devices.

B. Control Set-up Specifications

According to the present invention, one or more mechanisms are provided by which the individual radio listener identifies the radio listener's individual radio unit, personal interests, personal preferences and individualized settings and options ("Control Set-up Specifications").

According to the present invention, many types of information available for On- Demand Radio delivery are categorized into different areas of interest. These categories are made available to the user. In the preferred embodiment, the categories are available to the user through an information network, such as the Internet, and specifically through a particular web site and/or through a number of web sites to which the user can access at any time.

Due to the vast amount of information available in broadcast information, the user is asked to define a personal profile and/or set of preferences, referred to herein as Control Setup Specifications.

In one embodiment, the user's Control Set-up Specifications are used by he central Broadcast System to identify information for that particular user's radio unit such that only the preferred information is downloaded from the central Broadcast System information center to the user.

In an alternative embodiment, the user's Control Set-up Specifications are broadcast to the user's individual unit where the information is received and installed. In one embodiment, the Broadcast System broadcasts the user's Control Set-up Specifications each time the user updates the user's Control Set-up Specifications.

In another embodiment, the user enters Control Set-up Specifications in a palm computer, laptop computer, or other similar device, and then transmits the Control Set-up Specification information to the ODR unit. Transmission of Control Setup Specification information to the ODR unit can be done in various ways, including but not limited to using an infra-red device with an infra-red transceiver in the ODR. In another embodiment, the user enters Control Set-up Specifications directly into the ODR unit using existing dials and/or buttons on the faceplate of the ODR unit.

In the preferred embodiment, the types of information that is available for On-Demand Radio delivery are identified in a web site which can be browsed by the user. FIGS. 4 through 17 are graphical representations of one embodiment of an Internet web site user

Customizer for On-Demand Radio ("ODR"). The Internet web site user Customizer embodiment depicted in FIGS. 4 through 17 provides a typical Control Set-up Specifications interface.

The types of information, referred to here as "topics," identified in a typical web site embodiment of a Customizer include, but are not limited to: news, sport scores, financial results, weather, and other special interests. Topics are divided into categories, referred to here as "subtopics," in several levels, as appropriate for the particular category. For example, the Sports topic can be further divided into subtopics of golf, tennis, football, etc. The football subtopic can then be further subdivided into college and professional.

In one embodiment, as depicted in FIG. 2, the user/listener (100) accesses the information topics (140) through an Internet web site using, for instance, a desktop terminal or portable computer 120. The user/listener is then asked to complete one or more online screens (110) requesting information about the user, the user's unit, and the user's interests and preferences.

The types of personal information collected includes, but is not limited to: radio unit

Identification Number ("ID"), name (may be optional), address (may be optional), zip code, specific stocks of interest, commute route, commute time, sports categories, sports teams, product categories and the order of priority in which the user would prefer to hear information concerning the above-described types of information.

The types of preference information collected includes, but is not limited to a survey of interest levels, including but not limited to levels such as no interest, low interest, moderate interest, high interest, for such topics including, but not limited to general news topics such as world news, U.S. news, local news, and business news topics such as industry news, money and investing, world trade, managing people, etc.

1) Web-based Customizer In one embodiment, the Customizer is a web-based program which produces a

Filter.DAT data file which is described further in a following section of this application. The Filter.DAT file becomes the user's Control Set-up Specifications. One embodiment of the Customizer is described below. a. Default Filter.DAT

In one embodiment, the Customizer does not automatically generate a default Filter.DAT. If a listener does not complete all necessary operations to the end, no file is generated. When it comes time to make or modify the default version of Filter.DAT, a person uses the Customizer to create a version of Filter.DAT, which is then used as a default. b. Set-up Screens

The user is asked to supply certain first time set-up information that the Customizer needs to open an account, i.e., account name, password, product serial number, and personal demographics information. c. Logging In

An opening screen asks the listener for an account name. The system will check for the content for format of the input. FIG. 4 is a graphical representation of an embodiment of a log-in screen.

Next the listener is asked to identify his/her geographical location. FIG. 5 is a graphical representation of an embodiment of a metropolitan area designation screen. The following list of regions is exemplary and is by no way a limiting feature of this invention.

San trancisco Bay Area Los Angeles Area

In one embodiment, in order for a listener to access the web page, the listener must have the serial number of this radio. On the sign-on screen, the web page asks for the serial number. If this is the first time the radio is registered, the web page asks the listener to create a sign-on name and a password. From then on, each time the listener accesses the web site, he will be asked both the sign-on name and the password.

The web page also asks the listener for an e-mail address. In the future, if the listener forgets his password, he can request the web page to email the password to the designated email address.

Each ODR unit has a unique serial number. Furthermore, the serial number is made- up in a way such that there will be one or more checksum digits. All serial numbers, when combined with one or more checksum digits, add up to a unique number. This prevents a vandal from entering random numbers and manipulating other people's configurations.

Below are descriptions of functions that can be customized in a typical embodiment of the invention. d. Enabling or Disabling Automatic Start

The web page presents the option to choose between "Enable Auto Start" and "Disable Auto Start." Selecting "Enable Auto Start" allows the radio to automatically begin playing On-Demand Radio when it is turned on, even if the radio has been left in the AM or FM setting. Selecting "Disable Auto Start" does not allow the radio to automatically begin playing On-Demand Radio when it is turned on. e. Including and Excluding Topics

A listener can customize whether he wants to have a certain topic included in his play list. On the web page, all the possible topics are listed. The listener simply clicks on the topics that he is interested in and un-click the topics that he is not. In one embodiment, traffic and top news are standard topics and cannot be removed. If customization is not done, the default play list, in a typical embodiment, includes all of the following topics in the specified sequence.

Default Play List

Traffic Update

Stocks

Advertisements

In an alternative embodiment, the Customizer will allow the user to select from multiple pre-set default patterns of interests and preferences. If the user selects one of the pre-set default patterns, that pattern becomes the user's profile. In a typical embodiment, the pre-set default patterns control the selections for the Play List as well as any and/or all other user-customizable sets of information. As an example, the user could select a "Business Person's Profile." The Business Person's Profile would reflect selections in the Play List and the other user-customizable sets of information that are of interest to a typical business person. Other patterns available include but are not limited to: Student, Housewife, Engineer, Salesperson, Sports Fan, etc. The following list of topics and the associated descriptions is exemplar}' and is by no way a limiting feature of this invention. Below, each topic area identified in the following table is described in greater detail.

f. Selecting the Sequence of Topics

Once a listener has selected the topics of interest, the listener is asked to define the sequence in which the topics are to be played if there is no listener intervention. In a typical web site embodiment, a list of the selected topics is displayed. For each topic, the listener can click on the up or down arrow, which moves the topic forward and backward in the play sequence. A typical default play sequence is displayed in the table below:

In one embodiment, each topic is displayed with a small input box next to it; the listener enters a number into each box to represent the order in which the topic is played. In another embodiment, the user is given the opportunity to click and drag topics to the play order. g. Traffic

The Customizer allows the listener to define a customized traffic report.

In a typical web site embodiment, the web site presents a number of cosmopolitan areas, such as Los Angeles or the San Francisco Bay Area, for the listener to choose from. FIG. 6 is a graphical representation of an embodiment of a Traffic screen for a typical metropolitan area, which in depicted example is the Los Angeles area.

A typical web site embodiment also presents an option to define custom commute routes and/or often-traveled routes. The web site shows a map of the major highways and boulevards and the locations of the speed sensors. In one embodiment, the listener clicks on the "Define New Route" button and then drags a pointer through the highway and streets that he frequents. In another embodiment, the listener clicks on the segments of the freeways on which the listener commutes. In another embodiment, the listener is asked to provide a beginning-of-commute address and an end-of-commute address. The listener then identifies whether he travels on the route one-way or both ways by clicking on the appropriate box. Once a route is defined, On-Demand Radio will report traffic speed and congestion on specified directions of the route.

Along the route there may be stretches of highways or streets where traffic sensors are not present. In one embodiment, on the web site's customization map, the sensors are clearly marked, so he can see where the sensors are missing along his route. When new sensors are installed after the listener has defined his route, they are automatically included in the group used for reporting.

The following list of locations for the San Francisco Bay Area is exemplary and is by no way a limiting feature of this invention.

1.) Customized Traffic Routes

In an embodiment that provides for user definition of customized traffic routes, the listener defines the listener's custom routes on the Customizer web site. FIG. 7 is a graphical representation of an embodiment of a custom commute route screen. A listener tells the Customizer what freeways the listener travels regularly. The listener defines the beginning and end locations of the commute on each freeway. The listener further defines the time block in which he will be traveling on this route. The listener also defines what days of the week he travels on this route. In a typical embodiment, the resulting data is written to FILTER.DAT which is a control file described more fully below.

Traffic congestion information is sent in Broadcast data. The data records include but are not limited to: the freeway name, the direction, and the specific location of the congestion. The microprocessor in the ODR unit is programmed to compare traffic records in the Broadcast data against traffic records in FILTER.DAT, and against the ODR unit's internal clock to decide if the specific congestion information should be played to the listener. In one embodiment, when there is no congestion on the custom route, no voice files are played.

For example, on a particular weekday morning, a few congested areas of freeways on a listener's customized route to work are identified and are broadcast by the Broadcast System. The ODR unit plays voice files to describe the congestion on the customized route depending upon the listener's customized route setup. For instance:

"There is congestion on your way to work - Northbound Highway 101 is stopped at Lawrence Expressway; Westbound Highway 380 is stopped at El Camino Real." On a Sunday morning, a few congested areas of freeways on a customized route to church are identified and broadcast by the Broadcast System. The ODR unit plays voice files to describe the congestion on the customized route. For instance:

"There is congestion on your way to church - Eastbound Highway 237 is stopped at Great America Parkway."

2.) Customizer Options to Setup Custom Traffic Routes

In a typical embodiment of the invention, the Customizer gathers the following information concerning custom traffic routes:

Name of custom route: The listener picks a name for the custom commute route from a selection of names. The following list is an example.

To Work

To School

To Home

To Church

To Weekly Recreational Event

To Weekend Activities

Custom Route 1

Custom Route 2

Time: The listener picks the approximate time of day when the conditions on this custom route should be played. The following list of options is an example.

Morning - 5 to 10 (military time) Afternoon - 15 to 20 Night - 20 to 5 All times - 0 to 24

Day of week: The listener picks the days of week when the condition on this custom route should be played. In one embodiment, the days are written as MTWHFSX where: M - Monday T - Tuesday W - Wednesday H - Thursday F - Friday S - Saturday X - Sunday

The Customizer allows the following choices for the listener: 10

Weekdays - MTWHF Weekends - SX Everyday - MTWHFSX Monday - M Tuesday - T Wednesday - W Thursday - H Friday - F Saturday - S Sunday - X

^2υ Highway selection: The listener picks out segments of highways on which the user typically travels from a map by clicking on the segment. In another embodiment, the user enters the freeway ingress and egress (exit numbers) that the user typically uses. Concurrent with the listener's choices,

²⁵ the list of highway segments entered up to that point is displayed in graphics form.

Fromlocation: The listener identifies where on a highway the listener's

_^ trip starts.

Tolocation: The listener identifies where on a highway the listener's trip ends.

35 Edit: The listener can use this feature to edit a previously defined custom route. The listener can change all aspects of the route. h. Stock Report

In one embodiment, the listener is asked to specify, by stock symbol, the stocks in which the listener is interested. As the listener is typing the symbol, all symbols that start with the letters already typed are displayed. The listener can then use the arrow keys to select one stock from the list or can continue typing. There will also be a look-up option, which translates the company name into stock symbol. The default is: Dow Jones, NASDAQ, S & P 500 indices, plus a collection of popular, and/or local stocks.

In another embodiment, the listener is instead asked to choose from a full list of stocks on recognized stock exchanges, e.g., NYSE, AMEX, OTC, etc. In yet another embodiment, the Customizer gives the listener a limited list of choices of stock. Each choice is listed with a check box next to it. The listener can choose one or more of the listed stocks.

The following list of stocks is exemplary and is by no way a limiting feature of this invention.

FIG. 8 is a graphical representation of an embodiment of a Stock selection. i. Top News

Top News is an extraction of important news from all categories, regardless of the listener's preferences. In a typical embodiment, there are no settings for Top News. That is because Top News is of such importance that all listeners will be interested in receiving the information regardless of their preference settings. j. News Topics

For each News Topic, there are several subtopics. The listener is given the capability to indicate a different interest level toward each subtopic. The Customizer will give the following choices for each subtopic. The following list of Interest Level Choices is exemplary and is by no way a limiting feature of this invention.

k. General News

Certain General News subtopics are available for the listener's selection. For each General News subtopic, the Interest Level choices described above are available. The following list of general news subtopics is exemplary and is by no way a limiting feature of this invention.

World News

National News

Local News

FIG. 9 is a graphical representation of an embodiment of a General News screen. In another embodiment, the user is given the option of several ways in which to partition the news, including but not limited to: 1.) dividing the content evenly among all subtopics; 2.) requesting that World and National News be given greater coverage; or 3.) requesting that mostly local news be provided.

1. Business News

In a typical embodiment, certain Business News subtopics are available for the listener's selection. FIG. 10 is a graphical representation of an embodiment of a Business News screen. For each Business News subtopic, the Interest Level choices described above are available. The list of Business News subtopics in FIG. 10 is exemplary and is by no way a limiting feature of this invention. m. Sports News and Scores

A selection of sports types is made available for the listener's choice. For each subtopic, the Interest Level choices described above are available. FIG. 1 1 is a graphical representation of an embodiment of a Sports News screen. The list of sports news subtopics in FIG. 1 1 is exemplary and is by no way a limiting feature of this invention. In one embodiment, the user is given the opportunity to request that all sports be covered "evenly."

In one embodiment, for each Sports News subtopic, there is an on-screen "button" next to it labeled "Track scores." The "Track scores" title is exemplary and is in no way a limiting feature of this invention. Clicking on the button opens up another screen with a list of teams that the listener can track the scores of.

FIG. 12 is a graphical representation of an embodiment of a Sports Scores screen. The list of Sports Teams and Leagues depicted in FIG. 12 are exemplary and is in no way a limiting feature of this invention. The following list of sports sub-topics and teams is further exemplary and is in no way a limiting feature of this invention.

n. Entertainment News

In one embodiment, an Entertainment News topic is provided. FIG. 13 is a graphical representation of an embodiment of an Entertainment News screen. Certain entertainment news subtopics are available for the listener's selection. For each subtopic, the Interest Level choices described above are available. The list of entertainment news subtopics depicted in FIG. 13 is exemplary and is in no way a limiting feature of this invention. Similarly, the following list of entertainment news subtopics is further exemplary and is in no way a limiting feature of this invention.

TV

Movies

Books

Theater

Pop Music

o. Other Types of News

Many other types of news Topics and subtopics are possible. The list of Topics identified in this application are exemplary and are by no means a limiting feature of this invention. FIG. 14 is a graphical representation of an embodiment of a Science News screen. FIG. 15 is a graphical representation of an embodiment of a Health News screen. FIG. 16 is a graphical representation of an embodiment of a Travel News screen. FIG. 17 is a graphical representation of an embodiment of a Technology News screen. The list of subtopics in FIGS. 14 through 17 is exemplary and is by no way a limiting feature of this invention. p. Advertisements

In one embodiment, the user is given the opportunity to indicate interest in Advertisements that relate to certain subtopics of information and/or products. Below is a sample list of advertising subtopics from which a user could select. For each advertising subtopic, the Interest Level choices described above are available. Furthermore, in one embodiment, the user is given the option of specifying geographical location/boundaries for stores that advertise products and/or service for which the user has indicated some interest. If the user does not specify geographical location restrictions, the system will default to restricting locations within a certain radius of the user's zip code, for instance, 20 miles. In one embodiment, the user is given the option of restricting receipt of Advertisements to particular brand name and/or types stores. The following list of Advertising subtopics is exemplary and is by no way a limiting feature of this invention.

In one embodiment, the user's indication of interest in particular advertisement subtopics is used to target scheduling of Commercials. That is, if the user specifies high interest in Beauty-related advertisements, then the system will receive with priority Beauty- related commercials and/or will prioritize Beauty-related commercials in the timing and/or frequency and/or the amount of detail provided of these commercials.

In one embodiment, the user is given the option of requesting Commercial Alerts.

Commercial Alerts are similar in function to Stock Alerts. The user can specify a particular Store, product, or other commercial basis. The user can specify a particular threshold price for which the user wants to be alerted. For example, the user is in the market for a new car of a particular model. The user can specify the model of car for which the user is looking. The user can specify a particular price for the car. The user can request that the user be notified of car dealers that offer the specified model for a price at or less than the threshold price.

The above-described Internet web site is an exemplary embodiment and is not meant in any way to be a limiting feature of this invention. Rather, there are many ways in which the user can specify the requested information, including but not limited to: a) User completion of a telephone survey and questionnaire conducted for the Broadcast System; b) a hard copy survey and questionnaire that is submitted by mail or facsimile to the Broadcast System center. In another embodiment, the Broadcast System broadcasts information regarding each radio show into the ODR units. The user uses the dials and buttons on the faceplate of the ODR unit to indicate which program to record.

FIG. 18e is a flow diagram of an alternative embodiment of the way in which the user establishes an In-Unit Profile. In FIG. 18e, the user installs set-up software in the users personal computer (701), a palm computer, handheld computer, laptop computer, or like device is used to set-up the user's Control Setup Specifications. Unlike the above Internet and survey embodiments, the palm computer, handheld computer, laptop computer, or like device embodiment is used to set-up the user specifications (702) and transmit them directly to the ODR unit (703); the computer device communicates In-Unit Profile information to the ODR device through, e.g., an infrared transceiver (FIG. 19a, (1240)) in the ODR device. A number of other ways to communicate the information from the personal computer to the ODR unit can be used and the description of an infrared transceiver as the receiving component is exemplary and is not in any way meant as a limitation of the invention. The ODR unit receives the In-Unit Profile (704) and stores the information (704) in memory (210).

In one embodiment, an interface device is provided for transferring data from the computer to an audio cassette compatible device and/or to some other media device, including but not limited to: CD, CD-ROM, DVD, data card or like device. In this embodiment, the user would carry the interface device to the user's car cassette or like device (as described above) player for outputting the information. the user can specify the requested information, including but not limited to: a) User completion of a telephone survey and questionnaire conducted for the Broadcast System; b) a hard copy survey and questionnaire that is submitted by mail or facsimile to the Broadcast

System center. In another embodiment, the Broadcast System broadcasts information regarding each radio show into the ODR units. The user uses the dials and buttons on the faceplate of the ODR unit to indicate which program to record.

FIG. 18e is a flow diagram of an alternative embodiment of the way in which the user establishes an In-Unit Profile. In FIG. 18e, the user installs set-up software in the users personal computer (701), a palm computer, handheld computer, laptop computer, or like device is used to set-up the user's Control Setup Specifications. Unlike the above Internet and survey embodiments, the palm computer, handheld computer, laptop computer, or like device embodiment is used to set-up the user specifications (702) and transmit them directly to the ODR unit (703); the computer device communicates In-Unit Profile information to the

ODR device through, e.g., an infrared transceiver (FIG. 19a, (1240)) in the ODR device. A number of other ways to communicate the information from the personal computer to the

ODR unit can be used and the description of an infrared transceiver as the receiving component is exemplary and is not in any way meant as a limitation of the invention. The ODR unit receives the In-Unit Profile (704) and stores the information (704) in memory (210).

In one embodiment, an interface device is provided for transferring data from the computer to an audio cassette compatible device and/or to some other media device, including but not limited to: CD, CD-ROM, DVD, data card or like device. In this embodiment, the user would carry the interface device to the user's car cassette or like device (as described above) player for outputting the information.

The ODR device can also be integrated with a cellular phone such that the combination of the ODR device and the cellular phone is a standalone device. The entire ODR system can also be integrated into the car's sound system, cellular phone system, and/or any combination of these devices.

In a system that includes integrated ODR and cellular phone elements, a backlink to a centralized network, such as, but not limited to, the Internet is provided. Any data collected by the ODR system can then be transmitted to the centralized network ("backlink"), e.g., to a web site. Data collected by the ODR system includes, but is not limited to: Usage of the ODR system by the user; usage of the radio unit by the user, including but not limited to what music and/or radio stations the user listens to. In an alternative embodiment, one or more of the above-described elements, including, but not limited to: A radio, an ODR unit, a cellular telephone, laptop computer, palm computer, and similar devices remain as standalone units but communicate with the other elements of the system by means of wireless communications. In another embodiment of the invention, wired communications, such as an automobile network, ties communications of one or more of these various system elements. In a networked environment, the ODR is capable of using data provided by other elements of the network, as well as providing data and exerting control over the other elements of the network. In the preferred embodiment, the user/listener initially sets up the user/listener's profile by selecting the categories of information provided by the Internet web site that the listener/user is interested in receiving. FIG. 3 is a conceptual diagram representing the information potentially maintained for each user/radio unit.

User-specified options will include, among other things, allowing the user/listener to specify whether the data is to be downloaded at that instant, to set-up a schedule by which to have the information downloaded at another time, e.g. 5:00 am every morning and 4:00 pm every afternoon, or to download the information by user request.

In one embodiment, the ODR unit updates the In-unit Profile with information collected by, and/or deduced by, the ODR unit. The ODR unit collects information concerning the user. For instance, the ODR unit collects information concerning the user's usage of the ODR unit. The ODR unit collects information concerning the programs, types of music, types of stories, etc. to which the user listens. Similarly, the ODR unit can collect and deduce many types of information from embodiments in which the ODR communicates with other intelligent devices, including but not limited to: a cellular telephone.

C. On-Demand Narrowcasting

According to the present invention, certain or all aspects of the user's Control Set-up

Specifications can be used by the Broadcast System to narrowcast information to the listener's individual radio unit ("On-Demand Narrowcasting"). In one embodiment, the Broadcast

System constructs a header that contains information that targets one or more radio units. Targeting is accomplished, by, for instance, specifying, one or more unit identification ("ID") numbers. In the header, unit ID numbers can be specified individually, and/or by one or more ranges. Other types of user Control Set-up Specification information can be specified in the header to target a particular broadcast. For instance, in one embodiment, the unit type can be specified in the header; information can then be narrowcast by unit type; unit type would be information that could be collected from the user and/or inferable from the unit ID. As another example, a particular zip code can be inserted in the header so that a particular set of information is transmitted to all units for which user's have specified that zip code.

Furthermore, any information contained in, or which can be inferred from the user's Control Set-up Specification information can be specified in a header for purposes of targeted narrowcasting. For instance, the user-specified Interest Level choice can be used to determine whether or not to send the user a brief version or detailed version of a particular story. As an example, the Broadcast System would build a header for a detailed version of a story concerning IBM with appropriate codes for high interest/business news listeners; a header for a brief version of the same story would contain coding to indicate a lower level of interest for business news. If a particular user specified high interest for business news, then the user's ODR would find a match with the header for the detailed IBM-related story. If a particular user specified a lower level of interest for business news, then the user's ODR would find a match with the header for the brief version of the IBM-related story.

In an alternative embodiment, the Broadcast System indicates that a particular detailed version of a story about IBM is a detailed business story. The receiver at the ODR unit will examine the user's preferences. If the user has indicated a high interest in business stories, then the ODR unit will receive the detailed story.

As another example of the way in which the user-specified Control Set-up Information is used, information concerning the user-specified custom commute route, as described in more detail below, can be used to target advertising information. As an example, the user specifies a commute route that ends at a particular address or area of a large metropolitan area ("end-of-commute location"). The Broadcast System can use that information to target narrowcast advertisements for, e.g., restaurants, shops, retailers, services, etc. that serve the vicinity of the user's end-of-commute location. To accomplish the targeting narrowcast in this particular example, the Broadcast System builds a header that contains one or more of the following: a) ID's for radio units that belong to users that have identified an end-of-commute in a particular area (areas can be defined according to, e.g., local mapping standards such as the Thomas Guides); b) an end-of-commute area ID; and/or c) the end-of-commute address designated by the user.

One embodiment of the present invention provides that the radio unit contains more than one tuner. One advantage of using multiple tuners is that the total bandwidth is increased. In one multiple-tuner embodiment, there is a master broadcast frequency in which broadcasts in other frequencies are synchronized and/or linked. In the case of a radio unit with multiple tuners, the restaurant's location-tied header and associated advertisement is periodically broadcast on a continuous basis on a particular frequency. Such advertisements could be broadcast on, for instance, a carousel of advertisements that are broadcast, and then rebroadcast according to the carousel schedule. When the commuter approaches the location, the radio unit interrupts current programming and announces the restaurant's advertisement before continuing current programming. If the user has been listening to a regular radio broadcast, the targeted advertising can be played as an overlay of the regular radio broadcast, for example, when the regular radio station is broadcasting/playing commercials, in which case, the regular broadcast will resume at the point where the interruption ceases. In another embodiment, the advertisement causes an interruption in the regular radio broadcast, and the unit continues to receive the information of the regular radio broadcast and uses buffer space and/or memory in which to store the interrupted broadcast. When the targeted advertising is completed, the unit returns to play the information that was stored in the buffer and/or memory. Various methods can be used to synchronize the interrupted and further real-time radio broadcasts. Similarly, if the user is listening to On-Demand Radio programming, the ODR programming can be interrupted to announce the targeted advertiser's commercial; alternatively, an advertisement can be scheduled to be delivered to the user as part of the ODR programming.

Other factors can be considered in targeting advertising in accordance with the above- described approach to narrowcasting. For instance, time of day, day of the week, season of the year, etc. can be used to target advertising.

According to this aspect of the invention, the Control Set-up Specifications can be specifically narrowcast for reception by the particular user's individual radio unit, which is a process referred to herein as "On-Demand Narrowcasting." According to this aspect of the invention, "On-Demand Narrowcasting" means that the information is broadcast over the standard frequency, but is coded so that only a single unit, or a subsection of the total population of radio units, are identified in the header for the information. Accordingly, only a single ODR unit, or a subsection of the total population of ODR units, will select and capture the information because the information contains, or is preceded by, a header containing that particular unit's ID, or the particular unit's ID falls within one of the ranges specified in the header.

FIG. 18a is a graphical representation of one embodiment of the procedure by which On-Demand Narrowcasting is accomplished. In the depicted embodiment, for each news story, the database of Unit/User Control Set-up Specifications (1000) in the National

Operating Center ("NOC") is searched. Comparisons are made (1030) between the keywords

(1020) contained as part of the news story format (1010) and interests and/or preferences for each unit/user (1080). Matches (1040) between the keywords for a particular story and the profile of interests for a particular unit/user cause a header for the story to be constructed

(1050) containing the unit ID for the matched unit (1060). The header is then transmitted prior to, or as part of, the news story (1070). In another embodiment, the database of all

Units/User Control Setup Specifications in a particular geographical region is searched for matches between the story and the preferences of the listeners. A popularity index of the story is generated based on the analysis of the database. The popularity index of several stories are then compared to identify the more popular stories; the more popular stories are then broadcast.

In an alternative embodiment, "narrowcasting" is accomplished by broadcasting everything for analysis by each ODR unit. FIG. 18b is a flow diagram depicting one embodiment of the way in which In-Radio Profiles are established so that "narrowcasting" can be accomplished. In FIG. 18b, the user inputs personal information and information concerning the user's interests and preferences (100-130), using for example, user- interface setup screens on a web site. The user's information is stored in memory along with the information for other users (1000), e.g., at the Broadcast System's NOC. The NOC Broadcast System then builds one or more records containing each user's information (200). Each user's record contains the unit ID to which the user information is targeted. The collection of one or more records for the same ODR Unit ID is called a Profile. The Broadcast System then transmits the user's information (202). The individual ODR unit receives all transmitted Profile information, but only extracts the information containing the ODR unit ID for storage in the memory of the ODR unit (204). Once the Profile has been stored in the memory of the ODR unit, it is referred to as an In-Unit Profile. FIG. 18c is a flow diagram of one embodiment of the way in which "narrowcasting" is accomplished using In-Unit Profile information. The ODR unit receives all ODR header information transmitted to it as Broadcast Signal (250). If the header is for a standard Alert, the ODR unit receives the Alert and prepares the Alert for delivery to the user (252-253). If the header is not for a standard Alert, then the ODR unit analyzes the header information by comparing the header to the information in the In-Unit Profile (255). When the ODR unit identifies that a header is consistent with the In-Unit Profile (256), the unit extracts the related information (story, advertisement, commercial, update, alert, etc.) and stores (256) the information in the memory (210) of the ODR unit for later playback.

FIG. 18d is a block diagram of one embodiment of ODR Unit logic using In-Unit Profile information to store information matching the In-Unit Profile. In FIG. 18d, the Receiver (300) receives the Broadcast Signal (1072). The User Profile in memory (210) is used by the ODR unit to determine what information to receive and store in memory (210) for later playback through the Player (310). The Player (310) uses the User Profile in memory (210) to determine what information to play and in what sequence.

On-Demand Narrowcasting a particular user's Control Set-up Specifications is meant as an exemplary embodiment of the invention and is not meant in any way to be a limiting feature of the invention. Rather, other types of information can be specifically targeted by unit ID and/or one or more ranges of unit ID's. In the preferred embodiment, the Internet, including but not limited to, the online web pages completed by the user specifying the user's Set-up Control Specifications, e-mail, and custom-purpose programs, are used to control the functions of the Preferred Radio device — a device which is not directly connected to the Internet.

Applications of this aspect of the invention are not limited to controlling the On- Demand Radio. Rather, this aspect of the invention can be used to control the configuration of many types of devices, including, but not limited to, inexpensive household or mobile appliances. This aspect of the invention is particularly useful for controlling the configuration of devices that tend to be located in diverse locations and that may not be attached to an electrical outlet and/or computer network. The configuration changes in the said device can be controlled to include, but are not limited to: a) a new way of responding to input to the device, b) a new way of sending output from the device, including the use of new, downloaded message, or c) a new way of handling the internal operations of the device. The data sent from the Broadcast System can be in different forms, including but not limited to:

1.) control codes which are keywords telling the receiving unit what to doe; or 2.) actual software machine code. Encryption can be used to prevent the unauthorized change of the device. The manner in which configuration control is accomplished is further explained below. 1. Web Page Customizer

A web page is set-up to contain various configurable conditions of a device not directly connected to the Internet. A person is asked to select various options on the web page. Upon the completion of the input, the web page submits the data to a transmitter, which then sends one or more strings of data over the radio frequency to the said device.

2. E-mail Customizer

A person sends a piece of electronic mail to a specific address. In the mail, either in the header or body, are keywords that are intended to control the function of a device not directly connected to the Internet. In another embodiment, the address to which a user sends e-mail directly or indirectly indicates the function to be performed. The receiver of the e-mail is a computer, which interprets the keywords and then sends out one or more strings of data over the radio frequency to the specified device.

3. Custom Purpose Program

A custom-purpose program is set-up on a person's computer. When run, this program asks the person to define the configuration of a device not directly connected to the Internet. Once the user inputs the data, the program sends keywords to a receiving computer on the Internet, which then sends one or more strings of data over the radio frequency to the said device. In another embodiment, the program sets up the computer such that the user can send the data to the receiving device through, e.g., infra-red communications.

4. Configuration Across Radio Frequency

One or more strings of data are sent across radio frequency with information to configure a particular device — one that is not directly connected to the Internet or a computer network. As part of the broadcast, an identification is included, which uniquely addresses the said device. The device can be the only device responding to this identification, or as part of a class of devices responding to this identification. Upon detecting an identification match, the said device or devices reconfigures itself (or themselves) according to the instructions in the broadcast.

D. In-Unit Profile

According to the present invention, and as an alternative to, or in combination with, On-Demand Narrowcasting, the Broadcast System transmits certain or all aspects of the listener's Control Set-up Specifications which are received by, and installed in, the listener's individual radio unit ("In-radio Setup Specifications").

The user's ODR unit includes a radio frequency receiver, a memory, a microprocessor and storage system. In an embodiment in which the ODR unit is integrated with a radio, the ODR unit includes a radio frequency receiver (300), a memory (210), a microprocessor and storage system (320), and a player (310) as depicted in FIG. 19b. Some portion of the Control Set-up Specifications' user profile is stored in the memory of the user's receiver device system; the information will be used to select from all broadcast information. Selected information is stored in the memory for future retrieval.

E. On-Demand Reception

According to the present invention, the listener's In-Unit Profile can be used by the listener's individual radio unit to select information delivered by the Broadcast System according to the individual listener's specified interests ("On-Demand Reception"). In one embodiment, the receiver has the capability to scan the frequencies and/or match key tokens from each broadcast in order to find the frequency in which the Broadcast System broadcast(s).

A program broadcast can consist of multiple numbers of files (voice and/or other types of data). Alternatively, a program can be one single file. The data can have markers in certain locations within the file to mark the boundary from one story to another and/or locations for commercials.

In one embodiment, the listener's ODR radio unit continuously receives information delivered by the Broadcast System. In an alternative embodiment, the listener's ODR radio unit receives ODR broadcasts on a periodic schedule, for instance, every five minutes. This schedule of reception is referred to as an "ODR reception period." At the beginning of the example five minute period, the ODR unit looks for headers that match information for which the ODR is looking and which should be selected by the ODR unit. To the extent that one or more headers are encountered that match parameters for the particular ODR unit, the ODR unit will continue to receive the additional information and store the information in the memory of the ODR unit. Once the ODR unit has completely stored all broadcast information for the particular ODR unit, the ODR unit will enter a "sleep" mode until the beginning of the next scheduled ODR reception period. If the ODR unit does not detect any headers that match parameters for the particular ODR unit, then, without receiving the additional data, the ODR unit enters the sleep mode until the beginning of the next scheduled ODR reception period.

In one embodiment of the present invention, the user specifies the typical amount of time that the user has to listen to the radio. For instance, the user can specify, when setting up the Control Set-up Specifications, that the user's daily one-way commute is typically one hour. According to the invention, the system will customize the arrangement and/or amount of information received and stored according to the amount of time specified by the user as a typical listening session. The system will also determine whether to use a short version or detailed version of a particular story based upon the In-Unit Profile.

As is described further below, there are memory and navigational buttons in one embodiment of the invention by which the user can specify and/or reorganize the priority by which the user wants to listen to the ODR received information. According to the invention, the system will customize the order of and amount of information that the system receives and stores according to one or more of the following: a) The user- specified amount of time of a typical listening period; and/or b) The user-defined priority of topics as defined by the user defined buttons on the device.

According to the present invention, methods and systems are provided for downloading data from a host computer, several host computers, or one or more web sites to a radio unit device with memory (random access memory) sufficient to hold said data. In accordance with Control Set-up Specifications and/or In-Unit Profile, the data will be transmitted to. selected by, and/or stored in the memory of the listener's individual radio unit. One embodiment of the way in which the In-Unit Profile is used to control the reception of information related to the user's specified interests is described below. In one embodiment, the broadcast is an analog AM broadcast. In this embodiment, the Broadcast System inserts the keywords at a point in time after the beginning of the story. In this embodiment, the receiver is programmed to synchronize story capture. A start of story signal (trigger) is provided at the start of each story. Synchronized story capture will be accomplished in the receiver with the help of the trigger and a memory buffer of sufficient size to provide for the following procedure: the receiver will receive the trigger signal and the news story; the receiver is programmed to begin recording the story into memory; some seconds later, it will receive the keyword coding for the story; if the keyword coding matches the preset preference filters for the particular unit as indicated in the In-Unit Profile, then the unit has identified a "hit" and the unit will continue to record the story; otherwise, recording will be abandoned and the unit is reset to wait for the start of the next story.

1. Receiver

In one embodiment, the Receiver is responsible for selectively screening the broadcast for information that the listener wants. In this embodiment, the Receiver uses information from Filter.DAT and selectively picks up data from Broadcast data to save in PlayList.DAT, PhraseList.DAT, and Commercials.DAT. These three files contain the control data and pointers that determine the content and sequence of the speech played. All of the files mentioned are described further below.

In an embodiment in which the ODR unit is integrated with a radio, and where the tuner/receiver is shared between the ODR and the radio, if the user is not using the radio to receive any other station, then the ODR radio will enter an idle mode in which the tuner will be tuned to the ODR data broadcast station to receive data throughout the day.

In a typical embodiment, only news stories with the appropriate keywords will be selectively stored into memory. This way, all the news stories desired by the user will be in memory and ready to play when the user turns on his radio.

2. Player

The Player takes the information from the Play List and plays the voice files accordingly. Sound output from the Player includes, but is not limited to, one or more of the following: a) cassette adapter for the car cassette; b) Radio frequency rebroadcast (such as FM) from the receiver to the car radio; c) Player's own speakers; and/or d) Earphone output. The Player accepts user navigation control such as the BACK and FORWARD buttons, as well as other faceplate buttons. In one embodiment, playback will be by voice synthesis. Voice synthesis can be achieved either by software, using a powerful microprocessor chip, such as the Pentium, or it can be achieved by a special dedicated DSP chip in conjunction with ROM's.

In a typical embodiment, the news stories will play back one by one. If the user finds no interest in the story, the user can push a button to skip to the next story.

In another embodiment of the playback process, a summary mode is followed by a playback mode. During the summary mode, all the summaries are first read back one-by-one. The user indicates his interest in a story by pushing a button to select. After all the summaries have been read through, then the unit enters the playback mode in which the selected stories are now read out in detail.

3. The Broadcast Data The following table describes various fields for a typical embodiment of broadcast data.

In a typical embodiment, there are several different types of records, each with different fields. a. Filter

Download of Filter.DAT into the radio.

Phrase

Download of spoken phrases into Phrases.DAT.

Commercials

Download of commercials into the radio.

Story

Download stories, including stocks, sports score, and traffic, into the radio.

In order to process custom traffic routs, the definition of fields in a typical embodiment of Broadcast data for a traffic update is as follows:

Type This field indicates that this record is of the special type Traffic.

Highway The highway name of the traffic congestion. Direction The traffic direction where the congestion occurred. Mile The mile number from an fixed reference. Region Used for non-customized traffic data, this field indicates the region where the congestion occurred.

The Interest Level, which is used to sequence the order of play, is not used in the Traffic section.

The record in a typical embodiment of Broadcast data that provides for custom traffic routes is as follows: [Operation=Add/Replace] [ID=2002] [Name=ST-880 in Oakland] [Type=Traffic] [Time=5] [Highway=880] [ Direction^] [Mile=45] [Region=SF East Bay] [VoiceFile=ST-880 in Oakland.wav]

[Operation=Add/Replace] [ID=2003] [Name=ST-101 in Navato] [Type=Traffic] [Time=5] [Highway=101] [ Direction=Northbound] [Mile=119] [Region=SF North Bay] [VoiceFile=ST-101 in Navato.wav]

In a typical embodiment, to further provide for delivery of information concerning custom traffic routes, phrases are defined for Broadcast data that identify the custom route name, and are played prior to the list of traffic s in that route. The phrases are defined in the same manner that makes announcing a phrase possible for each subtopic. The ODR unit matches these phrases against the route name in Filter.dat and plays them when it needs to announce a traffic condition for a custom route. The record formats below are typical:

Name Record format To Work [Operation=Add/Replace] [ID=2007] [Name=Subtopic Separator] [Type=Subtopic Separator] [Time=5] [Topic=Traffic] [Subtopic=To Work] [VoiceFile^To Work.wav]

To School [Operation=Add/Replace] [ID=2007] [Name=Subtopic Separator] [Type=Subtopic Separator] [Time=5] [Topic=Traffic] [Subtopic=To School] [VoiceFile=To School.wav]

To Home [Operation=Add/Replace] [ID=2007] [Name=Subtopic Separator] [Type=Subtopic Separator] [Time=5] [Topic=Traffic] [Subtopic=To Home] [VoiceFile=To Home.wav]

To Church [Operation=Add/Replace] [ID=2007] [Name=Subtopic Separator] [Type=Subtopic Separator] [Time=5] [Topic=Traffιc] [Subtopic=To Church] [VoiceFile=To Church.wav]

Weekly [Operation=Add/Replace] [ID=2007] [Name=Subtopic Separator]

Recreational [Type=Subtopic Separator] [Time=5] [Topic=Traffιc]

Event [Subtopic=To Weekly Recreational Event] [VoiceFile=To Weekly Recreational Event.wav]

Weekend [Operation=Add/Replace] [ID=2007] [Name=Subtopic Separator] Activities [Type=Subtopic Separator] [Time=5] [Topic=Traffιc] [Subtopic=To Weekend Activities] [VoiceFile=To Weekend Activities.wav]

Custom Route 1 [Operation=Add/Replace] [ID=2007] [Name=Subtopic Separator] [Type=Subtopic Separator] [Time=5] [Topic=Traffic] [Subtopic=Custom Route 1] [VoiceFile=Custom Route l .wav]

Custom Route 2 [Operation= Add/Replace] [ID=2007] [Name=Subtopic Separator] [Type=Subtopic Separator] [Time=5] [Topic=Traffic] [Subtopic= ustom Route 2] [VoiceFile=Custom Route 2.wav]

4. Control File Descriptions

In one embodiment of the invention, there are four control files. The following table describes the purpose of each file. The description of the files below is exemplary and is in no way limiting of the invention. Furthermore, the file embodiments are described below in text form. The description of the file embodiments in text form is for description purposes and is not a limitation of the invention. The data types in the files include but are not limited to: binary, hexadecimal, numeric, graphical, video or any combination thereof, compressed or not compressed.

Filter.DAT

Filter.DAT includes the definitions of the listener's profile, including the listener's interests and preferences. Filter.DAT also includes the listener-defined preference for the order of the topics and subtopics are to be played — which defines the ODR unit^'s actual play sequence. When a story comes in the broadcast, the Receiver consults Filter.DAT for the proper sequence to play. The following are the definitions of fields for Filter.DAT.

The following is one embodiment of Filter.DAT.

Filter.DAT

[Topic=Traffic] [Subtopic=Regional update, InterestLevel=3]

[Topic=Stocks] [Subtopic=Dow Jones, InterestLevel=3] [Subtopic=Nasdaq,

InterestLevel=3] [Subtopic=S&P 500, InterestLevel=3]

[Topic=Top News, InteresfLevel=3]

[Topic=General News]

[Subtopic= World News, InterestLevel=2] [Subtopic=National News, InterestLevel=2]

[Subtopic=Local News, InterestLevel=2]

[Topic=Business News] [Subtopic=Technology, InterestLevel=2] [Subtopic=Banking, InterestLevel=2] [Bio-technology, InterestLevel=2]

[Topic=Sports News]

[Subtopic=Football, InterestLevel=2] [Subtopic=Basketball, InterestLevel=2] [Subtopic=Basketball, InterestLevel=2] [Subtopic^Hockey, InterestLevel=2] [Subtopic=Golf, InterestLevel=2]

[Topic=Sports Scores]

[Subtopic=Professional Football, Subtopic2=San Francisco 49ers, Subtopic2=Dallas

Cowboys, Subtopic2=Green Bay Packers]

[Subtopic=College Football, Subtopic2=San Jose State Spartans]

[Subtopic=Professional Bassetball, Subtopic2=Chicago Bulls, Subtopic2=L.A. Lakers]

[Subtopic=College Basketball, Subtopic2=San Jose State Spartans]

[Subtopic=Professional Hockey, Subtopic2=San Jose Sharks]

[Subtopic=Professional Golf, Subtopic2=Tiger Woods]

[Subtopic=Beach Volleyball, Subtopic2=Kiraley/Stokelos]

[Subtopic=Horse Racing, Subtopic2=Bay Meadows]

[Topic=Entertainment]

[Subtopic=Movies, Preference=2] [Subtopic=TV, Preference=2] [Subtopic=Theater,

Preference=2] [Subtopic=Books, Preference-2]

In an embodiment that provides for custom traffic routes, Filter.dat describes the custom routes. The definition of a custom route in typical embodiment of Filter.dat is as follows:

RouteName This is the name of the custom route. FromTime In one embodiment, this is the time of day to play the conditions on a specific custom route. Time is described in military hours without minutes. The ODR unit compares the From Time with the ODR unit's internal clock to decide if the conditions on the custom route should be played. ToTime This is the time of day to stop playing the conditions on this custom route. Time is described in military hours without minutes. The ODR unit compares this time against the ODR unit's internal clock to decide if the conditions on the custom route should be played.

Days This is the days of the week when the ODR unit needs to track the conditions on this custom route.

The ODR unit checks the ODR unit's internal clock to see if the current day is included in the range. If so, and the time matches, the conditions on the custom route are played. Highway The highway name. This is a text field even though all freeways are names with number. Direction The direction of traffic:

Northbound

Southbound

Westbound

Eastbound

FromMile The mile marker of the beginning of the segment of freeway. It is defined in reference to a fixed zero point.

ToMile The mile marker of the end of the segment of freeway. It is defined in reference to the same fixed zero point as the From

Mile.

SortOrder This field is not used in custom routes. Rather, it is used to play non-custom route traffic data using the new Broadcast.dat traffic records. Freeway names are separated by the forward slash "/".

The Customizer writes out a predefined Sort Order for each region. The traffic record in one embodiment of Filter.dat is structured as follows:

[Topic=Traffιc]

[RouteName=To Work, FromTime=5, ToTime=10, Days=MTWHF, Highway=101, Direction=Northbound, FromMile= 14, ToMile=45, Highway=380, Direction= Westbound, FromMile=0, ToMile=4

Highway=280, Direction=Northbound, FromMile=96, ToMile=103]

[RouteName=To Home, FromTime=15, ToTime=20, Days=MTWHF, Highway=280, Direction=Southbound, FromMile=103, ToMile=96, Highway=380, Direction=Westboound, FromMile=4, ToMile=0, Highway=101, Direction=Southbound, FromMile= 45, ToMile=14]

[RouteName=To Church, FromTime=5, ToTime=10, Days=X, Highway=87, Direction=Southbound, FromMile=12, ToMile--3]

[Subtopic=SF South Bay, SortOrder=l 01/880/680/280/237/87/85/1] [Subtopic=SF Peninsula, SortOrder=101/280/80/380/92/84]

b. PhraseList.DAT PhraseList.DAT contains common phrases used on the radio. For example, the announcement of each topic at the beginning of the topic, or the announcement of the summaries of the topic are phrases.

The following is a file structure of one embodiment of PhraseList.DAT, and the default file contents in that embodiment when the listener has not customized settings. It is understood in this application that file structures are described in a generic form; the generic form should be understood to include any data type, including but not to: text, digital, audio, compressed digital, compressed audio, binary, hexadecimal, etc.

c. PlavList.DAT

PlayList.DAT in the embodiment described is the radio's actual play sequence. The Receiver takes data in from the Broadcast data, screens it through Filter.DAT, and derives at PlayList.DAT. Broadcast records whose topic is not included in Filter.DAT are discarded.

All columns are directly copied from equivalent fields in Broadcast data, with the exception of "Composite Value". This field is derived by multiplying the User Interest Level in Filter.DAT with a story's Intrinsic Value from Broadcast data. This field is used to determine the order of stories within a topic and to decide when to discard a story to free up memory.

An example PlayList.DAT data file is described below.

d. Commercials.DAT

Commercials.DAT contains all the commercials. Commercials are not part of a play sequence, but are scheduled to play at appropriate times. For example, two commercials can be played consecutively on a periodic basis, for instance, every 8 minutes. To reduce the amount of time spent scanning through the PlayList.DAT data structure for commercials, commercials are kept separately.

The following table reflects the file structure of one embodiment of

Commercials.DAT.

, r 5. Radio Unit (Receiver and Player)

When the Receiver receives a story from the broadcast, it determines which type of record it is, stores the control data inside of one of the three DAT files.

In one embodiment, a Memory Management unit is responsible for allocating memory for each story. New records received from the Broadcast add memory usage. As stories are 0 played, their memory is freed. When memory is full and there is a new broadcast record, the radio goes through the Data Discard and Save Rules below to free up more memory.

6. Data Discard and Save Rules

One role of the Receiver is to keep stories in memory up-to-date. It is understood in this application, that references made to the "Receiver" include but are not limited to: 1.) a 5 radio receiver; 2.) a radio receiver coupled to one or more tuners; and/or 3.) a logical unit including a radio receiver coupled to one or more tuners which are coupled to a microprocessor such that the Receiver is capable of performing sophisticated functions. In one embodiment, as stories are played, their records are put into a BACK-button First In/First Out ( " FIFO" ) Buffer. The FIFO Buffer's depth is set according to a variable. Once the 0 record has been displaced out of the FIFO Buffer due to additional records being put in the FIFO Buffer, the record itself plus all associated voice files are discarded.

In one embodiment, all unheard stories older than 24 hours are candidates to be discarded. However, the removal of old stories only happens when a new story comes in from the broadcast. This is done so there is a maximum number of stories kept in memory

35 at any time. As a general rule, the system strives to meet the rule that stories of low composite value to the listener do not displace stories of high composite value to the listener.

Traffic and Stocks are time sensitive. The norm is for- the broadcast to actively replace each story in memory with an updated one (using the Replace operation). Sometimes, bad reception can miss a few replacement stories. In one embodiment, any traffic, stock, and sports score older than 24 hours are immediately discarded.

Every new story coming in through the broadcast has its Composite Value calculated by multiplying the story's Intrinsic Value with the User Interest Level.

If an incoming story comes in (from the broadcast), and the Receiver needs to free up memory in order to save it, the Receiver goes through the Data Discard and Save Rules. a. Data Discard and Save Rules

Discard the story with the lowest Composite Value that has been in memory for more than 24 hours If all stories greater than 24 hours have been discarded, then discard the story with the lowest Composite Value that has been in memory for less than 24 hours. If a story in memory has lower Composite Value as the incoming story, discard it. Do not discard stories in memory that has the same or greater Composite Value.

b. Watchdog Discard Rule

In one embodiment, a "watchdog discard" mode is implemented. The watchdog rule is applied in situations where the radio is blocked from receiving broadcast for an extended period of time. This can happen if a car is parked in an underground garage for several days. It would be inappropriate for the radio plays old information as if it has just happened.

Under the watchdog mode, a watchdog task regularly checks PlayList.DAT and Commercials.DAT to see if every record in memory has a time stamp greater than 24 hours. If this condition is true, discard all records.

F. User Interface

According to the present invention, the listener's individual radio unit provides methods, systems and apparatus by which the listener can request specific information stored in, or receivable by, the listener's individual radio unit ("User Interface"). In one embodiment, the user interface apparatus consists of a Preferred Radio and a small handheld remote control connected to the Preferred Radio, which can be a wired or wireless remote.

In one embodiment, the Preferred Radio is an ODR device that includes, among other things, a CPU programmed to, among other things, interface with the user and to retrieve data, a memory for storing data, voice reproduction circuitry, a voice synthesizer for converting the data into voice, and a cassette interface for outputting the sound of the audible data through the radio unit's speaker through the magnetic heads. To minimize memory usage, the data will be preferably stored in a compressed form.

For car radio units, the remote control will provide for simple functions and a minimal number of keys so that the user can navigate through the stored information.

The dialog between the user and the system will be very similar to a normal computer terminal interface with the distinction that, instead of displaying visual information for response, audible signals will be generated to prompt for input. Listeners input can be through physical commands as through the remote, and/or keys on the radio unit. In an alternative embodiment, listener input is provided through a speech recognition interface built into the radio unit. In one embodiment, the remote control unit is in the steering wheel. On-Demand Radio stations will continuously broadcast stories pertaining to each topic.

Typically, in the radio, a set amount of memory is allocated for each topic. Stories broadcast more recently will replace stories from the past, as in a FIFO. 1. Program Cycle

The radio will play each topic according to a pre-established play sequence (the "playback cycle"). When the last topic has been played, the playback cycle begins with the first topic and plays any NEW material that has just come from the broadcast. The radio cycles through this loop until there are no more new materials. In one embodiment, stories that have already been played remain in memory and remain available for future replay.

The listener is able to add or remove topics from the play list by going to the On- Demand Radio Internet web site or by using the Quick Access buttons in the manner more fully described later in this specification.

In one embodiment, at the beginning of each topic, the radio makes a brief announcement of the topic name and story highlights (summaries). After announcing the summaries, each story is played sequentially, unless the listener decides to manually interrupt the automatic sequence, The following table is a visual representation of one embodiment of a default play sequence

Traffic Update Custom Commute Route 1 Custom Commute Route 2 Highway #1 northbound Highway #1 southbound Highway #2 northbound Highway #2 southbound

Stocks

Custom stock 1 Custom stock 2

Top Stories Summaries Story 1 Story 2 Story 3

General News Summaries Story 1 Story 2 Story 3

Sports News Summaries Story 1 Story 2 Story 3

Sports scores

Sport 1, team 1 game summary Sport 1, team 2 game summary Sport 2, team 1 game summary Sport 2, team 2 game summary

Entertainment News

Summaries

Story 1

Story 2

Advertisements Store type 1 Store 1 Store 2 Store type 2 Store 1 Store 2

Repeat from beginning 2. Traffic

Traffic update is an important feature of On-Demand Radio. As metropolitan areas get more congested, traffic reports will prove to be one of the most useful features to the driver.

Many highways now have speed sensors. On the On-Demand Radio web site, a listener can identify the specific sensors on the routes that he takes daily. Once customized, the individualized congestion report will delivered to the radio. In one embodiment, if there is no congestion for a user-specified route, the ODR unit reports that there is no congestion on the specified route. In an alternative embodiment, the ODR unit does not report anything about a route unless there is congestion.

In one embodiment, traffic updates are not automatically discarded when the listener has heard them. The reason is that the listener may need a reminder that a particular route is congested, even though the listener has already heard the announcement. In each listening session, the traffic updates that the listener has not yet heard are played in the order of the most recently received. The ones that he has already heard are then played also in the order of the most recently received. Traffic conditions change quickly, so On-Demand Radio has the capability to individually discard old updates by control of the broadcast. Even updates that the listener has not heard can be discarded by control of the broadcast, if the traffic conditions no longer apply.

In one embodiment, there are two types of traffic updates. One is called incident update, which includes accidents or road construction. As an example, there are typically 5 to 30 incidents on a particular day. On-Demand Radio reports all of these. The second type is the highway speed sensor. There are hundreds of such sensors installed by the state highway agencies. They measure the traffic speed at a particular junction. A red status is generally speed below 20 miles per hour. In one embodiment, On-Demand Radio only reports red sensors. If a number of consecutive sensors are in red condition, the radio reports them together as a block. For example, if the sensors on southbound Highway 101 from 1^st Street to 13^th Street are all red, the On-Demand Radio reports it as "2:10 PM Southbound Highway 101 slow traffic below 20 MPH from 1^st Street to 13^th Street".

The traffic update can be reported with spoken voice or text-to-speech synthesis. In one embodiment, there is not more than a five minute delay for traffic updates. In the preferred embodiment, the information will be sent as text at regular intervals, for example, every 5 minutes. The audio freeway names or numbers are sent periodically, for example, once a day, such that the ODR stores the selected audio signal in memory. During the traffic playback, the audio signal will be retrieved according to the text version of the freeway symbol. In the same manner, the traffic condition can also be announced by looking up prerecorded conditions according to the received conditions in text. The following is an example of the content of a traffic update.

Time stamp

Location of congestion or incident

Direction of traffic (north or south bound)

Nature of incident

Alternative route

Typically, the detailed level traffic report is time sensitive. In one embodiment, slight traffic slow-downs that normally are not reported in rush hour traffic are reported in late night traffic reports.

3. Stocks

In one embodiment, the radio first. announces the time stamp of the last trade. In one embodiment, the Symbols update will cycle in alphabetical order. In another embodiment, the sequence of the stocks reported is determined by the user either through the web site or on the unit. In a typical embodiment, the information included for each stock symbol is as follows:

Time of report

Symbol

Current price

Daily high

Daily low

Volume

For each stock, the latest information received always replaces the previous data. The above information can be either spoken voice or text-to-speech. In the preferred embodiment, the information will be sent as text at regular intervals, for example, every 15 minutes. The audio stock symbols are sent periodically, for example, once a day, such that the ODR unit stores the audio signals for the selected symbols in memory. During the stock playback, the audio signal will be retrieved according to the text version of the stock symbol. In the same manner, the price can also be announced by looking up prerecorded numbers according to the received price in text. The time delay in which stock or other information (such as, e.g., traffic information) is delivered is dependent upon the delay with which the data is received from the data source, and is further dependent upon additional time for processing and transmission. In one embodiment, the delay in delivering stock information is approximately 25 minutes which includes a 15-minute delay in receiving the data from the data source and a 10 minute delay in processing and transmission of the data.

The Stock update is a listener-customized feature. In one embodiment, prior to customization via the web site, the major indexes and the stocks in the Dow Jones Industrial Index are played. '

4. News Stories News stories are stored in the radio's memory. In one embodiment, the news stories are stored in a first-in-first-out order. In another embodiment, the news stories are stored in an order that reflects the listener's profile of preferences. The radio is constantly receiving additional stories while discarding the oldest ones. Each story is marked according to its order of importance. When there is insufficient memory to retain all the stories from the past 24 hours, less important stories are discarded first. Any stories heard by a listener are discarded at the end of the session. In one embodiment, during the listening session, all the news stories a listener has heard are still retained in memory. When he wants to go back to listen to them again during the same session, he can. At the end of each session, all the news stories that he has heard are discarded to make room for more stories from the broadcast. a. Top Stories These are the front page news of the day, important events of which everyone would want to be made aware. Stories can come from any topic. In one embodiment, once the story is played under the Top Stories section, it will not be repeated in another category. Conversely, if a listener has already heard a top story in another news category, it will not be repeated in the Top Stories topic. For example, if a really important business story is reported in the Business News section, it will not be repeated in the Top Stories section. It is the station editor's job to constantly maintain the latest top stories for an exciting Top Stories category. 5. Sports Scores In one embodiment, for each team, the latest information received always replaces the previous data. There is a short summary of the game with the scores. There is no more than a ten minute delay for score data. The radio announces a date and time stamp for all updates.

Sports team score update is a listener-customized feature. Before customization, via the web site, the professional teams of popular sports are broadcast and received. In the preferred embodiment, due to the large number of scores of different types of sports, the information transmission and retrieval is also performed in a manner similar to the manner described for traffic and stock. Names of teams and scores will be transmitted in text and the appropriate audio signal will be looked up and retrieved for audio output.

6. Commercials In one embodiment, commercials are played on a periodic basis, for example, every eight minutes. Once the listener have been listening for eight minutes to any topic, two minute's worth of commercials come on at a convenient point between stories. In one embodiment, a quick highlight of upcoming stories is made prior to each set of commercials.

In one embodiment, at the end of a commercial, there is an audible announcement that related stories exist for the subject matter of the just-completed commercial. The user accesses the related commercial stories by responding to the audible prompt for related stories. The user's response to the prompt can be in one of, but not limited to, the following: an audible response in an embodiment that is speech-recognition-equipped; pushing a particular button on the ODR unit, for instance, the BACK button. 7. Automatic Start Feature

When On-Demand Radio is part of an AM/FM radio, it can be programmed to begin playing whenever the unit is turned on, event if the radio is in the AM or FM band. This can be when a driver starts the car, or when a listener turns on the listener's Walkman stereo. In one embodiment, this is the default mode unless the listener uses the Internet web site to disable this feature.

8. Automatic Resume Feature

In one embodiment, after listening to On-Demand Radio, if a listener jumps to AM or FM radio, and then jumps back within a set amount of time, e.g., within 30 minutes, On- Demand Radio will resume playing at the next story in sequence from where he has left off. If the listener turns off the radio, and then turns it back on, On-Demand Radio will begin playing from the beginning of the play sequence.

9. User Accessible Hardware a. Faceplate Buttons

On some On-Demand Radios, there may be a separated button labeled, e.g., NEWS, or ODR. When a listener presses this button, the radio goes into On-Demand Radio mode. The radio immediately begins to play stories in the first topic in the play sequence. In a typical default line-up, the first topic is the Traffic Update, but can be programmed to be any topic via the Internet web site.

The AM/FM band selection button can have an additional choice: e.g., NEWS, or ODR. FIG. 19a is a graphical representation of one embodiment of an On-Demand Radio unit apparatus. In the embodiment depicted in FIG. 19a, the band selection button (1 120) has three selection positions: AM (1121)/FM (1123/NEWS-ODR (1 122). When NEWS-ODR is selected, the radio immediately begins to play stories in the first topic in the play sequence and will continue to play stories, in accordance with the user's predefined or with the default play sequence unless interrupted by the user. The user can interrupt the play sequence by, for instance, pressing one or more of the navigational ODR faceplate buttons.

In one embodiment, the ODR radio unit offers a multi-selection button that allows the user to select one of several pre-set default profiles which will control the Play List and memory button (which in an ODR unit, under the NEWS or ODR band selection, become what are referred to in this application as Quick Access Buttons) definitions for that user. For example, the button could allow the user to select the Business person profile, a student profile, sports fan profile, etc. These profile selections are exemplary and are not meant to be a limitation of the invention. If the user selects, for instance, the Business person profile, then the Play List and Quick Access Buttons will play information in the following example sequence: Stock, General News with emphasis on Business News, Top Stories, Traffic, Sports News, and Entertainment News.

In most current radios, there are six buttons (1150-1155) used for programming radio stations. Once the radio is in the NEWS-ODR mode, these buttons can be used as Quick Access Buttons to quickly access specific news topics. The following table shows the allocation of the Quick Access Buttons.

Pushing a Quick Access Button plays the specified topic immediate. As default, the radio stores data for the five topics assigned to the Quick Access Buttons. Quick Access Button 6 is referred to in this specification as the Content Pool, and is used to select additional topics. The first push of Button 6 plays the 6^th topic. Subsequent pushes play the next topic in the play sequence, and so on. Pushing Button 6 when the last topic is playing causes the ODR unit to begin playing the topics under Button 6 beginning with the first topic under Button 6.

The Quick Access Buttons are used to interrupt the automatic order of the On-Demand Radio play sequence. When a listener pushes a Quick Access Button, the topic with that Button is played. When all of the stories of the topic have been played, the next topic begins automatically. In one embodiment, if a Quick Access Button does not contain a topic, and if the Button has been pressed, the radio announces "Topic not available".

1.) Modifying the Contextual Relationship of the Programmable Quick-Access Faceplate Buttons

In the typical embodiment, all of the Quick Access shortcut buttons are preprogrammed to specific topics. In the typical embodiment, the listener can change the definition of the button by pressing and holding a particular Quick- Access button for a fixed amount of time. In this way, the button will be programmed to a new topic. This function is similar to that of a memory button on a normal car radio.

When the radio is playing a particular topic of interest to the listener, the listener can press and hold any of the Quick Access buttons to save the current topic into that button's memory. Once the button has been pressed and held, the system stops playing the current story briefly, and plays a beep or some other short sound. The system then returns to where it left off in the original story. The topic previously held in the memory location is overwritten by the topic currently playing. The short sounds can be transmitted by the Broadcast System and received by the ODR unit and stored in memory. This gives the Broadcast System the ability to control this aspect of the ODR unit function remotely. In one embodiment, the amount of time required for the typical embodiment of the system to register the press-and-hold as a request to over-write the memory is the same as the value for the Navigational Button hold-click.

In one embodiment, the order of topics in the Content Pool is alphabetic. In another embodiment, the order of topics in the Content Pool is user controlled either from the web site Customizer or by using the Quick Access Buttons or other navigational features of the ODR unit to arrange the topics. When a listener redefines the topic in a Quick Access button, the system immediate re-shuffles the play order of its topics to represent the new condition. As an example, Entertainment News has not been set to be one of the top 5 topics. While Entertainment News is playing, a listener programs the Quick Access Button 1 to be Entertainment News. After all stories in Entertainment News have been played, the system plays stories from Quick Access Button 2, then the topic from Quick Access Button 3, and so on. The topic previously in Quick Access Button 1 is now relegated to the heap of topics past topic 5. All topics past the first 5 are ordered alphabetically based on the topic name. In one embodiment, the topic previously accessed with Button 1 exchanges places with the Entertainment News topic.

As another example, General News is in Button 2 and Entertainment News is in Button 4. While listening to Entertainment News, if the listener pressed and held button 2. Button 2 would then be programmed with Entertainment News. Button 2's previous content, General News, would then be stored in Button 4.

In one embodiment, the default order of the first 6 topics to play upon the start of the Simulator program is defined by the order of the first 6 topics in Filter.dat. Topics past the first 6 are not governed by Filter.dat, and are arranged in alphabetical order by the topic name. b. Navigational Buttons

In one embodiment, there are two navigational buttons, each with two levels of functionality: single click and hold click. The single click is used for the most common functions such as Forward. The hold click is generally used for the same function, but with a bigger group, such as Skip Section. In one embodiment, there are four navigational buttons: two for skipping stories and repeating stories, two for skipping sections and playing previous sections.

In one embodiment, the first push of the BACK button (1180) always plays the current story from the beginning. Subsequent clicks cause the radio to back up and play one story at a time. In this regard, the BACK button is similar to the BACK function of an Internet browser; it replays the stories that the listener has already heard. The FORWARD button (1190) always skips to the next story.

In an alternative embodiment, the first push of the BACK button replays the last few seconds, e.g., the last five seconds, of the current story before continuing to play the remainder of the current story. The example of five seconds is exemplary and is not meant to be a limitation of the invention. Subsequent pushes of the BACK button in this embodiment operate as described above — the next push causing the current story to replay from the beginning; subsequent pushes causing replays of preceding stories, one story at a time.

In one embodiment, the first hold-click on the BACK button (Hold BACK) always repeat the current topic, starting with the first story. Subsequent clicks cause the radio to back up and play one topic at a time. The Hold FORWARD button always skips to the next topic.

In one embodiment, the only exception to the above is during a commercial. The Hold

BACK and Hold FORWARD buttons do nothing during commercials. The BACK button repeats the current commercial, and does not back up further. The FORWARD button plays the commercial support material (if it is pushed after the announcement indicating a commercial support material is available), but does not skip to the next commercial or story. Commercial Support Material is described later in this specification.

In an alternative embodiment, the FORWARD button skips the commercial. In one embodiment, skipping the commercial will result in playing another commercial. In yet another embodiment, pushing the FORWARD button will skip the commercial after a certain number of seconds, e.g., 2 seconds, of the commercial have been played. In yet another embodiment, pushing the FORWARD button will skip the commercial after a certain minimum number of seconds, e.g., 2 seconds, of the commercial have been played. In this embodiment, if the first required number of seconds of a commercial have been played when the user pushes the FORWARD button, the rest of the commercial is immediately skipped. 1.) Manual Control in Traffic Updates

If a listener has customized his routes using the web site, a Custom Traffic Route topic is played on the radio. The standard traffic update follows. If no custom routes have been defined, the radio plays the standard traffic reports only. Pushing the Forward button plays the next freeway. Pushing the Next Section button plays the next geographical region, such as South Bay or East Bay. 2.) Manual Control in Stock Updates Pushing the Forward button skips to the next stock. Pushing the Next Section button plays the next set of stock such as Technology Stocks, Heavy Industry Stocks, or related information regarding the stocks in the portfolio. Pushing the Back button repeats the current stock. Pushing the Previous Section button makes ODR go back to the previous section.

3.) Manual Control in News Updates Pushing the Forward button skips to the next story. Pushing the Next Section button plays the next set of stories such as National News or Local News . Pushing the Back button repeats the current stock. Pushing the Previous Section button makes ODR go back to the previous section.

4.) Manual Control in Sports Scores Pushing the Forward button skips to the next team. Pushing the Next Section button plays the next league or sport, such as NFL, NBA, or related information regarding the teams in the listeners list. Pushing the Back button repeats the current stock. Pushing the Previous Section button makes ODR go back to the previous section.

5.) Manual Control in Commercials In one embodiment, the navigational buttons work different during the_playing of commercials. The Forward and Next Section buttons are not functional inside of commercials. Therefore, a listener cannot skip a commercial. The commercials automatically play one after another.

Some commercials have commercial support materials. These can be such things as addresses of stores or product specifications. At the end of a commercial that has commercial support material, an audible tone or verbal announcement or other signal is played to let the listener know that commercial support material is available. The radio plays the next commercial or story in the playback sequence while a designated period of time is counted, for instance, 5 seconds. If the listener pushes the BACK button before the designated period of time expires, the commercial support material plays. If the listener doesn't press the BACK button within the designated period of time, the radio stops counting, forgets about the commercial support material, and continues to play the next commercial or story. If the listener pushes the BACK button before the designated period of time expires, the button functions as follows: it repeats the current commercial. A second push on the BACK button repeats the previous commercial. When commercial support material is playing, the 1st BACK button push repeats the commercial support material. The 2nd BACK button push plays the commercial leading to the current commercial support material. If the listener pushes the FORWARD button, the radio plays the next commercial or story. At the end of the commercial support material, if the listener does nothing, the next commercial or the next story begins playing automatically.

Typically, the BACK button functions like it does in all other topics: the first push repeats the current story, commercial, or commercial support material. The second and subsequent pushes play the previous story, commercial or commercial support material.

The asterisk in the five second period indicates that if the listener pushes the BACK button within the five second period while a new commercial is playing, the firmware can consider the new commercial to never has been played. This means the new commercial is not put on the queue used to keep track of the stories that have been played. 6.) Manual Control in Radio Shows

In one embodiment, pushing the FORWARD button once advances the currently- playing pre-recorded radio show 10 seconds. A second push of the FORWARD button advances the show another 10 seconds. Similarly, pushing the BACK button once backs up the currently-playing pre-recorded radio show by 10 seconds. A second push of the BACK button backs up the radio show by another 10 seconds. Pushing the NEXT SECTION button plays the next pre-recorded radio show. Pushing the PREVIOUS SECTION button plays the previous pre-recorded radio show.

10. Play Sequence a. Automatic Play Sequence On-Demand Radio is set to automatically play in a way that minimizes user button pushing. The automatic play sequence is listed in the Program Cycle section. b. Sections

With the use of "sections", the invention provides the listener faster access to specific areas of a topic. For example, under the topic Traffic, in the San Francisco Bay Area, there are several regions: North Bay, East Bay, Peninsula, and South Bay. Each region is assigned a section. Within each of these sections, there are stories about the traffic conditions on freeways. A listener is able to navigate from story to story, as well as from section to section. In this case, a listener can skip to a section such as South Bay by pushing the Skip Section button 3 times. Within a section, the listener can skip from freeway to freeway using the Skip Story button. c. Consolidation of Topics

In one embodiment, in order to make it easier for the listener to remember how to navigate through the information, several topics are consolidated into one. For example, all news topics such as top news, business news, local news, sports news, world news, and U.S. news are all grouped under the topic news, and assigned one Quick Access button. Similarly, all magazine-type contents such as Travel, Health & Living, Science, and Technology are all grouped under Magazines, and assigned one Quick Access button. Mapping it this way allows each of the six Quick Access buttons to represent a type of content. With the new grouping, the six Quick Access buttons may look like this:

In one embodiment, there are no navigational buttons used to go from topic to topics.

The listener presses the specific Quick Access button to get to that topic. In one embodiment, a NEXT TOPIC button (1220) and a REPEAT TOPIC button (1230) are provided. Pressing the NEXT TOPIC button (1220) causes the ODR unit to begin playing the next logical topic in the play list sequence. Pressing the REPEAT TOPIC button (1230) causes the ODR unit to begin playing the immediately preceding topic in the play list. d. Another embodiment of Buttons in ODR (On Demand Radio) Mode The following table summarizes the available buttons and the associated functions for one embodiment of the invention.

e. Content Pool Button

The function of the Content Pool, typically button #6 (1 155), is slightly different from the way that the other buttons function, but is designed to be equally intuitive. In a typical embodiment of the content pool button, the first push of Quick Access button #6 (1155) reaches the first topic in the Content Pool. For example, consider that there are two topics in the Content Pool: Spanish Broadcast, and Chinese Broadcast. The first push of button #6 reaches Spanish Broadcast. Pressing the button one more time reaches Chinese News. Within each of these topics, a listener can use the Skip Story and Skip Section to navigate. If the listener finds a section interest, the listener can then push and hold button #6 to program it. Let's say he likes Chinese News Taiwan section. Pressing and holding down button #6 while listening to Chinese News Taiwan Section makes Chinese News the first topic in the Content Pool, and Taiwan section the first section in Chinese News. f. LCD Display

The LCD (1140) displays the current section name as well as the button number where this section is found. This makes it easier for one to know which button is currently playing in case he wants to program the Quick Access buttons. g. Length of Stories

All stories are broadcast in summary-only or summary plus full-story. The summary is essentially the first paragraph of the full-story. When summary plus full-story is available, depending on the user-given Interest Level, ODR either chooses the summary or the full-story. This allows a listener who is not very interested in the topic to get a summary of the story, and for an avid listener to get the full story. If no user profile was given on the Web, the Intrinsic Value of those stories is used to determine the version to keep. h. Support Stories

After a main story is played, ODR prompts the listener if he wants additional stories. If he chooses to play the support stories, ODR allows navigation just like a normal story. i. Commercials

Commercials can be skipped. The user's Control Setup Specifications and other information known to the Broadcast System and/or to the ODR unit is used to determine whether or not commercials and/or particular commercials will be delivered to, received by, and/or played by the ODR unit. The Repeat Story functions can be used to repeat commercials. The Save function can be used to save commercials for 24 hours, j. Save Function

By pressing and holding the Repeat Story button, the currently playing story can be saved for 24 hours. For the 24-hour period that a story is being saved, it is the first story of the section to be played. If more than one story of the section has been saved, the one saved earlier is played first.

Similarly, a commercial can be saved. For the 24-hour period that a commercial is being saved, it is the first thing to be played after turning on the radio or entering ODR mode. k. Pause

When ODR is playing, it can be paused by either turning the radio off or tuning to AM or FM bands. When returning to ODR, either by turning on the radio or switching back to the ODR band, if the time since the last ODR access is less than 30 minutes, then

ODR will resume where it was left off. If the time has been greater than 30 minutes, ODR will restart from the first topic. Of course, the stories that have already been played are moved to the bottom of each section.

11. Multiple Profiles

Several listeners can define their profiles on the web and all are stored in the radio.

Pushing and holding down the AM/FM/News sequences through all the profile numbers. Releasing the AM/FM/News button selects the profile number. The profile contains a combination of setting from the web and those made on the radio. Those ODR functions included in a profile are ODR Interest Levels, section ordering, Quick Access button setting, saved stories or commercials, etc. Those radio functions included in the profiles are memory button settings, Intelligent Scan and Intelligent Memory Buttons.

12. AM/FM Functions

When the AM/FM/News-ODR button 1120) is set in the AM (1 121) or FM (1 123) modes, the ODR unit operates in the same manner as a non-ODR radio. In all modes, AM/FM/News-ODR, the on/off/volume button (1110) and other buttons on a typical radio unit continue to operate in the manner in which such buttons are expected to operate in non-ODR radios.

13. Clock

In a typical embodiment, the Broadcast System will broadcast local time regularly. A radio equipped with ODR will set the time correctly without manual intervention for initial setup and daylight saving time. Furthermore, a user who travels from one time zone to another does not have to manually change the clock time In a typical embodiment, time is displayed in the LCD Display (1140).

14. LCD Display In a typical embodiment, the Broadcast System will broadcast station call letters, music format, and/or other related information. A radio equipped with ODR will display the station call letters for each AM or FM station, music format, and/or other related information.

15. Station Scan and Seek Buttons In radios without ODR, the Scan button scans the frequencies in sequential order looking for clear radio stations. With ODR, the radio receives a database of radio stations and their music or news format. In a radio with ODR, each time a listener pushes the Scan button (1200), all the stations with a format similar to the currently playing station are scanned first, followed by the rest of the stations. This allows the listener to jump to another station with a similar format if the current station plays a commercial.

Similarly, in a radio with ODR, each time a listener pushes the Seek button (1210), all the stations with a format similar to the currently playing station are located first, followed by the rest of the stations. This allows the listener to jump to another station with a similar format if the current station plays a commercial. 16. Memory Buttons In radios without ODR, each memory button is programmed to one station. In radios with ODR, because of the availability of the station format database, the radio knows the format of the station in each memory button. Additional stations with a similar format are accessible by push the memory button a second or more times. Each push of a memory button cycles through a pool of stations with similar formats. Pressing and holding down the button programs the memory buttons the same way as before.

G. On-Demand Delivery

In accordance with the present invention, when the listener requests information stored in the memory of the listener's individual radio unit, the specified information is retrieved, converted into audible information through the use of a speech synthesizer, and delivered through the radio's auditory speaker mechanism for the listener's individual reception ("On- Demand Delivery"). In one embodiment of the invention, the user requests On-Demand Radio programming by depressing a faceplate button on the radio, for instance, a band selection button that includes the options AM, FM, ODR (or like selections). Once the user has selected ODR, the ODR unit then plays the entire ODR program customized according to the user's prior specifications, as identified by, for instance, the user's choices using the web-based Customizer described above. In this automatic program playing mode, no intervention by the user is required in order for the user to listen to the entire customized ODR programming. If the user chooses to interrupt the ODR programming, the user can use one of other faceplate keys, for instance the typical 6 Quick Access Buttons, described more fully above, to change the order in which the ODR programming is played. Furthermore, as is described above, subsequent pushes of the same Quick Access Button allow the user to interrupt programming played under the topic controlled by that particular Quick Access

Button and skip one or more, depending on the number of pushes, subtopics within that topic.

In one embodiment, one or more different "Coming up" phrases are played prior to a commercial in order to give the listener an idea of the stories that are to be played. The Broadcast data records for several "Coming Up" phrases are read into a circular queue in the memory. Starting from the beginning of the queue, the system plays a different phrase each time a "coming up..." phrase is needed. The system typically plays at least one "Coming Up" phrase for each commercial break. If the entries in the list are exhausted, the system again circles through the queue. In one embodiment, commercial subject matter is consistent with the topic and/or subtopic subject matter under which the commercial is played. For example, commercials for a stock trading firm are played in the financial news section. In one embodiment, all summaries for a particular topic are played at the beginning of a topic, prior to playing the stories. This change allows finer control of the number of summaries to play. The number of summaries to play is configurable.

In one embodiment, one summary is played prior to a commercial break. In another embodiment, the number of summaries to play prior to a commercial configurable by the listener in the Customizer.

In one embodiment, there is no audible separation between the summary and the story sections. In another embodiment, the system plays a sound file that announces the upcoming subtopic. The announcement sound file is downloaded through the Broadcast System. Each topic has its own Story Separator sound file, although multiple topics can share one sound file.

If there are no summaries, this phrase is not played. In one embodiment, the system will not allow a commercial break to cut in between this sound file and the first story.

In one embodiment, the system plays a sound file prior to playing stories in a particular Subtopic, thereby grouping all the stories in that Subtopic together. This is done because it is desirable to group like stories together, and one way to do this in ODR is through the use of Subtopics. For example, sports teams are grouped by their sport in a Subtopic, and then by the team's name in Subtopic2. In this embodiment, subtopic separator sound files are inserted into the Play List just prior to the stories in the matching Topic and Subtopic. If there are no matching stories, then a sound file is not played for the Subtopic phrase.

In one embodiment, when the system has finished playing all the stories, it displays a message on the screen and stops. In another embodiment, the system then plays a sound file that gives an audible indicator for the listener that all the stories have been played. The following is an example of a Broadcast data file record for the Program End Phrase. The sound file is downloaded from the broadcast.

In one embodiment, after playing the sound file indicating the end of the ODR session, the ODR system puts the radio in the Off state.

The order in which stories are played is determined by the calculated Composite

Value, which is equal to the product of the Interest Level in this subtopic (in Filter.dat) and the Intrinsic Value of the story (in Broadcast data). Intrinsic value is a number, typically within a given range of numbers, that is assigned to the story, for instance, by the editor at NOC. In one embodiment, when stories have the same Composite Value, they are played in the order in which they appear in Broadcast data.

However, many situations warrant the finer ordering of stories. Stock quotes, traffic, and sports scores are examples where the sequence of play is very important. In one embodiment, the system plays stories in the order in which their corresponding Subtopic or Subtopic2 appears in Filter.dat. The stories are first sorted by the order of the Subtopics, and then by the order of the Subtopic2's. When a story has multiple Subtopics, the Simulator determines the play sequence according to the position of the earliest matching Subtopic in Filter.dat. When a story has multiple Subtopic2's, the Simulator determines the play sequence according to the position of the earliest matching Subtopic2 in Filter.dat. 1. Mode Button In one embodiment, there is no easy way to expand the content of a story, or to listen to only the summaries, or only the full story. In another embodiment, a Mode button ( FIG. 19a, (1100)) is provided that switches from summaries to full story and vice versa.

The radio no longer plays the summaries first, followed by the full stories. Instead, there are two modes: Summary mode and Full-Story mode. In Summary mode, only the summaries are played, one following another. In the Full-Story mode, only the full stories are played, one following another.

While in Summary mode, if the listener pushes the Mode button, the radio interrupts what's currently playing, plays a phrase that indicates the mode that the radio is going into, something like "Full-Story Mode", and immediately plays the associated full story. The radio remains in Full-Story mode until the Mode button is pressed again. While in the Summary mode, if a commercial or phrase is playing and the listener pushes the Mode button, the radio interrupts whatever it was playing, plays the "Full- Story Mode" phrase, and then returns to where it left off. It plays full news stories only at the next story.

All story records in Broadcast data contain file pointers to SummaryFile and VoiceFile. For stories whose summary and full stories are the same (such as stocks or traffic), the same file name appears twice, once in SummaryFile and again in VoiceFile. WhileinFull-

Story mode, if the listener pushes the Mode button, the radio interrupts what^'s currently playing, plays a phrase that indicates the mode that the radio is going into, something like "Summary Mode", and immediately plays the summary of the next story. The radio will remain in Summary mode until the Mode button is pressed again. While in the Full- Story mode, if a commercial or phrase is playing and the listener pushes the Mode button, the radio interrupts whatever it was playing, plays the "Summary Mode" phrase, and then returns to where it left off. It goes into summary news stories only when it plays the next story.

In one embodiment, each time the ODR unit is turned on, the ODR unit is automatically in Summary mode. Furthermore, the state of the Mode button is preserved across the Band-Select, memory, and navigation button presses.

A listener would generally know what mode the listener is in at any time by the length of the stories. In Summary mode, news summaries are about 20 seconds. In Full-Story mode, news stories are about two minutes. In one embodiment, a small LED light indicates the mode in which the ODR unit is currently operating. 2. Related Stories

In one implementation, the system has a feature called CSM (Commercial Support Material), which provides additional material for a listener about a particular commercial. In another embodiment, the system provides a similar function for news stories.

In the Full-Story mode, after a story has been completely played, the announcer says, "To hear two more related stories, press the Mode button." Just as in the CSM, while the next story is playing, the listener has a fixed amount of time to press the Mode button. If the listener presses the Mode button within the allocated time, the radio aborts the next story, and starts to play the related stories. All related stories are playing in their entirety, and not just the summaries. The listener can use the normal navigational keys to repeat the story (or topic) or skip to the next story (or topic). At the end of playing all the related stories, the radio goes back to the Full-Story mode and plays the next regular story. FIG. 20 is a state transition diagram of one embodiment of an On-Demand Radio unit play back system. In FIG. 20, a Topic, e.g., News, is announced (800). Automatically, or by pressing the FORWARD button (802), the playback system proceeds to announce the first subtopic (804), e.g., "World News," under the Topic. After announcing the first subtopic, the ODR system will automatically, or if the user presses the FORWARD button (806) will, proceed to deliver the first story (808) under the first subtopic under Topic. At any point after the ODR system begins to announce the first subtopic and before the ODR system begins to announce the second subtopic, if the user presses the NEXT button, then the ODR system will proceed to announce the next subtopic. Automatically upon completing the first story, or by pressing the FORWARD button before the first story has been completely delivered (810), the playback system proceeds to deliver the second story (under the first subtopic under Topic). Once the second story has been completed, the playback system automatically (814) announces that there is additional information concerning the immediately preceding story (816). If the user responds affirmatively (820), the additional information story is delivered (822). Otherwise, the playback system automatically (818) begins to deliver the next Story under the first subtopic under Topic. If the user has affirmatively requested the additional information, the playback system will continue to proceed, automatically or by pressing the FORWARD button (824) to deliver all other additional information stories, e.g.. (826), before automatically, or by pressing the FORWARD button (828) to return to deliver the next Story under the first subtopic under Topic.

In one embodiment, the button to activate the CSM is the Back button. In another embodiment, the CSM button (for commercials) is changed from the Back button to the Mode button. In Broadcast data, a regular story containing related stories is designated with a special marker which acts as a pointer to the CSM stories. In another embodiment, CSM stories have special markers that point back to the master story. In yet another embodiment, some regular stories have special markers linking the story to other regular stories.

Related stories are considered a part of the associated regular story. Therefore, when a regular story with Related Stories is discarded, all of its Related Stories are discards as well, regardless of whether they have been heard or not.

If a newly arriving story makes the total number of stories in a topic greater than the maximum number allowed, then either an existing story is discarded, or the new story is not saved. The decision is based on each story's Composite Value: stories with higher Composite Value are retained. All Already-Played stories have lower Composite Value than any

Unplayed story.

3. Custom Traffic Reports

In one embodiment, the ODR unit performs the following operations when it receives a Traffic record in Broadcast data: a Checks records in Filter.dat to see if the congestion falls inside of any of the custom routes, b. For all congestion that fall within a specific custom route, first sort them in the order in which the Highways appear within the record in Filter.dat. The second and third order of sorting is Direction and Mile. respectively, again based on the order of appearance of this data within the record in Filter.dat.

In one embodiment, the ODR unit assembles the data for all of the custom routes throughout the day. However, the ODR unit only plays custom route data when the appropriate day and time is matched. Time is matched if the current time falls within

FromTime and ToTime in Filter.dat. Note that FromTime and ToTime can wrap around the o 24 hours clock. Day is matched if today is found in the day string provide by Filter.dat.

In one embodiment, in the context of traffic, the Discard operation is used to remove records for congestions that have eased. Therefore, when the ODR unit receives a discard command, it removes all instances of the appropriate record from memory. All traffic records in Broadcast data will have the Keep field as Yes, so automatic discard does not apply. This 5 means that all records are retained in memory until the discard command explicitly removes them.

4. Non-Custom Route Traffic Reports In a typical embodiment, after the ODR unit has played custom route reports, the ODR unit plays all non-custom route data. This allows a listener who has noLeustomized 0 the listener's traffic reporting options to use ODR to find out traffic data on any major highway.

The records are sorted in the following order before they are played:

5 1 Region Sort first by region. The sort sequence is defined in the order of appearance of the regions in Filter.dat.

If this field is absent in all Broadcast.dat records, then ignore this field during sort.

2 Highway Next, sort by the order in which highway names appear in the 0 SortOrder field in Filter.dat. If a highway is not present in the

SortOrder field, then put it at the end of the sequence.

3 Direction Within each highway, play northbound and westbound traffic first, then southbound and eastbound.

5 Mile Finally, for records indicating northbound and westbound direction of travel, sort by Mile field in ascending order (0, 1,2,3, etc). For southbound and eastbound direction of travel, sort by Mile field in descending order (3,2,1,0, etc). This structure assumes that northbound and westbound mile numbers go higher the further one travels, and the reverse for southbound and eastbound.

5. Alerts

Alerts are information that are played immediately when received, regardless of the mode in which the ODR unit is playing. That is, Alert delivery will interrupt regular AM listening, FM listening and/or ODR/News listening. There are several types of Alerts, including but not limited to: Weather, Emergency,

Traffic, Sports, and Stock. This list of Alert types is exemplary and is not in any way a limitation of the invention. a. Customized Alerts

Some types of Alerts will only cause an interruption of programming if the user has predefined the particular type of Alert to cause such an immediate interruption. Such customized Alerts may also require additional pre-definition information to activate the Alert and allow the Alert to interrupt programming. For instance, the user can define one or more Stock Alerts. The user will be provided with the opportunity to define the basis for the Alert. That is, the user will be provided the opportunity to identify a particular level of change for a particular stock (high price level, low price level, price change) or for a particular index, e.g., if the DOW Jones index drops more than, e.g., 50 points.

Similarly, the user can define one or more Sports Alerts. In the case of Sports Alerts, the user will be provided with the opportunity to define the type of Alert that the user is interested in receiving. For instance, the Sports Alert can be targeted to a particular game and particular aspects within that game. As an example, the user can request Alerts when the score of a particular football game changes and at the end of each quarter. A Sports Alert can be targeted to a particular team and events for that particular team. As an example, the user can request Alerts whenever a particular team is about to begin a game, whenever the score changes for any game in which that team plays. A Sports Alert can be targeted to a particular player. For example, the user can identify that the user wants to know every time a particular football player makes a score. The user can define a customized traffic Alert. If the user has defined a customized traffic Alert, then the Alert function will provide the user with traffic alerts that effect the route identified by the user.

The above-described examples of Alerts are exemplary and are not a limitation of the invention. b. Standard Alerts

Weather Alerts and other types of Emergency Alerts will interrupt all types of programming regardless of user-defined interests. For instance, the approach of a hurricane, tornado, or severe thunderstorm would be announced to interrupt any type of programming.

Similarly, a high-speed chase on any traffic route in the area would cause an interruption of all types of programming.

H. On-Demand Content

According to the present invention, many different types of information can be made available from which the listener/user can select ("On-Demand Content"). There are many possible sources from which On-Demand Content can be collected and there are multiple strategies by which On-Demand Content can be prepared for broadcast to the listener/user.

Illustrative Embodiments

The embodiments of the invention described herein are only considered to be preferred and/or illustrative of the inventive concept; the scope of the invention is not to be restricted to such embodiments. Various and numerous other arrangements may be devised by one skilled in the art without departing from the spirit and scope of this invention. For example, alternative topics and categories of information are possible.

ON-DEMAND NEWS RADIO

I. State of the Art

Currently, radio, be it AM or FM, is used mainly for the broadcast of music or news.

People usually listen to music for entertainment, relaxation or as background music. Once a listener has chosen a music station (mostly for its genre of music), he will be content to listen to whatever the station feeds him.

News listening, however, can be more purposeful. People usually listen to a news station while they are commuting to work. If they are driving, they may want to know about traffic conditions the minute they start the car. A businessman may want his fill of business news before he arrives at work. Some may prefer more international and national news while others may prefer more local news. A sports fan may be impatient in getting to scores of games that are in progress or are already over.

A typical news radio station will "loop around" every 20 minutes, within which there may be about 40 individual "stories". During the next loop, some stories may be repeated while some may be replaced by new ones. Since radio is a broadcast technology, the news station editorial staff will pick stories which will be lowest common denominator of interests of the station's perceived listeners. As such, the story topics will not fit the needs of each individual listener. Even for a story that matches the need of the listener, the little amount of time that can be devoted to it will make it's content sorely lacking in depth.

We may want to examine the other news delivery mechanisms to see how the same problems may be present and may or may not be solved. TV news, other than the inclusion of video clips, is in fact very similar to radio news. It suffers the same deficiency as radio delivery. In fact, because a video clip will need a certain amount to convey and sink in, less number of stories can be fitted into a half hour slot. TV news is more like entertainment. It is unsatisfactory for a viewer in an inquisitive mode of news gathering. Newspaper, because of the low cost of news print paper, can cover a lot more stories, each in much more details. It satisfies most readers' needs. Still, there is not an infinite amount of paper available. Newspapers still need to specialize in some areas. For example, Wall Street Journal concentrates on business news (and analysis). Larger name brand papers like New York Times and Los Angeles Times may concentrate on international and national news while smaller local newspapers will concentrate on local news. Another handicap of newspaper is that they are published daily and will not be able to keep up with late-breaking news throughout the day.

The Internet potentially has many of the most desirable attributes for news delivery. All news stories can be made available at great details as they break throughout the day. The number of news per day is quite staggering (Reuters reportedly has about over 1000 per day). Screening through just the headlines will be time consuming . Fortunately, Internet being an electronic medium, a profile can be established by a reader to pre-filter the number of stories down to a manageable size, say 100 stories per day. The reader can then scan through the headlines to decide which ones to read. This is the approach taken by PointCast and other news delivery organizations on Internet. Internet news has just one minor handicap. It is accessible only in front of a computer (desktop, lap-top, Web-TV, etc.) and must be read by eyes.

Our invention here will combine the best attributes of Internet news delivery together with radio. The result is that a listener (typically a worker spending 1-2 hours commuting every day) will now have access to news stories that he wants, in greater details, and at times that he wants them.

The Invention

The Invention consists of a radio broadcast system together with radio receivers that will allow listeners to selectively listen to news stories of his choice in great details. 1. At the radio station, a data inserter will be installed. The data inserter is potentially a PC based machine. 2. Each inserter receives news stories in the form of data files either by modem download

(e.g. from a national center or from news services such as AP, Reuters, etc.), or by local input from the station staff. Each story will consist of a headline, a brief version of the story (optional), a detailed version of the story, certain keywords (e.g., sports, basketball, Lakers. Knicks) and other details such as version number (a story may evolve during the day and a second version may need to be sent) and time.

3. Stories are stored in memory of the inserter and queued for broadcast. The queuing is dynamic and may change. Important late breaking stories and time-urgent information such as traffic may be moved up the queue at the control of the news editor of the station.

4. Data may be broadcasted with existing technologies, such as FM SCA sub-carrier, RDS. Such technologies do not interfere with the station conducting its regular broadcast business. Currently, SCA and RDS are capable of about 600-2400 bits-per-second (bps) data rate, with higher data rates possible with some improvement. Alternatively, a full FM or AM station may be devoted to data broadcast, provided FCC approval is obtained.

5. Human voice conversation is conducted at around 180 words per minute. Assuming 5 characters per word (+1 for space), data rate is about 18 bytes/sec. = 144 bps. Thus, an

SCA channel broadcasting at a relatively low 600 bps is already about 4x real time data rate for a voice announcement on a radio station. Assuming a data compression of 3x for text, this will translate to 12x real time voice data rate.

6. At the receiver, the user has set up a user's profile to indicate the stories that he wants to receive. For example it may be: News - international, News - national, News - business,

Sports - baseball, Sports - basketball, Traffic - 110 Fwy, 405 Fwy. He may select the level of details for the news categories.

7. Each receiver is most likely part of a regular radio. If the user is not using the radio to receive any other station, then the radio will enter a "Sleep" in which the tuner will be tuned to the data broadcast station to receive data continuously throughout the day. Only news stories with the appropriate keywords will be selectively stored into memory. This way, all the news stories desired by the user will be in memory and ready to play when the user turns on his radio. 8. Playback will be by voice synthesis. Voice synthesis can be achieved either by software, using a powerful microprocessor chip, such as the Pentium, or it can be achieved by a special dedicated DSP chip in conjunction with ROM's.

9. The news stories will play back one by one. Each one will start with the headline. If the user finds no interest in the story, he can push a button to skip to the next story. Another method of playback may be to have a headline mode followed by a playback mode. During the headline mode, all the headlines are read back one by one first. The user indicates his interest in a story by pushing a button to select. After all the headlines have been read through, then the unit enters the playback mode in which the selected stories are now read out in details.

Instead of the above approach, an alternative approach is as follows:

1. News stories are stored as voice files in the inserter.

2. New stories are broadcasted in voice throughout the day. In this aspect, it is just like a regular radio station, i.e. a normal radio tuned to this station will have access to all the stories. 3. Each news story is preceded in broadcast by a short audio "blip". The "blip" may contain several bytes of information, indicating the category, sub-category, version number etc. for the news story. For example, a "blip" may indicate the following story to be about Sports-basketball-Lakers. Alternatively, such information may be sent by SCA subcarrier or RDS instead of an audible "blip". 4. Using the category and sub-category information, the receiver can choose to record the news story in memory, similar to a solid-state or tapeless answering machine. If voice compression technology is used, memory required can be reduced significantly to about 1.5 - 2 kbytes per second of audio.

5. Since voice is recorded in solid state memory, user has all the benefits of a solid-state playback, e.g. listen to a title and decide to skip forward to the next story.

6. The difference between this approach and the previous is that more memory and transmission bandwidth are required. Conversely, less number of stories or less details per story may be delivered. It is envisaged that the receiver in either approach will eventually be built into the car radio or the Walkman type of radio. In the beginning, a standalone unit may be built with the receiver, memory and voice synthesis circuitry, together with an audio-cassette tape player interface that will allow the unit to receive data separately and then be plugged into the audio- cassette player of a car to be played back.

The following "invention disclosure" is incorporated fully herein by reference.

Also incorporated fully herein by reference are the attached continuation invention disclosures entitled ON-DEMAND NEWS RADIO-PART 2 dated March 3, 1998 and ON-DEMAND NEWS RADIO-PART 3 dated March 26, 1998.

Invention Disclosure

Title of Invention: Downloading, storing, and retrieval of information and converting the information into audible information through the use of speech synthesizer, digital sound, or their combinations.

Abstract

A method and system for downloading data from a host computer, several host computers, a web sites or multiple web sites to a device with memory to hold said data such that with input from the user, the data will be retrieved and converted into audible information through the use of a speech synthesizer. The type of information to be download may be selected from a large database through the user preference file which the user can set up. The retrieval of information can be selected by the user through multiple levels of choices.

Background to the Invention

The use of internet become part of most people daily routine. Whether one looks for specific information, browse for general information, or look up the latest news, the trend is only getting upwards in terms of usage. Due to the limitation of the data transmission speed, there are several tools, e.g. PointCast, Freeloader, etc., which allow the users to download the needed information ahead of time. For example, the users can set the clock to download information during the middle of the night and retrieve them in the morning. The users are also allowed to set up preferences such that information downloaded are according to the specific interests of the individual user.

Under this scenario, the user usually retrieve the information and display them on the screen. Most of the time, the interesting sections are printed and read later. There are many occasion during the day that the user cannot read, instead, they listen. For example, when they are driving to work, they listen to the radio for the latest news or stock quotes. The radio station provide information in the sequence and format provide by the station. As a result, most of the information do not interest the listener. This invention discloses a method and system such that information according to the user preference will be downloading to the user, stored in the memory of the device, and convert the information into audible signals for the user. The user can select section of the stored information through multi-level selection through the use of a few keys.

Summary of the Invention

This invention discloses a data downloading, storing, retrieval, and voice synthesizer system for randomly access of the stored information and convert the selected information into audio signal using the voice synthesizer.

The system consists of a data source which are categorize into different areas of interest. This information is made available to the user through a information network in which the user can access at any time. Due to the vast amount of information available, the user would have to define a personal profile or preference such that only the preferred information is downloaded from the data source to the user. The downloading can be done by user request or by a timer for future download. At the user receiver device, it consists of a data process and storage system. The user profile is stored in this system and information will be used to download selected information. The information will be stored in the storage system for future retrieval. The retrieval system consists of an audio synthesizer and a user input keyboard. Majority of the information in the storage system will be outputted as audible sound including menus, data output, etc. As the user listens to the audible menu, input can be made to make the selection. The selected data will be outputted through the voice synthesizer to he heard by the user. Functions of the input device can consists of enter, backspace, next, again, etc. so that the user can browse the stored information audibly. The user can also choose the "radio" mode in which the data will be outputted in a predetermined sequence.

The following describes the preferred embodiment.

The Data Source

The data source resides in a website which can be browsed by the user. Information contained in the website consists of news, sport scores, financial results, weather, and other special interests. They are divided into categories in several level as needed. For example, sports news category can have subcategories of golf, tennis, football, etc.

Internet Access

The user accesses the data from the website by use of the internet. The terminal can be a desktop, portable computer. There will be an interface for transferring data from the computer to an audio cassette compatible "Preferred Radio" device. The user would carry with him this device to his car's cassette player for outputting the information. This preferred radio can also be integrated with a cellular phone such that it can be a stand alone device. The whole system can also be integrated into the car's sound system and cellular phone system.

User Preference

Initially, the user sets up the user profile by selecting the categories of information that he would like to download. Options will also be given whether the user want to download at that instant or sets up a timer to have the information downloaded at another time, e.g. 5:00 am every morning and 4:00 pm every afternoon.

The Preferred Radio

This device consists of a CPU programmed to interfaced with the user, a memory bank for storing and retrieval of the data, voice synthesizer for converting the data into voice, and a cassette interface for output the sound to the car's speaker through the magnetic heads. To minimize space, the data will be preferably stored in the compressed form.

The User Interface

This can be a small handheld remote control connected to the Preferred Radio, can be wired or remote. Since the user is driving when he is using this system, the remote control will be designed with simple functions and few keys so that the user can navigate back and forth through the store information. The dialog between the user and the system will be very similar to a normal computer terminal interface. Instead of displaying visual information for response, audible signal will be generated to prompt for input.

On-Demand News Radio - Part 2

Daniel S. Kwoh March 3, 1998

This document is a continuation of On-Demand News Radio, Jan. 17, 1998. Readers should refer to the above document for background. Since the issuance of the above document, there has been the following changes in thinking:

We realized that synthesized speech may not be a mature enough technology (in voice quality or low cost). In any event, users may not entertain listening to a synthesized voice for long. As such, it may only be useful in short segments like traffic, stock quotation, sports scoreboard etc., but not for long segments like news stories. The system may therefore be a hybrid system: news stories will be sent in real human voice, Le. voice of news stations announcers that listeners are familiar with; traffic, stocks, sports scoreboard will be sent as data and then speech synthesized.

L They System

1. News Story Broadcast:

News story broadcast may have the following scenario:

Phase 1 -

We get the partnership of a local AM news station. They broadcast news as usual. Typical news is about 0.5 to .S minutes long. We send in an Editor to the station. For every news story, the Editor assigns a category code, e.g. 504 for Sports - Baseball - Dodgers. During the broadcast of the story, the Editor generates and sends out the code. There are 3 separate problems here: the latency in code generation; the synchronization of code reception and news story capture; and the channel for code broadcast. We will address all the issues and possibilities here: a. Code broadcast channel - Most news stations are AM while data broadcast is only available in FM SCA sideband or RDS (as far as I know). One method for code broadcast is to link up the AM station by modem to another FM station and use the FM station sideband to broadcast the code (slightiy time delayed after the start of the news story due to code generation latency). This method seems presently doable but messy. Another method is to try to embed the code in the AM signal itself. For example, if the code is 2 bytes long and we try to embed it in 5 seconds time, then the data rate is only 3 bits/second. Since the data rate is so low, it sounds technically do-able. However, I am not currently aware of such data scheme and we either have to invent one or find one. One thing in our favor: on the receiver side, the hardware should be in place to digitize the audio signal (in preparation for compression and storage). Hence we only need to find the algorithm for encoding and decoding the code. b. Latency in code generation - If the AM news station is in full co-operation, then the news stories will first be passed through our editor before being read by the announcer. In this case, code can be generated ahead of time and there is no latency. However, assuming an un-cooperative station (they don't want to do anything extra), then our editor is basically eaves-dropping onto the news broadcast. Code will then be generated some 10-30 seconds (?) after the start of the story. c. Synchronized story capture - We will need a trigger signal to mark the starting time of the news story. Synchronized story capture will be accomplished in the receiver with the help of the trigger and the huge memory buffer as follows: the receiver will receive the trigger signal and the news story and starts recording into memory. Some seconds later, it will receive the code for the story. If the code matches the preset preference filters, then it is a "hit" and story will continue recording and be captured. If not, then recording will be abandoned and unit reset to wait for the start of the next story. Notice in this Phase 1, the station is basically co-operating but not pro-active. They are not. changing their mode of operation. Stories captured by the On-Demand News Radio will be the same as heard by regular listeners. The only difference is there will be more stories captured (stories that have been announced in the last 24 hours) and users have control to skip forward (and backward).

Phase 2 - The station becomes pro-active. They reserve 2-3 hours in early morning hours (2-5 am ?) for reading of in-depth stories. The length and details of such stories should be of the order of msnbc.com or abcnews.com, but less than the real lengthy ones on newspapers. The On-Demand News Radio will then attain its full potential: it will have in memory in-depth stories (typically several minutes long, captured in the middle of the night, like newspaper delivery) as well as late-breaking stories (broadcasted during daytime, typically 0.5 -1.5 minutes long).

2. Traffic, Stocks, Sports Scoreboard Broadcast

Traffic information relating to particular freeways may be too short for code generation and synchronized capture. In reality, news stations currently get around to traffic only about once every 10 minutes, which may not be up-to-date enough. In addition, traffic authority at major metropolitan areas may have much more traffic data (e.g. average speed on different freeways) then announced on current news radio stations. For more updatedness and comprehensiveness than currentiy available, traffic information should be sent as data and then speech synthesized at the receiver.

Stocks information has a different problem. If the user has a stocks portfolio, he would like to get the latest prices. There are about 7000 stocks in the U.S. stocks exchanges and it will be impossible to do broadcast by voice. Data Broadcast Corporation currently uses the SCA sideband to broadcast stock data in a loop in about 10 minutes. We can broadcast the same data and then speech synthesize at the receiver.

Sports Scoreboard, for updateness and comprehensiveness (e.g. including results of local colleges and high schools), should also be sent as data and then speech synthesized.

TJ. Engineering Issues

1. News story capture

The issues of code generation, trigger generation, synchronized story capture need to be investigated.

2. Editorial staff

Workflow should be designed to minimize the number of editorial staff at each station (for even uncooperative ones).

3. Tuners

Separate AM and FM tuners required ?

4. Voice compression/decompression

Decide on voice compression/decompression algorithm - Real Audio ? QualComm's Pure Voice technology ? Others, e.g. MPEG II, wavelet ? By software or hardware ?

5. Speech synthesis

Decide on algorithm. By software or hardware ?

6. Memory

Decide on amount (8 Mbyte ?), type (DRAM ? FlashRAM ?) 7. Microprocessor Microcontroller Choose one with enough power and at low lost

8. Power

Type and size of rechargable battery ?

On-Demand News Radio - Part 3

Daniel S. Kwoh March 26, 1998

This document is a continuation of On-Demand News Radio, Jan. 17, 1998, -Part 2, March 3, 998. Readers should refer to the above documents for background. Since the issuance of the last document, there has been the following changes in thinking:

Instead of sending voice in an AM station and data in an FM station, both should be sent in an SCA sideband of a FM station. This both reduces the cost of the receiver (FM and AM simultaneous tuning not required) and obviates the need to co-ordinate and synchronize voice and data broadcast at two separate stations.

Operationally, we also come to the important realization that, with few exceptions, there is no urgency to broadcast news stories in or close to real time. We can take time to process a news story voice file to generate trigger and category code and then put both voice and data on a queue to be broadcasted

There is no longer any problem of generating an accurate trigger, generating a category code in a short time, synchronized capture at the receiver.

Finally, in order to cut operating cost, centralized production at one national center, instead of distributed over city centers, should be contemplated

We will discuss the tentative mode of operation and outstanding engineering issues as follows.

I. Content sources

We have 3 categories of contents and they come from different sources:

1. Local news

There are two alternatives to obtaining local news: a. Partnership with a local newspaper. This will be the most complete and in- depth source. They will provide news in the form of electronic texts. We will need editors to cut the stories from newspaper level of details into something that can be read in 0.5 minutes (min.) to 3-5 minutes (max.). We will also need announcers to read the stories out. b. Partnership with a local news radio station. This is the original mode of thinking. Stories will lack depth and variety. However, the announcers' voices may be familiar to the local population. The radio station pipe the news to us in voice through some dedicated phone line.

2. World new, national news, business news

We may buy or partner with news organizations such as UPI, AP, Wall Street Journal, USA To-day, etc. to obtain the news. We will again need editors to edit the stories to appropriate lengths. We will need announcers to read the stories out.

3. Traffic, stocks, sports score-board

Traffic information needs to be obtained electronically from local traffic authorities, e.g. CALTRAN in California. Delayed stock quote may be obtained electronically from many sources. Sports results have to be purchased from various organizations with rights. These three data streams will be sent as data and the receiver will do text-to-speech synthesis to read out the data. Hopefully, each of the area is a limited-vocabulary application so that synthesized voice may have good enough quality. EL. Operation

1. We will establish a national operational center. It will be staffed with engineers, editors and announcers.

2. For output, the National Center will be linked by dedicated telephone line to an FM station in each target city (we need to study cost/performance trade-off of a satellite link instead of a telephone link). Each FM station will have an inserter provided by us.

3. For input of Local News, we will need either i. Dedicated telephone line to local news radio stations if we obtain local news from them; or ii. Telephone or Internet link to local newspapers if we obtain local news from them. Similarly for World news, National news, Business News, Traffic, Stocks, Sports, we will need electronic links to the information and data sources.

HO. Engineering Issues

1. Voice file

Should we send out analog voice from FM sub-carrier and let the receiver compress, store and later decompress or should we send out digitized, compressed voice file ? Digitized file will have the following benefits: a. All data are now digital data. Presumably, only one SCA subcarrier is needed, instead of one for voice and one for data. As a result, only one SCA receiver/decode circuitry is needed. This will lower receiver cost. b. Voice data (local news, world/national/business news) or text data (traffic, stock, sports) can now be handled uniformly as packetized data but with different headers ( (which contain trigger and category data)/error correction schemes. This may simplify software development.

Sending voice as compressed digitized data has the following engineering questions: a. Current candidate algorithms for compression are RealAudio (15 kbps), TrueSpeech (6-8 kbps), QualComm's PureVoice (12 kbps). Choosing the optimal algorithm is very important here. It will impact on the bandwidth required (and hence cost, since higher SCA BW is available but costs more), memory required (and hence receiver memory cost), receiver processor required (and hence processor cost). We should examine all candidate technologies, including fractal, wavelet, etc. do trade off analysis based on cost (licensing, implementation) and efficiency. b. For a 14 KHz SCA BW, what is the maximum data rate possible ? Does high data rate involve exotic scheme which may be expensive ? c. For the maximum 'data rate possible, can we squeeze compressed voice and text data through the same channel ? For example, stock data rate is about 2.4 kbps (for 7000 stocks, 25 bytes/stock, 10 minute loop time). If we use voice compression scheme at 12 kbps, we will need to send -14.4 kbps through 14 KHz channel. Is this possible ? We have some flexibility in data rate required. When stock data rate is at the maximum (during day time), voice data rate can be "throttled" down to pass through the channel.

2. SCA reception on moving platform Supposedly, SCA may have reception problem on moving platform. This needs to be researched.

3. Text-to-speech synthesis

What kind of processor power is required to do good job of Text-to-Speech Synthesis. Can single microprocessor/microcontroller do this with software or do we need additional hardware like DSP ? Can the micro multi-task speech synthesis and data reception at the same time ? What is the cost of implementation of speech synthesis ?

4. SCA Inserter, hardware and software

We need to source manufacturers of SCA inserter or make conceptual design and cost estimate ourselves.

5. Trigger/category code generation/packetization software Need to estimate the size of this job.

6. DAB

What we are doing smacks of Digital Audio Broadcast. Standards have been set up in Europe and U.S. We need to study to what extent we can use the established standards (instead of re-inventing a slightly different wheel). If what we do is sufficiently different from DAB, we also need to study the migration path to DAB if somehow it becomes (even though likelihood is low) the standard way of broadcasting in the future.

7. Cost of communication links

We need to estimate cost of dedicated lines or satellite links.

8. Cost of National Center

The National Center is like a production studio or radio station. We need to estimate cost of such a set-up.

9. Cost of Receiver

We need to estimate cost of receiver in 2 versions: walkman type, car cassette plug-in type. Cost should include charger, rechargeable battery.

Claims

WHAT IS CLAIMED IS:

1. A radio apparatus comprising: a receiver to receive transmitted radio signals; a tuner for extracting radio signals from the transmitted radio signals; memory for storing user-specified selection criteria and for storing radio signals deliverable in audible form; a microprocessor coupled to the memory programmed to select user-specified selection criteria from said extracted radio signals; said microprocessor further programmed to select a subset of the audibly-deliverable extracted radio signals according to said stored user-specified selection instructions; said microprocessor further programmed to store said subset of selected audibly- deliverable radio signals in the memory; sound delivery circuitry coupled to said microprocess for delivering in audible form the said subset of selected radio signals in the memory.

2. The radio apparatus of claim 1 further comprising: a user interface.

3. The radio apparatus of claim 2 wherein said user interface further comprising: one or more faceplate buttons coupled to the microprocessor; said microprocessor further programmed to respond to a change in physical sensing of one or more of said faceplate buttons; at least one of said response to cause an interruption in the delivery of said audible sounds and to further cause an alternative ordering of delivery of said audible sounds.

4. The radio apparatus of claim 1 wherein said microprocessor is coupled to a cellular telephone.

5. A system for delivering information in audible form comprising: a computer network; a computer program for collecting information concerning user-specified interests and preferences; a collection of information convertible to audible form; a radio transmitter for transmitting one or more sets of user-specified interests and preferences as radio signals; a radio transmitter for transmitting one or more records of said collection of information convertible to audible form as radio signals; a receiver to receive transmitted radio signals; a tuner for extracting radio signals from the transmitted radio signals; a memory for storing user-specified interests and preferences; said memory for further storing of a selection of said information convertible to audible form; a microprocessor coupled to the memory programmed to select user-specified interests and preferences from said extracted radio signals; o said microprocessor further programmed to store in said memory said selected user- specified interests and preferences from said extracted radio signals; said microprocessor further programmed to select a subset of said information convertible to audible form according to said stored user-specified interests and preferences; said microprocessor further programmed to store said subset of said selected 5 information convertible to audible form in the memory; sound delivery circuitry coupled to said microprocessor for delivering in audible form said selected information convertible to audible form stored in the memory.

6. A method of delivering information comprising: collecting information concerning user-specified interests and preferences; 0 transmitting said collection of user-specified interests and preferences as radio signals; preparing information for delivery to user in a form that can be converted to audible information; transmitting said information for delivery to user as radio signals; receiving transmitted radio signals; 5 extracting user-specified interests and preferences from said received radio signals; storing in a memory said extracted user-specified interests and preferences; extracting a subset of said information for delivery to user from said received radio signals according to said stored user-specified interests and preferences; storing in said memory said subset of said information for delivery to user; 0 delivering in audible form said subset of selected radio signals in the memory.

5