There is a series of software patent cases on this very issue. See Finjan v. Secure Computing, on so-called "latent code."
First, it makes a difference whether the patent claim is for a method (dynamic) or for an apparatus/device/medium (static).
A method claim is very unlikely to be found infringed by latent code (located in the binary, but never executed). An apparatus claim however could be. See the Finjan case, and/or do a Google search for: finjan latent code.
Second, also consider the type of infringement that has been alleged: one can infringe, not only by using a patented invention (dynamic), but also by making, selling, or offering for sale. Source code itself might infringe by "making" and never-executed binary code could infringe by "selling." Of course, monetary damages might be low.
There are a related but different set of considerations when using code to show invalidity (as opposed to infringement) of a patent.
To anticipate a patent, prior art must have been publicly accessible, and capable of "teaching" the invention to someone in the field, at the time the patent was applied for.
Proprietary source code is unlikely to have been publicly accessible. So if "dead code" refers to code that has been #ifdefed out, it's unlikely prior art.
If "dead code" refers to code located in the binary, but never executed, then its prior art status depends on whether someone in the field could have found the code, e.g. if there were strings or debug symbols sufficient to disclose the invention.
@etmax I don't disagree with your first premise that true patent infringement requires at least the presence of code that can be run (apparatus claim) or even that has been run by someone (method claim). Perhaps this abbreviated version of the original longer article has made my position less clear.
That said, a later part of your comment provides a perfect explanation for how dead code could cause legal liability. Many times in legal work only the actual source code is produced and not the Makefiles or tool configurations necessary to indicate which #defines are active in a particular build. Or the files are there but the configuration possibilities are manyfold. It is in this way that both experts can wind up basing their infringement fight on potentially infringing code that may or may not actually be in the real product.
Now if the code has to be there to implement some user-level feature, then simple product experimentation can show it is not compiled in. But if the patented algorithm could be part of some lower level functionality that functions either way, then the proper experiments may not always be possible to arrange relative to the dollars at stake.
@Michael, You seriously worry me if you as an expert witness think that dead code conditionally compiled (#ifdef etc.) can have legal standing. You mention "in the binary" but conditionally compiled code IS NOT in the binary. In addition to this some companies provide complete development platforms where the entire mix of functions is decided by the end developer based on setting #defines so to base the patent liability on such a thing is nothing short of ridiculous and if it's happened a complete miscarriage of justice and every such case should be revisited.
I've sifted through the assembly listings produced from my C code during debugging effort and everywhere there is an #ifdef etc. the code generated is nil.
In fact consider if I write down details of a patented algorithm in the comment section of the source code (that is essentially the same thing) all it says is that I know the algorithm necessary, I haven't installed that in any product because the binary doesn't have the comments or the #ifdefs, so it never leaves my office. I am therefore guilty of having a description of a patent which is no more illegal that downloading the patent application from the patent office.
If my comments or #ifdefs are breaking the law then every person who does a patent search is breaking the law.
There are even complete operating systems you can configure based on #defines where you actually have no idea what code is run because the extensive #defines and #ifdef's so obfuscate the code that actually gets compiled that no one really knows.
And this has been going on since code was written in the 1980's in assembler.
Companies large and small use this feature I'm talking Sony, NEC, Motorola and many more.
The reason why it is done is because it produces very tight efficient customisation without any bloat so many other methods introduce
So, I think you are wrong and If I were before a court for this I believe I would win.
A few years ago there was a well respected Federal Judge was trying to address a similar situation. Unfortunately he was well up in years and didn't really understand modern technology. To make matters worse, his educational background was in economics. The accused product incorporated a feature that caused it to infringe. The accused infringer argued that none of their customers cared whether or not the feature was present. The patent holder argued that if it was present the product infringed, whether the customers used it or not. Besides why would they have the feature if nobody cared about it?
The judge wanted an independent survey of the thousands of customers to find out how many used the accused feature, how often they used it, what part that feature had in the purchase decision, as well as what part the feature had in product ratings and recommendations the customers made after the product was purchased. The survey the Judge wanted would have cost well over $1 million just for a statistically valid sampling of customers and would have taken months, or longer depending on how long it would take to locate the customers. The lawyers on each side spent months arguing about the issue, most likely billing their clients $ millions. The case finally settled before trial with the accused infringer taking a license and paying more $ millions to the patent owner.
The real winners were the lawyers. Over and over again I see similar outcomes. It seems that the old joke about the lawyers for both sides getting together over coffee and deciding what they can spend their clients' money arguing about isn't far from the truth. That usually starts when a patent owner sends an infringement letter to some company and the company lawyer advises company management to ignore the letter. Once you let your lawyer (or any other non-business professional) dictate how to operate the company the only one that comes out ahead is the lawyer.
The two scariest things a business manager can hear are 'I'm from the govrnment and I'm here to help' and 'I'm your lawyer, let me handle it.'
IANAL, but it would seem to me that dead code, since it's never actually used, cannot possibly be patent infringement except due to jury or judge error (both of which are serious risks in any court case). My understanding is that for a patent to be infringed, it actually has to be used. For example, when damages are being considered, the plaintiff will try to argue that the consumer would never, ever, ever have considered buying the defendant's product except for this wonderful patented feature. Well, if the code is dead, there's no way the consumer could have used the allegedly infringing feature, so there's no way that was the reason the consumer purchased the product, ergo, zero damages.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.