That anti-patent pamphlet I mentioned

Sun Dec 15 16:11:59 UTC 2002

On Sun, Dec 15, 2002 at 03:57:18PM +0100, Arnoud Galactus Engelfriet wrote:
> Marcus Brinkmann wrote:
> > I say that either the following two is true:
> > 
> > 1. Every program has a technical effect if it is run on hardware.
> 
> This is true. That's why the EPO came up with the "further
> technical effect". Maybe we should define "technical effect"
> as "the effect you'd get if you built the software in
> equivalent hardware instead". Then it does not matter anymore
> how the invention is realized, and you simply look what it
> does and what that achieves.

I have no problem with people patenting hardware that does a similar job to
some program.  I have a problem with people patenting software, irregardless
of what it does.

> > > Article 52(1) says
> > > 
> > > European patents shall be granted for any inventions which are
> > > susceptible of industrial application, which are new and which
> > > involve an inventive step.
> > 
> > When I say invention in this discussion, I usually mean invention as in this
> > definition, which means that it always includes an inventive step (is new,
> > technical, and industrially applicable).
> 
> Ok. So if I have something that is an obvious modification of
> an existing device, you would say it is not an invention. Right?

I might say it is an invention, but not an invention in the sense of Art
52(1).

> This may be the cause of a lot of confusion, because in my
> opinion it is an invention, although an obvious one. That's
> how I read the EPC: "patents shall be granted for inventions
> which ... involve an inventive step". This admits there are
> inventions which do not involve an inventive step.

I realized that you use the term invention in the general sense, and not in
the specific sense of the patent law.  Otherwise a sentence like "an
invention must have an inventive step" doesn't make much sense at all (it
would be completely redundant).  I don't think any fundamental disagreement
between you and me in this thread is explainable by that difference of word
usage.

> > > I think it is totally irrelevant whether the inventive aspect
> > > is in software or hardware. 
> > 
> > Then indeed you are very much in line with the EPO, and clearly against the
> > written law.  Which explains the whole discussion.
> 
> I disagree with your interpretation of the EPC, and I
> disagree with your observation that my interpretation is
> "clearly" wrong. It's a different interpretation, and one
> which leads to results you don't like, but that does not 
> automatically make me "clearly" wrong.

There is not much room for interpretation.  If the EPO wouldn't be painfully
aware of the fact that its current practice is against the current law, it
would not pressure so much for having the law changed to adapt to current
practice.

> > > Let's say I have a car engine in which fuel injection is regulated by
> > > a valve coupled to a sensor. This way the car engine operates with a
> > > certain efficiency, because the signal from the sensor can open and
> > > close the valve. The inventive aspect is in the use of the valve and
> > > sensor. Is this an invention? I would say yes. And if the prior art
> > > does not teach using valves and sensors to regulate fuel injection,
> > > then the invention is not obvious and hence involves an inventive
> > > step.
> > 
> > This is way too vague to say if it is an invention or not.  But if there is
> > something new to be learned about the forces of nature in the valves, or the
> > mechanics of the sensor, I will pay fair and say, yeah, there is an
> > invention according to 52(1).  For the sake of argument anyway.
> 
> Ok, so you combine the evaluation of inventive step and
> the determination whether it is an invention. Is it possible
> that the mechanics of sensor and valve do teach us something new
> about forces of nature, but their application in a fuel
> injection system is obvious?

As long as we learn something new about the forces of nature, and it is
industrially applicable, and it is not obvious, it is a technical invention. 
Irregardless of where it can be applied obviously or not (fuel injection,
soft drink injection, or whatever :)

> > So, as long as there is no invention in the mechanical glue between the chip
> > and the sensor, or the chip and the valve, then there is no invention here
> > that deserves or needs the protection of a patent.  
> 
> Your approach is clear, although I find it interesting to see
> that apparently it does not matter what forces are manipulated
> or what this manipulation achieves. If the manipulation occurs
> in software, it's not an invention, if it occurs in hardware it
> is an invention.

