General knowledge on how software patent-infringement lawsuits are evaluated

Question

Technically someone has to check the suspected software code, to see if it infringes a specific patent. But

• What if the suspect claims, that it is his companys own trade secret? are trade secrets in any way respected? in other words any trade secrets can be tricked out from its owner, by accusing him of a random patent infringement?

• What happens if the suspect refuses to provide her source code? Someone starts decompiling the executable, or the suspect is automatically declared as an infringer? Source code losses have happened to people who are not criminals.

• What if the suspected company refuses to provide any form of its product(service)? In this case can the suspected company effectively defend itself from the prosecution?

These questions highlight the knowlegdge I lack to understand the process of the patent-infringement-lawsuits. (Please let me not to reference unsuccessful search queries. I really tried to search)

Answer 1

Suppose you own a patent with claims that may be infringed through, at least in part, software. You think some company, call them Acme, infringes at least one of your patent claims.

In the US, you are required to perform a reasonable investigation into Acme's products and services to make the claim that Acme infringes your patent. Because source code MAY be necessary to prove one way or the other that Acme does or does not infringe, you will most likely not be completely sure of infringement, only reasonably sure.

During discovery, you will ask the federal judge to allow you, through your attorneys and experts, to review the source code, so the infringement case can be decided on the facts and not on supposition.

Acme will claim that its source code is a trade secret and will ask the judge to restrict both how the source code is produced (in a locked room with no recording devices or network access) and to whom the code is produced (basically, attorneys and experts only, who all agree to maintain the trade secret nature of the code under the supervisory authority of the court).

Acme will most likely provide the wrong (or incomplete) source code the first few times, until the judge issues sanctions against Acme for failure to produce responsive documents (the source code). Acme will be driving up the cost of the litigation for its own purposes. (Sad but true in many cases that I have seen). In rare situations, usually where Acme knows it does not infringe, Acme will provide just a relevant snip of the source code to prove non-infringement early on and tell you to go away.

There is no reason to decompile the executables in the US, for failure to provide the source code as requested would be enough for the judge to grant summary judgement against Acme, or, more likely, tell the jury that they are to assume that the source code infringes as a sanction against Acme for their failure to produce. These are choices that Acme makes.

The situation you suggest about tricking Acme out of their trade secrets is more likely to occur in trade secret litigation. Suppose a programmer moves from your company to Acme. You think the programmer took some trade secret source code to Acme, who is now using it in a new product. You sue Acme for theft of trade secrets and several other related causes of action, in either state or federal court based on the circumstances. You and Acme will quickly get into a fight over trade secrets. Acme will demand that you provide a detailed description of all trade secrets that Acme is accused of taking. You will demand that Acme provide the court with a detailed list and history of all of their trade secrets before you provide the detailed list of the trade secrets you claim have been taken. It can be a real chicken-and-the-egg problem in terms of fairness to both sides.

Answer 2

Pre-emptive disclaimer: I'm not a lawyer, this is not legal advice.

In the US, before you can bring a lawsuit, there is something called "Rule 11" that must be overcome. Rule 11 sort of says that you need to have some evidence or reasonable belief to support your case before you can file a lawsuit. (This is a broad generalization and may not apply to all cases and all jurisdictions.) This is to prevent frivolous lawsuits [1].

In case of patent lawsuits, it often means that you may need to have proof that somebody is infringing, or a reasonable explanation of why you think, before you can file a lawsuit. In case of some products where implementation details are not openly available, this may seem like a Catch-22 situation, but rule 11 is a relatively low bar, and it may be possible to satisfy it without solid proof.

But the upshot is, typically a plaintiff may have to do infringement analysis before filing a lawsuit to, amongst other things, satisfy Rule 11. This applies to all kinds of patents, not only software. Often, instead of actual proof, the public comments of the alleged infringer (or an employee thereof) may provide sufficient basis. Once the lawsuit is in progress, however, there is a process called "discovery" which takes place, in which the attorneys of both sides demand access (which the other side is legally required to satisfy) to all material that may be relevant, including not only the source code / schematics / design docs / diagrams, but also emails, logs, internal memos, documentation, and all manner of communication related to the allegedly infringing product(s). As mentioned in the comments above, access to this may be restricted to protect trade secrets and the like.

However, what do you do before the lawsuit is filed and you need to do some sort of infringement analysis? Since you asked about software, let me talk about that.

