Seven Constraints for an EU Software Patent Law

Assuming that the EU is really going to adopt software patent laws, what constraints must be met? What would help to protect the interests of small companies as a last resort to avoid that all innovation is relocated to countries outside the EU?
| posted on Mon, 28 Mar 2005, 15:17 | weblog | rss | spin-off | comments |

There are some ground rules that should be embedded in any patent law that is thorough. If these rules are not met, the risk is that a pecking order is created, in which large companies with many software patents peck on smaller companies, perhaps open source programmers, who accidentally use code that appears to have been patented before.

Author: Rick van Rein is the founding owner of OpenFortress. OpenFortress is a perfect example of a small company that with a strong motivation to innovate software technology, in this case in the area of digital signature applications. Rick considers software patents a serious threat to OpenFortress' ability to innovate, as well as to software innovation in the EU in general. This article was written to make clear under which constraints a patent law would be just bearable. OpenFortress would prefer not to be forced to leave the EU just to be able to continue innovative software development.
Patent status: Read this historic perspective to understand why the current state of affairs is not quite clear to me. I agree that the whole software patents is more of a political circus than anything else.
Remark: Please do not assume that I am in favour of a software patent law. I am one of the many that have signed the petitions against the introduction of software patents in the EU, because I believe software protection to be a copyright matter. Also, I don't see a need for sparking software innovation, as a lot seems to be going on without patents to trigger such innovation. But given that EU politicians want to go this way, I think it is important to give them the best guidance possible. This is my serious attempt to provide such guidance.

Constraint 1: Compensate major investments only

Rationale: A problem with ideas is that many people can have them. It would be bad if an idea can be patented by the party that happens to be the first to a patent office. Patents are not designed to introduce chances of suing parties, they are intended to motivate development.

This means that patents should only be granted to compensate for major investments by the developing party. Major investments mean that time and money is put aside for development of something that cannot be funded any other way. The investment for the patentable solution should not include costs that can be subtracted elsewhere; for example, costs that lead to enhancements of existing products or creation of new ones that market in the short term, or costs that are covered by funding or tax savings.

Software innovations quickly become commonplace, and the period during which an investment can be earned back must therefore be much shorter than for other technologies. There are many examples of things in common use that are still carrying the burden of a patent today. It seems prudent to say that a software patent should be valid for 5 years at the very most.

Solution: A clever approach would be to evaluate the Return On Investment. A patent-requesting party would specify their investments and be open to inspection by an accountant. The return would be specified as an exploitation plan, detailing all requested forms of patent exploitation and the charge to apply for each. This also specifies a maximum total return that will be charged to earn back the investment, as well as a maximum period over which it should be earned back. The patent office must adhere to reasonable Return On Investments and reasonable exploitation periods, as would be specified in the software patent law.

Constraint 2: Expert review and Public review

Rationale: Software patents must be evaluated by experts in the field. Nobody is waiting for patents that take too much liberty by being vague, thus including too many cases. For example, I could write technical-sounding, but too-broad cryptographic patent requests that only an expert in the field would be able to tackle. Such purely commercial patent-exploit would hinder progress, rather than accelerate it. The patent office must therefore take initiatives to ensure independent expert review.

In addition, experts anywhere in the world should be offered a chance to listen in on the patent proposals, and respond to the requests that were put in. The patent offices must evaluate such responses at the content level, meaning by field experts.

Solution: A patent office could be structured along the same lines as the Internet Engineering Task Force, which has well-defined policies and processes for open interaction on producing high-quality technical standards. The IETF also employs a body of domain experts to evaluate several application domains and to maintain their consistency.

Constraint 3: Prior art to consider

Rationale: Software patents concern software. As a result, prior art covers all software that is publicly available. This includes the vast body of open source software. A patent request that is so general or small that it could be anywhere in publicly available software is probably unsuitable to be assigned as a patent.

It is the responsibility of the patent office to research all available software. It is the responsibility of the patent requestor to pay for this research. As a side-effect of this mechanism, it avoids too-small or too-general patent requests. Nitty-gritty patents have one effect only: they block progress.

Another element that counts as prior art are public specifications. Notably, any possible Internet Draft that has ever been posted in the drafts repository, even if it didn't become a standard, is a form of published prior art. The same applies to online specifications, blog entries and any public web pages with technical information. These communication mechanisms are of vital importance to the innovation of software and can therefore not be ignored.

Patents granted in other regions of the world also count as publications, so as prior art. This means that a patent filed in another country automatically excludes the chances of filing a patent in the EU. Work should be undertaken to get similar statements included in the patent law and practice of other countries.