Forces of nature are not directly manipulated in software.  Never.  This is
downright impossible, as software is not something that exists as a motor
exists.  In its purest form it only exists in the world of ideas, and in the
real world in only exists as a representation (as a program text, or as bits
and bytes on a volatile or permanent memory).  There is always a technical device
that receives electrical input (like a motor), that does the mainpulation.

This is the technical border.  If you extend patentability beyond this
border, you will always have the problem that everything becomes patentable
in consequence (and the self-restriction to things with "further technical
effect" is arbitrary and can be defined by the EPO at will, as it really
includes everything).

> > I know that it is current practice to allow such patents.  And I know that
> > 1978, such patent claims have been denied.  The law is clear on the 1978
> > side.
> 
> It is current practice to allow such patents. Back in 1978, such
> claims would have been denied. But today we have a much more fair
> and consistent interpretation of the law.
> 
> Should we keep on repeating our assertions of how the law is
> supposed to be interpreted? I don't think either of us has any
> arguments the other is prepared to accept, because we're coming
> from totally different starting points.

The problem is that you argue in terms that are completely arbitrary and can
be bended at will.  It is clear to me that it is always hard to
counter-argue such situations with ration and well definedness, simply
because there is no way to counter a contradiction except by two things:

1. I can show that you can follow everything from a contradiction (ie,
   everything is patentable in your interpretation)
2. I can offer a different interpretation that really is fair and consistent
   in that it offers a real limitation to the patent system, and I can show
   that this interpretation is much better suited for our economic world.

The two together: the logical aspect, and the economic aspect, are enough to
make any discussion about what "technical effect" might mean downright
irrelevant.  This is why at the start of this thread I rejected the trickery
terms and said that they are a trap:  They are designed to get lost in
arbitrariness and ambiguity.  I continued the discussion anyway to mainly
shape my own argumentation techniques, but also because I think that such
positions can not be left in the room without showing their fallacy.

> > > The image would be a representation of reality. For example
> > > taking an X-ray picture or compressing video. Then you are
> > > manipulating (representations of) light rays or electro-
> > > magnetic signals. That's technical.
> > 
> > So a digital image of an x-ray is technical, but a digital image of an
> > elephant is what, animal? 
> 
> They're technical data if it can be shown the machine operates
> in a technically different way based on it.

This is potentially true for every data.  Is this really what you want?

> A digital photo camera is an invention, is it not? 

It can be an invention.  The pictures it takes can not.

> > And a digital image of a nun feeding a hungry
> > child is human?  And, sorry, but I can not resist, a digital image of the
> > excrements of a male cow is?
> 
> They're all data. In a face recognition system, the data would
> be processed to make the system e.g. grant access or something,
> and then the system operates influenced by the data. That would
> make system+data technical.

You avoid the question:  Can data be technical?  Above you say yes.  You
even offer a definition that makes all data technical, and thus patentable.
A direct consequence of what you say is that a picture of an elephant is
patentable.  A picture that exhibits a "further technical effect" on a
machine would be patentable.

You are showing us a world where music, art, pictures, text, literally
everything can be patented.  It is a world of horror.

> > realize that, too.  But you have not said how you want to stop the EPO from
> > granting patents on things you don't consider to have a technical effect,
> > but the EPO does.
> 
> How can I possibly do that? In fact, how would you want to stop the
> EPO from granting patents on things you think do not involve novel
> application of forces of nature, but they do?

By reinforcing a law that clearly defines what is patentable and what not,
and by better controlling the patent office that it does what it is allowed
to do and not mroe.

> The Japanese patent
> office apparently can find reasoning that computer programs are
> technical ideas by which a law of nature is utilized. If the Japanese
> Supreme Court affirms that, what can you do?

If this happens, it is the politician's call to make the law clearer to the
patent office.

> > > I think I disagree with your definition of 'software patent'
> > > because, as a computer scientist, I am unable to think of any
> > > reasonable definition of 'software'. It is function that
> > > matters. Implementation of the function is irrelevant.
> > 
> > If you don't like software patent, say "logic patent".  It means the same
> > thing here.
> 
> Fine. I'll use "computer-implemented invention" to refer to
> things that use software, and "logic patent" for things that
> involve no (further) technical effect.

There is no difference.

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/