[%TAGS (074db819ec% %074db819ec) %]
(074db819ec% IF user.email && action == 'arc' %074db819ec)
(074db819ec% END %074db819ec)
- From: srctran@world.std.com (Gregory Aharonian)
- Subject: [Patents] More on why business methods are technical (fwd)
- Date: Sat, 3 Nov 2001 12:12:51 -0500 (EST)
I agree with Hartmut that there is one key essential argument behind all
of these discussions on the patenting of software, hardware, business
methods, genetics, etc. The key issue is in Hartmut's words, this idea
of "controllable physical forces", or my preference, "patenting
non-physical processes". This issue is what is underneath the partially
thought out semantics of the EPO's Pension Patent decision - that
business methods don't achieve a technical effect - with one view of
technical effect being a physical result in the claimed process.
Thus the question - "Should non-physical processes be patented"? In
America, while it has taking time to clarify the thinking, the answer
for over 100 years has been YES, starting with the words of our Supreme
Court in the late 1800s cases involving the early telephone and telegraph.
The State Street and ATT/Excel cases pretty much settle the issue -
business methods (whatever they are) are patentable.
Thus the question - "Should non-physical processes be patented?" is of
interest for two reasons. First, how will Europe answer the question
(since Asia [Japan, Australia] seems to be answering the question YES
following the US logic)? Second, if Europe answers NO (i.e. retaining
the "computer program" and "business method" exceptions in EPC 52.2),
which answer, YES or NO, will prevail when someone files a protest under
TRIPS.
How you answer the question depends on your view of the evolution of
society and laws. Hartmut prefers to stay in the past, when most
inventions and case law was grounded in "physical" inventions, such as
those traditionally thought of as mechanical. This was a time when such
inventions made up a large part of the economy, and therefore not
surprisingly were the basis for much case law for patenting. For
example, about 20 years ago in the United States, half of all patents
were mechanical, 35% chemical and 15% electrical. Going back further I
suspect even more patents were mechanical and less electrical (the
electrical being where the boundary blurs between physical and
non-physical).
However, presently about 30% of US patents are mechanical, 35% chemical
and 35% electrical (and I suspect similar percentages hold up around
the world). We see clearly that the role of the mechanical, the
physical, is diminishing in importance to the economy. Indeed, daily
we are flooded with talk of the global information economy, the global
service economy, etc. I wouldn't be surprised one day to learn that the
farms of America, farming being very mechanical and physical, were being
run by one human and a large number of computerized machines.
So the dilemma is this - to we allow the patent system to evolve to handle
the types of processes, in this case "non-physical", that are becoming the
predominate part of the economy, or argue as a fundamentalist - that the
patent system was spawned in a mechanical/physical world, and should never
evolve?
This is the fundamental question, once you filter out the rhetoric. And
it is here that Hartmut and I disagree. I say YES, the patent system
should be allowed to evolve to handle non-physical processes such as
software and business methods, because the patent system is the best way
to describe such processes for public knowledge and setting boundaries.
Hartmut says NO, either suggesting that software and business methods
get no protection, or that we rely on copyright, and repeatedly citing
old German case law grounded in the physical/mechanical.
I doubt anything Hartmut says will convince me to abandon my position,
and I doubt anything I way will convince Hartmut to abandon his position.
The question for the rest of Europe is which position makes most sense
for the European economy.
Greg Aharonian
(074db819ec%|loc%074db819ec)Archive powered by(074db819ec%END%074db819ec) MhonArc 2.6.16.
(074db819ec%TAGS [% %]%074db819ec)