[%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 == 'PILCH Hartmut phm@a2e.de' || is_owner %074db819ec) (074db819ec% END %074db819ec)
(074db819ec% END %074db819ec)

> You explain nothing here.  Amazon's one click is a lousy example to use
> to justify software patents.  Consider instead, natural language
> translation, a software problem that has yet to be solved after forty
> years of research.  People have invested (i.e. risked) lots of time
> and money, with few useful results.  So if someone new decided to take
> another crack at the problem, and spend lots of money and time, it is
> no less a risky and time consuming effort than any hardware design
> problem.  So stop attacking all software patents by pointing to some of
> the more obvious and simple patents such as Amazon's 1-click, or my
> favorite, a 1996 US software patent for nothing more than 3D pie charts.
> There are many software problems as intellectually difficult and time
> consuming to solve as hardware problems.  

and in that case very well protected by copyright.
Usually it is not a matter of finding a certain principle. 

> And there are many stupid mechanical and hardware patents being issued
> as well - should all mechanical and hardware patents be rejected
> because of the stupid ones?

We do not reject logical patents because there are a few particularly
stupid ones.
Why do you keep warming this up again and again?
 
> >The act of "building the factory" entails risk to the factory builder
> >and, when successful, benefits society by creating the knowledge that
> >it can be done.
> 
> Again, overly simplistic.  Increasingly many people designing mechanical
> products just spec out some design on a CAD tool, and send the CAD files
> to a factory to have them built.  The only risk is the time spent on
> developing the product with a CAD program, and then marketing the hardware
> product.  

All that John said is that even with your "co-design tools" or CAD tools,
there is still a certain risk left that your innovation may work only in a
simulated world but not in a real world.  And that risk is the only
justification for possibly considering your calcualtion a patentable
invention.  If that risk is so low as you say, than anything that is found
out by co-design tools is a logical innovation, or call it a software
patent.

> Which to me is little different than someone using a CASE
> program to develop some software, and then having to figure out how to
> market it.  You guys worship the physical way too much - it clouds your
> logic.  Go take a look at some of the latest mechanical CAD tools -
> using them is little different than programming software - just lots of
> manipulations using a computer program.  Little risk, little sweat.

All we state is that the distinction between physical and logical works
well and can be applied as a criterion.  A much sharper criterion than the
"novelty" criterion which Greg A seems to be worshipping way too much.
 
> Hartmut writes:
> 
> >Right:  an invention consists of three parts:
> >     1 real world problem (involving physical objects)
> >     2 model of real world (knowledge of natural forces)
> >     3 algorithm      
> >
> >The novel part in a true invention must lie in 2.
> >Part 3 can be found automatically by artificial intelligence / artificial
> >life.
> >
> >Part 1 can be difficult to find and formulate correctly.  But monopolising
> >part 1 boils down to monopolising "the idea of trapping mice".
> 
> I disagree.  The novelty part in not in part 2, because just like you
> claim part 3 can be found be AI, so too can part 2 be found using AI.

If it can be found by AI, then it is not new real-world knowledge but
already contained in previous real-world knowledge.  The part that can be
found by AI is, by definition, part 3.

> I can present digital circuit problems, even simple ones, that most
> humans could not solve in a reasonable amount of time.  But by defining
> the basic laws of Boolean logic to a certain AI problem, I can get the
> AI problem to prove that digital circuit problem is solvable, and part
> of the computer generated proof is the actual digital circuit.  Given
> a big enough computer to handle large LISP executions, I can do this
> for any digital hardware problem that has to be solved.  

So you have conclusively explained that your solution to digital circuit
problems is not based on any new empirical knowledge and therefore belongs
to the realm of what we could call "software patents" or at least "logical
innovations".
 
> So to me, for both hardware and software, you have a human using a
> variety of computer tools to help him solve a problem.  The solution is
> worthy of patent protection, independent of whether or not the embodiment
> is in hardware or software, or a combination of the two.

