Prior art is not as easy to use as a defense as people usually think. On that topic, I found the talk by Andew Tridgell quite interesting:

" You need to learn to read patents. And that doesn’t mean just the abstract. In fact, many people in the free software community, a lot of discussions on sites like Slashdot, people stop at the title. And they think that based on the title they can say "Ah, that was done by the FooHits Corporation in 1925, therefore it’s not a problem". Right? And it doesn’t work like that. You can’t stop at the title, you can’t just stop at the abstract. "

http://news.swpat.org/2010/03/transcript-tridgell-patents/

Circa 2000 I and another developer at my company implemented two systems which are very good examples of prior art for this patent. Both of those systems are still in use today, and I consider the mechanism to be a standard design pattern for robust SOA components. Reading the claims, the only ones that don't match what we did are the claims that say the system is implemented in Java; ours are C++ and Perl. That should be sufficient to invalidate the patent though, at least in a reasonable world.

It's possible to invalidate only certain claims of a patent with prior art. In theory you would think that if there's lots of prior art of people doing XYZ, then someone doing XYZ in Java because their project uses Java would be obvious and therefore not patentable. In practice the Federal Circuit has taken an absurdly narrow view of "obvious".

I guess that might also answer something I've been wondering since this began (well actually before, but this case has brought it back up in my mind). If you take some people skilled in the relevant art, and just describe a problem to them and tell them that someone did solve it but not how it was solved, you lock them away to do a clean room implementation of something that solves that problem, and then their solution happens to be the same as in some patent... then isn't that a bit of evidence that the solution in the patent isn't non-obvious?

Exactly. In fact not only could you say it isn't non-obvious, you might go as far as to say it is obvious.

Was the code published?

Not externally, but there's plenty of documentation and version control history internally, and many witnesses who can attest to the accuracy of those records. That may or may not be sufficient evidence of prior art.

For the Perl implementation, the basis of the design came from the book "Network Programming with Perl" by Lincoln Stein. I'm pretty sure he covered the basic "accept a connection and fork" pattern, and in the Perl world the big benefit of the pattern is the pre-loading and compiling of modules/classes that the forked process is going to need. So that book probably contains sufficient published prior-art.

It is a bog-standard technique in the mod_perl world.

For instance chapter 10 of Practical mod_perl is titled, Improving Performance with Shared Memory and Proper Forking. Guess what that was about? This was published in dead tree format in May 2003, before the December 2003 filing date for this patent. And it appeared in online documentation before that.