That anti-patent pamphlet I mentioned

Marcus Brinkmann Marcus.Brinkmann at ruhr-uni-bochum.de
Fri Dec 13 17:24:17 UTC 2002


Hi,

On Fri, Dec 13, 2002 at 01:29:54PM +0100, Arnoud Galactus Engelfriet wrote:
[about the meaning of "as such"]
>
> No, it means that a computer program by itself cannot be patented.
> A hardware device that contains some software can be an invention,
> even if the invention resides in the software.

That's what the EPO wants it to mean, but that is not supported by the law
and any rational interpretation of it.  It is the EPO which invented the
term "technical effect" to justify granting software patents, but the
distinction between "a program as such" and "a program with a technical
effect" is not a distinction you can derive from reading the law.

In other words, the EPO wanted to grant patents on software.  Because they
couldn't do it i a straightforward way, they had to be very clever and
create a construct that would allow them to do so.  The construct is that of
the "technical effect" and the artificial distinction between a "program as
such" and a "program with a technical effect".

It is this artificial construct, which I think is in violation of the law,
both in intention and to the letter.

There were loads of discussions about this term, and we certainly could go
on repeating the details of the discussion here.  Or we could just both go
and read up the discussion on swpat.ffii.org ;).  But on the other hand, it
is probably less work for both of us if I end the discussion before it
really started and say that I reject the construct of the distinction
between "a program as such" and "a program with a technical effect", claiming
that if you allow a patent on the latter you fundamentally allow patents on
the former as well.  As I assume from the rest of your mail that this is a
distinction you want to draw, it's probably better for us to retract in the
agreement of disagreeing.  Otherwise, read on :)

> Keep in mind there is a difference between "invention" and
> "having an inventive step" in the EPC. 

Can you remind me of that difference?

> >In any case, it is then
> > the task of the politic to constraint the courts by reinforcing the law
> > (probably changing the wording a bit so that the clever tricks are not
> > possible any more).
> 
> Either that, or to change the law to accomodate the new direction
> chosen by the court. 

There are two reasons why this would be bad.  First, it would be directly
against the idea of division of power.   The conclusion to what the law
needs to be changed must be made by politicians, which are bound to the
will of the citizens whom by they are elected.  At least in Germany there
is only one court which is able to give directions to politicians how law
should look like (Bundesverfassungsgericht - Federal Court of Constitution?).

> > > TRIPS demands patents in all fields of technology. Excluding
> > > software-based implementations from patent protection violates TRIPS.
> > 
> > What is a "software-based implementation"?  I don't know that term, if you
> > could please define it, thank you.
> 
> Sorry, I meant software-based inventions. I.e. inventions which
> can be at least partially realized using software.

Can you give an example?  I think it is crucial to find out if the invention
is in the software or in the hardware.  If it is just some new hardware
invention with some software (inventive or conventional) slabbed to it, I
have no concerns.  If it is software with just some "technical vocabulary"
slabbed to it, to make it look more technical, I have a fundamental
objection.

> > Computer programming is not a field of technology.  Just as math isn't.
> 
> Programming is applied mathematics, just like engineering
> is applied physics. Applied sciences are patentable subject matter.

Irregardless of whether programming is applied math, I have never heard
before that all applied sciences are patentable subject matter.  I think
you just made that up.

> > Then please quote such patent claims which you think should granted.
> > For now, I am happy to leave the interpretation of "technical effect"
> > completely up to you, and exercise scrutiny only on the examples you will
> > come up with.
> 
> I've got a list of examples at
> http://www.iusmentis.com/patents/businessmethods/epoexamples/
> Not all of them really establish a technical effect, which IMO
> illustrates how difficult it is to define this properly.

Ok, thanks.  Those example give me indeed a very good idea what we are
talking about.  I am not going to even try to read the claims of these
patents, but the one line summary is interesting and probably enough to keep
the discussion forward.