Again you just reiterate.
How many times to I have to answer that we are not talking about "hardware
vs software" here.
Do you lack the understanding or the good will?
 
> >Software patents like the IBM patent on "a way of finding faulty strings
> >in a text" usually come very close to claiming a problem.  Software is
> >about abstraction, and this eventually means abstracting from the solution
> >to the problem.
> 
> And increasingly, this is true for hardware, both digital and mechanical,
> as it is for software.  Thus increasingly, you can be for or against
> patents in general, but you cannot discriminate between types of patents.

We have shown in all the above examples that we can clearly discriminate.
And anyway you have to, or would you accept a patent on a new legal
concept?  If not, why?

> I sense that many of you here are against all patents in general.

I just sense that Greg Aharonian wants everything to be patentable and
deliberately tries to deny the feasibility of distinctions.

> I suggest some of you research the latest mechanical engineering
> design tools, where someone can describe problem and the computer
> optimizes the physical design.

Again these design tools apparently are simulation tools, based on an
existing model of the physical world.  Any solution found by such a tool
is a logical solution, i.e. a pure algorithm not based on a new model of
the physical world.

 
> Edward Avis writes:
 
> >So I could protect my program, which is an implementation in C of a
> >particular sorting algorithm.  But I couldn't stop others from making
> >their own inventions based on the same algorithm.  This is exactly what
> >copyright on computer programs achieves.
 
> And that is why people are increasingly abandoning copyright
> protection for software - because it gives no protection, 

FUD of the 70s, when lawyers didn't yet know the distinction between
source and binary code and the speed of the software business.

> and turning to patent protection.

They are turning to patent "protection" simply, because others are doing
the same and you need to stockpile arms.

> If I invent a new sorting algorithm, and can't control how others
> exploit it with copyright protection, I will either get a patent or
> not disclose my sorting algorithm (except for those many programmers
> who voluntarily disclose new algorithms for everyone to use, which is
> nice but their choice).

Inventing such algorithms isn't so difficult that thinking about
"protection" is really worthwhile.  By being productive, you can live
quite well in the software business anyway.

Not disclosing is just the normal way to make use of copyright.
And it is very profitable.
But even if you do disclose, developping software can still be profitable.

> Increasingly copyright is becoming absolutely useless to protect
> software - it is not an alternative to patent protection. This is part
> of the reason for the explosion of software patents in the US, and for
> the coming explosion in Europe - that people realize that copyright
> protection for software is increasingly useless. Better to fix the
> patent examination process, a solvable problem, that trying to
> convince people to give up patents.

Again you are reiterating the same old stuff over and over again.
I responded several times why "fixing" the patent system won't help.
You failed to refute my arguments and bring up the same already refuted
onese again.
This is really a kind of spamming.
 
> (And Hartmut, stop calling EPO types "evil" and other insulting phrases.
> It makes it that much easier for them to ignore all of your arguments.)

I might soon use those phrases on you as well.
Your argumentation tactics is not honest.
 
> >Unless you want to allow mathematics to be patentable also.  That may
> >happen sooner than you think; since a computer program is equivalent to
> >a mathematical proof, patentability for one would lead to patentability
> >for the other.  I can just imagine all the patent lobbyists complaining
> >of the inconsistency that a computer program can be patented but pure
> >mathematics cannot...
> 
> And they should complain - it is inconsistent.  And not only for software.
> Increasingly there are many mechanical and hardware designs that are
> equivalent to mathematical proofs (if you are knowledgeable about the
> latest AI mechanical CAD systems - which apparently many of you aren't).
> So if you reject software patents because some of them are logically
> equivalent to a mathemtical proof, then you have to reject mechanical
> and hardware patents as well because some of them are logically equivalent
> to a mathematical proof as well.

We'd just have to reject some of them, as I said.
Those based on an existing calculational model.
 
> Which I suspect some of you want to do - not to get rid of just software
> patents, but all patents.

Again old FUD, refuted several times and reiterated by Greg again and
again.  Why this unwillingness to learn?   

-phm








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

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