I question the validity of the audio and video transmission and receiving system patent in general, but in particular I question the assertion that it is being infringed by web radio. I work in web radio. I am also an inventor and have a couple of inventions relative to webcasting in various stages of the patent process. I am involved in non-subscription webcasting, operating under section 114 of the statutory license. What I am about to describe would also apply to webcasters operating under The Small Webcaster Settlement Act of 2002. I have identified three types of "radio" webcasting processes which are described below. The word radio is really inappropriate here since radio, by definition, is a wireless transmission. It has been adopted by the webcasting industry however to describe the product in a term familiar to the consumer. The product is similar to terrestrial radio in many ways, and is constrained by the terms of the statutory license and the SWSA to remain so. Those terms, called the performance complement , severely limit the scope of interaction that a listener has with the webcast.
Live/Simulcast
This is the type of webcasting used by radio stations, though it can also be used in an internet only format and is often used by hobbyists. In this system a program director or DJ is playing songs from the station library or their own personal collection. The webcast begins with the CODEC on the streaming server which "compresses" the audio, removing bits using one of a number of different algorithms to prepare the audio for streaming. After processing the bits are sent to a spool file. The spool file can be visualized as a cup of water that is filled from the bottom with a straw at the top that allows people to sip from. The spool file holds a finite number of bits, just as the cup holds a finite amount of water. The spool file is small, too small in most cases to hold a complete song. The spool file is made available on the internet. The client accesses the spool file by its URL. A spool, or buffer, is then created on the client side. Sometimes the spool is written to disk, sometimes it remains in RAM. That is determined by the CODEC being used. The client side buffer is essentially a mirror of the streaming server spool, more or less depending on bandwidth lag. All clients are receiving the same thing at more or less the same time, if it's a music webcast it will usually be picked up mid-song. The client side buffer, in most cases, never holds a complete song, it's too small. The buffer is always passing its bits to the CODEC on the client side, where they are reprocessed and sent to the audio output. When the client disconnects from the stream, the client side buffer stops receiving bits and empties out to the client side CODEC. No song data is retained on the client side.

You can see that in this system the client has no way to access the song library directly, in fact the song library may not even be stored on a computer. There is no way for the client to choose what song comes next. There is no means for saving the content for playback at a later date. This would be a violation of copyright law and the performance license.
Simulated Live
Simulated live webcasting is used to create the illusion on the client side that they are listening to a live show. The difference is that the song files are stored on one or more servers, preprocessed by the CODEC and ready for streaming. The program director creates a playlist. The playlist contains the paths to song files in the order in which they will be played. The playlist is read by the streaming server which then retrieves the file from the library and starts sending it to the spool file. When the playlist ends the streaming server reads the playlist again and the process starts all over. The performance complement of the statutory license dictates many of the parameters of the playlist creation, including length and artist rotation. The client side of a simulated live webcast is identical in every way to a live/simulcast webcast.
Library Distribution via CGI
With the Library Distribution via CGI system of webcasting the client accesses a program on the webcasters server. These programs, which I'm referring to generically as a Song Picker CGI, are generally proprietary and vary from webcaster to webcaster. The Song Picker CGI accesses the webcasters library of song files, which have been pre-processed with the webcasters CODEC of choice, picks a file and then begins sending it to a spool file that the streaming server creates for the client. The Song Picker CGI can be very simple, creating a random playlist for the client, or offer varying degrees of interactivity. The level of interactivity is governed by the statutory license and the SWSA. Clients can not directly access the song library. They can not know what song is coming up next or what other songs are in the library. The number of songs by any given artist must be limited. In this system, every client is receiving a unique stream. The characteristics of the buffer on the client side are the same as the previously mentioned systems. When the stream is disconnected by the client, nothing remains on the client side. There is no permanent storage and no possibility of playback at a later date and time of the clients choosing.