From phm@a2e.de  Tue Aug 14 18:00:09 2001
From: phm@a2e.de (PILCH Hartmut)
Date: Tue, 14 Aug 2001 19:00:09 +0200 (CEST)
Subject: [Patents] Re: EPO 1978: programs vs inventions (fwd)
Message-ID: <Pine.LNX.4.31.0108141855510.7914-100000@querty.oas.a2e.de>

---------- Forwarded message ----------
From: PILCH Hartmut <phm@a2e.de>
Subject: Re: EPO 1978: programs vs inventions
To: intprop-l@topica.com

Paul E. Geller wrote:

> > Of course a computer program can describe an inventive chemical teaching.
> > But then the invention consists in a reaction, not in a program.

> 	Now, finally, some syntactic clarification which, hopefully,
> should focus discussion.  Please, everyone, note the distinction between
> program as means of implementing the invention and the invention itself,
> that is, that for which utility or industrial application is claimed.

If this distinction is to be more than a verbal smokescreen, you need a
concept of "technical invention" like that of the BGH, i.e.

	teaching on how to use controllable natural forces to achieve a
	causally overseeable success which is, without intervention of
	human reasoning, the direct result of natural forces

	(BGH Dispositionsprogramm, Walzstabteilung, Antiblockiersystem etc)

A chemical reaction is such an invention, because its effect is directly
achieved by the natural forces: if you remove the chemical, there is no
success.

A system for splitting rolling rods (Walzstabteilung) is not an invention,
because the effect is achieved by human reasoning (calculation according
to a mathematical formula), the finished result of which is then fed into
an already known construction that involves natural forces.

Another way to approach it is to divide the problem into an abstract and a
concrete layer (idea and materialisation) and then check whether the
concrete layer (i.e. the invention) is new, non-obvious and useful.

E.g. the abstract layer could be the computer program that controls the
chemical reaction.  The concrete layer would be the reaction itself.  In
another example the abstract layer was a construction plan for a ship and
the concrete layer the ship itself.  The patentee tried to sue a company
for selling ship construction plans that make use of his idea, but this
was rejected by a court in Hamburg.  In the same way, computer programs,
even those for an ABS or for controlling a chemical reaction, are as such
not patentable, but the concrete process (materialisation) they describe
(ABS or the chemical reaction) could qualify for a patent, if it is new
and non-obvious.

> 	[...]
> > And to Greg: Any real or alleged difficulties in defining such a
> > borderline are not a valid excuse for not defining that borderline.
> 	[...]
> 	This is why, in all law, not just patent law, the crunch comes in
> the (hard) cases: our notions are all more or less open-ended -- more or
> less _unbestimmte Rechtsbegriffe_.  Hence the questions that transcend,
> but implicate, patent law: How much to try to spell out in legislation?
> (How much, in patent law, to specify in the middle zone of administrative
> guidelines for examiners?) And how much to leave to the judges?

Indeed the current EPC regulation struck quite a good balance by choosing
a "Ten Exclusions" (cf Ten Commandments) scheme that, one should think,
makes things clear by means of persistent examples, while allowing the
theoretic underpinning of the "technical invention" to survive the epochs
and adapt to paradigm shifts.

> 	(Marek's contribution today should set to rest any illusion that
> this distinction is not fully operative in the civil law.  Hartmut's
> response to Marek contradicts his own syntactic insight quoted above: the
> issue is not software, but what any specific program implements.

I still think that judges in Europe are not entitled to interpret the law
in a way that de facto makes programs patentable.

They could be entitled to do that, if the law itself had, through changes
in the legal underpinnings or in the technological reality, become
contradictory or otherwise unapplicable.  But this is not the case and all
pretenses made to this extent were just repetitions of old patent lawyer
junk talk from the 60s such as "software becoming more and more important
and therefore needing more and more protection", i.e., in the words of the
German constitutional court (BVerfG), mere individual political value
choices (rechtspolitische Vorstellungen) which judges are not allowed to
impose on the public when the legislator has made other choices.

> Yes,
> Patrizio, I am making these comments from a comparative background, albeit
> in the field of copyright -- close enough, I think ....  Which brings me
> to Jozef's question: What to do about program structures that do not
> implement any "invention"?  Copyright is helpful only to a point, but not
> in hard cases.  Perhaps, there is a gap here calling for legislation ....)

Not everything that is not ownable needs to be made ownable. Moreover,
whether those desires that copyright leaves unsatisfied can be satisfied
by patents is largely a question of luck.  Most can't. The only reason
that patents entered this game seems to be that they have a powerful
seductive bandwagon carrying them.

--
Hartmut Pilch                                           http://phm.ffii.org/
Protecting Innovation against Patent Inflation	      http://swpat.ffii.org/
85000 signatures against software patents         http://www.noepatents.org/

==^================================================================
EASY UNSUBSCRIBE click here: http://topica.com/u/?aVxiHs.a2jybo
Or send an email To: intprop-l-unsubscribe@topica.com
This email was sent to: phm@a2e.de

T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================





