One of the Groklaw commenters asserted how FTP and even "TCP-IP" are prior art (OK, he corrects himself to say they are listed as 'related art' - whatever.) But the commenter is missing the fact that the patent discusses distribution of smaller parts of the file by "spraying" it around. FTP and HTTP can transfer large files, but your HTTP client doesn't download a single large file in small chunks from several servers.
The more accurate prior art are the methods for transmitting large files via usenet: split large file, uuencode parts, distribute parts to several usenet hosts (where there's also some kind of negotiation about swapping parts between hosts.) Finally client obtains, decodes, and reassembles those parts.
ReGet and other "downloaders" for years have been able to download files in chunks, from mirrors, and even automatically find mirrors: http://deluxe.reget.com/en/mirrorsearch.htm
I know at least GetRight was first released in February of 1997[1]... dont know if there is anything older than that... probably some command line tools though...
Also usenet downloading by parts has been around before that, from memory at least 1994-1995
1) Describe a system similar to the patent that is compatible with chunked-HTTP downloading from multiple mirror sites ( which has been around since before the patent )
2) Ask for declaratory judgement that such a system does not infringe on the patent
3) The troll will fight back, let them 'win', i.e. make them prove the system you describe is the same as their patent
4) Reveal the system is prior art => invalidate the patent
From the patent abstract I have a hard time imaging that they will win this lawsuit.
It's sort of like BitTorrent if you squint. Just BitTorrent provided by several central servers run by one company that wants to include DRM in every download from the system.
I'd like to believe that, but... I dunno. Things are crazy, and non-techies just don't understand technical things. It'll come down to how well the lawyers can convince the judge that this applies or doesn't apply.
I'm surprised that the bittorrent patent issued because the patent looks like it claims what the digital fountain patents (now owned by qualcomm) claimed several years previously.
I'm going to explain "digital fountains" a bit more because I think they are really cool. The "fountain" in "digital fountain" refers to fountain code. A fountain code can take a file and generate an infinite stream of codes. As long as the receiver obtains a portion of the codes that is just slightly larger than the file size, they can recover the original file. These codes are immensely useful for broadcast distribution. You can broadcast the morning newspaper using a fountain code and everyone's mobile device will obtain the file after downloading the paper's size + a bit more of the fountain codes. When using wireless radios, broadcast distribution is very desirable because unicast distribution (think HTTP) doesn't scale while broadcast scales perfectly.
There is a little more to them than that. What you describe can be achieved simply by broadcasting the whole file over and over again with sequence numbers. The thing about fountain codes, if I remember them correctly, is that you can recover from having received corrupted packets by receiving only a few more packets, instead of the whole newspaper again.
But that, too, is achievable in a simple way: just fit a degree-N polynomial over a finite field to N+1 symbols made out of your data and emit an infinite stream of values of the polynomial. Any N+1 correctly received symbols are sufficient to reconstruct the original polynomial. A computable algorithm for error correction in this case is to try all the N+1-sized subsets of the data you've received, largest first: omit received symbol #1, then #2, then #3, etc. If you have found a subset with no errors, then the polynomial fit to its N+1 first values will successfully predict the rest.
Unfortunately, this error correction algorithm is absurdly inefficient. But I seem to recall that fountain codes have an efficient error correction algorithm as well.
The more accurate prior art are the methods for transmitting large files via usenet: split large file, uuencode parts, distribute parts to several usenet hosts (where there's also some kind of negotiation about swapping parts between hosts.) Finally client obtains, decodes, and reassembles those parts.