Forces of Nature

How to apply clear limits of patentability to two real-world examples

Example 1: Innovative Loom with Steering Software

Consider an electronically controlled loom. A change in the steering software improves the way the thread is handled. Would this innovation be a patentable invention according to the Parliament's directive of 1st reading?

Yes, it would.

The innovation does not lie in the software, but in the way forces of nature are applied to control the thread in the loom. This steering can be done by mechanical means, or it can be assisted by software. This difference is not relevant to the nature of the innovation itself.

Recently, this patent (EP 1 147 250, Te Strake) was presented to the members of the European Parliament as an example of a valuable patent on software (“computer-implemented invention”). In fact this patent is not on software, but on a method of applying the forces of nature inside the loom.

Example 2: Loom with Innovative Steering Software

Now let's think of another type of innovation in the same device. We do not change the way the thread is handled, but instead we improve the software for its own sake—for instance, by adding support for a new standard for computer networks (like being able to operate the loom via an internet connection).

This innovation would not be patentable according to the Parliament's directive of 1st reading. And it should not be.

Why not?

To understand this, we must understand how competition takes place in the software market.

Let us consider two competing manufacturers of looms, A and B. Manufacturer A comes up with looms whose software supports a new network standard. Competitor B wants to provide the same innovative feature. What are B's alternatives?

B could, for instance, buy one loom from A, extract the software from it, and use it unmodified in its own loom. By doing so, B would infringe on A's copyright, so this would be prohibited by law.

The next thing B could do is to reverse-engineer A's software and re-implement it. This would still be forbidden by A's copyright, although more difficult to detect.

As any programmer can confirm, this task is very hard work. For any significant program this is close to impossible. (In practice, programmers perform this task only when it is unavoidable in order to achieve interoperability with a given competitor's software—the only case where this is legal.)

Why is this task so hard?

When software is written, the programmer edits the so-called source code. For making changes to the software—for instance, adapting it to run on a different loom—access to the source code is needed. By keeping the source code a trade secret, manufacturer A can protect his innovation against cloning. This protection mechanism has proven itself for over 20 years to be effective for innovations in software.

So there only remains one possibility for manufacturer B to compete with A: analyse, from observation, what the software on A's loom does, and independently write new software which does the same.

Such an independent implementation requires as much work as the original innovation. What you gain from analysing interesting ideas in the competitor's software, you lose while painstakingly re-building details where the first implementor had the freedom to choose the simplest approach to accomplish the task.

If competitor B succeeds with his independent implementation, he can compete with A. In the meantime, A can have gained significant market share, or have moved on to further innovation. This is how fair competition in a free market works.

To summarize:

  1. The cases, where B could get an unfair advantage over A by cloning A's innovation, are protected by copyright and trade secrets.

  2. The case where B can invest the same amount of work as A in order to provide the same innovative feature would be legal according to copyright, but forbidden if a patent was granted.

It does not matter whether the software is running on standard computer hardware, or on a loom. (It would, however, make a difference if the software affected the application of forces of nature instead of just the software itself—see example 1.)

In fact, a patent on A's software innovation would prohibit even more than just case 2 above. Consider, for instance, a case where A and B are simultaneously working on the same innovation, but only one of the two can get the patent.

Like example 1, this patent (EP 1 381 202, Birdstep Techn. ASA, Sweden) was also presented to the European Parliament as an example for a valuable software patent, with a mobile phone instead of a loom.

This patent is not yet granted, and we hope that it never will be.

Click here to download
a printable version (PDF).

More about Software PatentsContactxhtml 1.0 – Last Update: 25 May 2005