[%TAGS (074db819ec% %074db819ec) %]

(074db819ec% subtitle %074db819ec)


(074db819ec%|loc%074db819ec)chronological(074db819ec% END %074db819ec) (074db819ec%|loc%074db819ec)Thread(074db819ec% END %074db819ec) 
(074db819ec% IF user.email && action == 'arc' %074db819ec)
(074db819ec%|loc%074db819ec)Reply to sender(074db819ec%END%074db819ec) (074db819ec%|loc%074db819ec)to list(074db819ec%END%074db819ec)

(074db819ec% IF user.email == 'Gregory Aharonian srctran@world.std.com' || is_owner %074db819ec) (074db819ec% END %074db819ec)
(074db819ec% END %074db819ec)

Hartmut's proposal contains the following phrase arguing against
"non-technical" computer programs (a concept that has no meaning
in America):
    I.e, the solution of the problem must lie in a technical realm
    beyond the realm of programming, and the exclusion rights
    derived therefrom must be directed to material objects outside
    of the program, such as e.g., chemicals or automobile engines.

Reading this, I conclude that Hartmut's proposal would ban a 
patent on a new sorting algorithm by itself, but not a new sorting
algorithm applied to a chemical process or automobile engine control.
The sorting algorithm by itself, I understand from Hartmut's words,
is solely within the realm of programming, and therefore not
patentable.

If indeed that is Hartmut's view and proposal, then I argue that it
is both a scientifically inefficient philosophy for patenting, and
a patent law argument that failed in the United States.

Why is it scientifically inefficient?  When someone comes up with a
new algorithm, such as a new sorting algorithm, I as a scientist or
engineer could care less about its applications.  Finding applications
is easy.  All I am interested, when reading the patent specification
for the new algorithm, is understanding what the algorithm is doing.

What I don't want to see is lots of trivial paragraphs along the
lines of "With this new algorithm, one can better control any
chemical progress that uses this type of algorithm, one can better
control any automobile engine that uses this type of algorithm, one
can better control any electrical circuit that implements sorting
in hardware", blahblahblahblahblah.  Adding such examples of how
to use the algorithm outside the realm of programming is just plain
inefficient.  Most scientists and engineers are smart enough to
figure out how to do so themselves, and don't want to see a lot of
paper wasted with obvious uses of the new algorithm.

So Hartmut's proposal sounds like a lawyer's dream - to get a
software patent, you have to fill your patent application with
pages of examples of uses outside the realm of programming, which
doesn't nothing to help others understand the algorithm or apply
it themselves.  All it does is cause patent applicants to have to
make their disclosures much longer than necessary (thus the
scientific inefficiency), pay more money to their lawyers (thus
economic inefficiency), and waste more paper (thus ecological
inefficiency).

These same arguments occurred years ago in the United States (in
fact, most of the discussions going on in Europe now about software
patents went on in the US courts from the late 1980s to the late
1990s - and the outcome will be the same).  People argued that
computer programs by themselves were pretty much math equations
within the "realm of programming" (I prefer the realm of Guiness
Stout).  The courts shot down most of this logic, and the lawyers
just added useless real world examples (and irrelevant descriptions
of hardware to the claims) to the specifications to satisfy the
courts' rulings and the wishes of people like Hartmut to make sure
software patents have a real world focus.

In the end, the software patents still issued, though at a greater
cost to patent applicants.  And much like in Europe, while everyone
was arguing these philosophical issues, no attention was made to
improving the examination process (in particular searching) so that
all of the idiotic types of software patents we all hate wouldn't
issue.

Greg Aharonian







(074db819ec%|loc%074db819ec)Archive powered by(074db819ec%END%074db819ec) MhonArc 2.6.16.

(074db819ec%TAGS [% %]%074db819ec)