In case of overlap between a patent request and prior art, a patent should not be granted. If a patent clearly states certain prior art as a dependency, then only the added aspects can be patented in precisely the way they are added.

Solution: There is an immense body of public prior art that details software and software development. Software patent requests must be compared with all open source software, open specifications and public technical information and charge the patent requestor for the time invested to research it. Patents are publications, so a patent granted in the US automatically makes it impossible to get the same thing patented in the EU.

Constraint 4: Right of appeal

Rationale: Small companies usually have more pressing concerns (for example, to innovate and to develop) than to track patent discussions on all sorts of topics. It cannot be expected from small companies that they read every single patent request. Simply because they have more on their mind, namely to innovate. Patents exist to stimulate innovation, but stimulation of one innovation should not block other innovations.

The charge for using a patent may therefore be the first thing a programmer or designer sees about a patent. To protect his rights to innovate, the programmer or designer must therefore be offered a chance to appeal the patent, if he has ways of proving that either he or another external party has published the solution prior to the request date of the patent. Suitable proofs would be 'common knowledge' such as publications in magazines, in open source software publication places, in dated web archives, or securely timestamped documents. In general, a convincing confirmation by an independent outsider is required.

The expenses for such charges must not be carried by the party filing the appeal. Those expenses must be carried by the patent office if it concerns publications that they ought to have been aware of, or by the patent owner if this is not the case. The owner should allow room for appeal costs in their estimated return on investment calculations.

Since this introduces a dependency of the patent office on the outcome, the patent office cannot make the judgement. A financially independent appeal board with all applicable expertise must take care of this task.

Opinion: An appeal is basically a yes-or-no decision that need not be complicated, since evidence is provided by the party that appeals. Evaluating such evidence is much less work than was investigated by the patent office, and can therefore be resolved much faster. The patent law should arrange a maximum running time for an appeal, for instance a month.

Opinion: When an appeal is proven right, the patent will be revoked, which will be formally announced by the patent office. The patent owner is then responsible of paying back all patent fees applied in the past.

Solution: Parties may be unaware of using a software patent. For this reason, patents must always remain open to appeal. Appeals are evaluated by an expert board, which is fully independent of the patent office. Expenses for such appeals are carried by the patent office (if granted) or the patent owner (if denied).

Constraint 5: Warn first, charge later

Rationale: As stated under the previous constraint, it is possible that a programmer uses patented software without realising it. It is therefore good to avoid any risk of charging a company if they are willing to remove patented solutions from their software. This protects budgets intended for innovation, which means it is in the interest of patent law.

This places the charged programmer in a position to choose whether or not to keep using the patented solution, perhaps after a failed appeal. The charges for using it are defined in the return-on-investment plan mentioned above, so the decision to make is clear. Patent charges can never apply to business done before the date of the charge, plus a reasonable grace period defined by the patent request and constrained by patent law and by evaluating experts' opinions.

With the programmer in a position to decide between alternatives, there seems to be less need for trials in court. This means that the negotiation can often be conducted as a normal trade between patent owner and patent user. The drain of a trial on a small innovating company is incredible and should be circumvented wherever possible.

Solution: A programmer or designer must be allowed to first appeal a patent if this seems reasonable, and then to decide whether to remove the patented solution at no charge, or to keep using the patented solution and pay the charge posed by the patent owner.

Constraint 6: Open source exemption

Rationale: Much of today's software development is based on open source software. Anything harmful to open source development is directly harmful to software innovation. For this reason, software patents should never apply to open source software.

Open source is more vulnerable to patent charges because it reveals every single aspect of the software -- namely, the source code. This position is not fair in comparison with closed-source software, which can only be proven to use patented solutions with much more effort.

If open source software is not exempted, then at least the chargability of the software must be equated with closed-source software, to avoid that open source development is stopped. This would mean that the software must be shown to use patented solutions from the outside, and not based on its distinguishing trademark, the source code.

Solution: Ideally, open source software would be exempted from patents. As an alternative, a law could allow only patent grants that can be based on the behaviour of compiled software.

Constraint 7: Review old patents again

Rationale: Software patents can be a threat to innovation, if the above rules are not followed. There currently are some patents that were assigned to software solutions. These form such a threat. They must therefore be re-evaluated.

Solution: Software patents have been assigned in the past. If a new patent law is instated for software patents only, these patents must be re-evaluated under the new law. If they happen to not apply anymore, the revocation process described above should be applied.

Vertaal naar het Nederlands Vertaal naar het Nederlands

Comments on this article