Often, the code may be open source, for example, Linux or Android, which may make things somewhat easier. Even with access to the source, it is surprisingly difficult to show infringement. One example is "divided infringement", where two or more parties act together to perform all the steps in a claim. This is a very common occurrence in today's "cloud"-based world. (Or, in non-marketingspeak, a client/server setup where some of the steps are performed on the client and the rest on the server.) Until a recent case shook things up, this did not count as actual infringement. Alternatively, it is also difficult when when some steps are performed by the open-source software and the rest by a third-party, closed-source driver which is opaque to the casual observer.

Another problem is, even with access to source code, having to convince a lay jury that the technical mumbo-jumbo, that is called "source code", actually does what this other kind of technical mumbo-jumbo, that are called "patent claims" -- which look like English -- describes.

However, even without access to the source code itself, there are several possible ways to do infringement analysis:

1. Many patents cover aspects of the product that is readily observable, such as UI aspects or behavior of the software. Infringement can be shown simply by executing the software. (Apple's "slide-to-unlock" and "over-scroll bounce" patents that they used against Samsung are a good example of this.)

2. If the product is available as an executable, decompiling it and examining the assembly may be needed to show infringement. This means you literally have to reverse-engineer the software. This is, of course, quite difficult, and may be even more difficult to hold up in court. Even for languages like Java, which (if not obfuscated) decompile to code that is very much like the original source, it may be difficult to show infringement.

3. If the patent claims include network communication or protocols, it may be possible to show infringement by executing the software and running a packet sniffer to collect traces of packets being sent and received. Correlating those packets with changes in the behavior of the software may show infringement of the method. This is similarly difficult, and may be even more so if communications are encrypted. Sometimes, claims cover wireless communication methods, modulations or protocols, which means you need specialized (and expensive!) equipment, and the (even more expensive!) experts to operate them, to capture signals in order to detect infringement.

4. If the allegedly infringing software is hidden away on a server and provided as a service, you could try providing various inputs and observing the corresponding outputs, and try to show that this would only be possible if the service implemented the method of the claim. This, as you might guess, is also extremely difficult, and may in fact be impossible when the patented method covers such a narrow aspect of the service that the effects of the patented method in the outputs are negligible. However, a good example of this method, which is actually done on a daily basis, is "Search Engine Optimization", which is essentially reverse-engineering of Google's algorithm-du-jour to manipulate a given website's search ranking.

5. If you're lucky, somebody has already reverse-engineered the software in question, and has provided a write-up or, even better, an open-source alternative (or client, in the case of services) for you to examine. This is rare, but happens more frequently than you'd imagine. The open source world is rife with projects -- that somebody wrote to scratch their own itch -- which emulate, and are highly compatible with (and hence a very good approximation of), the original closed-source software.

There are many, many more types of software-based inventions, and as many ways to analyze the products for infringement. The list above is just to give you an idea of some possible methods. Contrary to what people may assume, it is actually very difficult to prove infringement of most patents.

However, if you think about this, it explains pretty well why there is a furor about "software" patents in the press these days. The patents that are easiest to prove infringement for happen to be patents that cover readily-observable aspects of software, such as those covering GUI elements (Apple's slide-to-unlock, over-scroll bounce-back) and high-level software behavior (Amazon's one-click), because they are easy to prove infringement of, and consequently, those are the patents that are asserted in patent disputes. There are undoubtedly much lower-level, technically in-depth patents that are being infringed, but which would be difficult to try in court in front of a lay jury, and hence are not asserted.

Think about it: would you rather try to prove infringement to a lay jury of Apple's over-scroll bounce-back patent [2] -- something you can demonstrate to them by simply using the allegedly infringing device in front of them -- or Samsung's patent about the length fields in packets [3], which could only be explained by providing an abstract technical explanation of wireless communication protocols, packets, networking and message fragmenting? Considering this, the outcome of the Apple v. Samsung dispute is hardly a surprise.

So of course, the patents that show up in tech media are the ones that are asserted, and it is no wonder that the patents being asserted are mostly high-level patents that can be easily shown to be infringing, which people decry as "obvious". Well, of course they are "obvious" (though not in the patent law sense), simply because they are easily observable and hence easy to show infringement for. However, that does not necessarily mean they are "obvious" in the patent-law sense, which has a very specific meaning that has nothing to do with how apparent it is or how apparently easy it is to implement. Similarly, these patents may also be "trivial" to implement, but triviality is (rightfully) not a requirement for patents: the RSA patent is pretty trivial to implement [4], but, by all accounts, was not obvious at the time.

1. http://en.wikipedia.org/wiki/Frivolous_litigation
2. http://www.google.com/patents/US7469381
3. http://www.google.com/patents/US7675941
4. 4-line Python RSA program, http://www.cypherspace.org/rsa/python.html