> Technical effects:
> Reducing the bandwidth between clients and servers: EP 407 026
> 
> Using a second, separate channel to authenticate someone
> makes a system more secure: EP 416 482
> 
> Avoiding the need for storage on a client system in a Web
> shopping system: EP 784 279

The above sound just like what we call "software patents", ie, patents on a
program as such, rather than a technical invention that teaches us more
about the forces of nature.

> Integrating a PIN card and a SIM card in a single device: EP 929 880

This is too unspecific to tell about, and following the patent link requires
javascript (which lynx doesn't support).  So let's leave it out.
 
> Keep in mind "technical effect" means something is an invention,
> even though the solution may be obvious.

According to the EPO, but I claim that this is not supported by law.

> For example, using an
> out-of-band channel to receive a password is a technique that's
> known per se. But it achieves the technical effect of making
> the system more secure. The invention would probably be obvious,
> unless they were the first to come up with the concept of
> out-of-band channels.
>
> Some more examples. Saving memory, increasing speed, improving
> security, operating a user interface (T 236/91, T 59/93), configuring
> the operating system (T 265/92), coordinating and controlling
> internal data (T 6/83), or assisting in solving diagnostic problems
> in data communication (T 216/89) all are technical.

If saving memory is a technical effect, then it's not a far step (certainly
only an argumentative step) to either accept that all programs have a
technical effect, or that you can every program technical by applying it to
some specific technical problem (I guess every patent attorney who is worth
his money is able to do so easily).  This is exactly what I said above: the
distinction isn't a distinction.  All programs are either programs as such
or programs with a technical effect or both.

Which is exactly why we have to reject software patents, because then the
conclusions from the Dispositionsprogramm come true that everything that is
thinkable is patentable.  This is the big threat that we have to prevent
from becoming real _and_ codified in european law.

Or to make it more specific:  Saving memory is just the consequence of
increasing the information density, or packing more information into less
bits.  That is also called compression.  And information theory, in which
compression algorithms live, is math.

Likewise for out-of-band channels.  Channels are just transports.  Using an
extra channel is nothing that tells us more about the forces of nature.  It
is a purely abstract and logical construct with certain properties.  One
property is that using out of band channels is separating information into
different separated streams.  Everyone can come to that conclusion just by
applying logic (well, perhaps everyone except AT&T which needed years to
figure it out that they should probably use an out-of-band channel in their
public phone system :).  These are called logic patents, and even further
illustrate the danger of software patents to restrict personal freedom.

> Processing physical data is technical. Physical data may be, for
> example, data representing an image (T 208/84) or data representing
> parameters and control values of an industrial process (T 26/86).
> However, monetary values (T 953/94), business data (T 790/92) and
> text (T 38/86) are not physical data. 

This is even scarier, and if you can write the above pargraph with a serious
face you are probably lost to the pro-software-patent lobby and need to be
rescued :).

Basically, what you just wrote is that a compression algorithm is technical
if it is applied to an image and it is not technical if it is applied to
text.  I am throwing my hands up in despair.  I have nothing to counter that
argument, except to reject the very idea of a compression algorith _ever_ to
be technical.
 
> [T = EPO Board of Appeals decision]
> 
> >   I suspect that the reasons pro-software-patent people don't
> > come up with examples is that they really want unlimited patentability, and
> > don't want to limit themselves to a certain set of examples (nor release
> > their true intentions).
> 
> That is not fair, you don't know anything about me yet you
> presume to know what I am after or why I am discussing this.
> I can say all kinds of nasty allegations about you too, but
> I don't. Let's keep it polite, please?

Sorry, no that is not what I meant.  I didn't really think that you are a
pro-software-patent person.  You might be, but you never said that, so I
certainly don't assume it.  You could just be playing devil's advocate, and
it would be all the same for me :)

However, I hope you are against software patents, and that you help us to
fight them, because they are harmful for our economy and personal freedom of
expression.

[invalid patents]
> I am not so sure anymore I understand the point we're arguing
> here.

Yeah, reading back the thread I can see how the discussion got side tracked,
so I am dropping it here.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus at gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/



More information about the Discussion mailing list