Re: Another strawman for equal hardware and software patentability

[PILCH Hartmut <phm@a2e.de>]

Like the text of Varian and Shapiro which Greg posted recently, this one
also is not about patentability.  The author says basically that one
should try to abstract as far as possible and not solve problems at the
physical level when they can be solved at the logical level.

Any solution at the logical level is a software solution, not a technical
invention.  And any logical/software solution is implemented by hardware
(which should be irrelevant for the patent application, because it is not
part of the solution).

> A nice commentary in the 2 September 2000 issue of Electronic Engineering
> Times, page 55, makes a good case that the boundaries between hardware
> and software design are very ill-defined. It is just as ill-defined then
> to treat the patenting of hardware and software differently.  The author
> is CEO of a company that makes hardware design tools (and by CEO I mean
> a German who actually creates jobs and pays taxes on profits).

Aha, Greg's definition of "CEO": "a German who creates jobs and pays taxes"

Probably meant to insinuate something along the lines of "those who earn
patent license fees create jobs and pay taxes and should therefore get to
decide about software patentability".

> Indeed, on the same page is an article about a German company, Infineon,
> titled "How Infineon turned standard product into IP", with this as the
> first paragraph:
>             As system implementation move to higher levels of
>             integration, conventional semiconductor companies
>             are finding that the real value of their standard
>             product portfolio lies not in chip sales but in
>             the ability to license their designs as reusable
>             intellectual property.
>
> Greg Aharonian
>                               ====================

Is EET a patent/licensing journal?

> Thinking about hardware versus software is riddled with discrepancies
> by Axel Thillmann (CEO, Nolivit Inc.)
>
> There seems to be a notion in electronics design that software is easy
> and hardware is hard, as if the words "software" and "hardware" were
> self-fulfilling prophecies.  But it's not clear why one should be easier
> than the other.
>
> Actually, hardware is probably easier, in that it is extremely logical,
> like any mathematical formula.

That sentence sounds absurd.  Of course you always can abstract from
hardware.  Then you may get something logical, i.e. software.

See also Stallman's quote on

        http://swpat.ffii.org/archive/quotes/

about the quirkiness of hardware.  It puts the difference quite nicely.

But interestingly enough Thillmann takes "logicalness" as a criterion of
simplicity.

> Software, on the other hand, often does not follow the same
> constraints.  Not that it couldn't; but historically, it doesn't.

Maybe he means that hardware is constrained by the need to be simple while
software can be incredibly wild-grown and complex.  Complexity means that
it consists of many ideas which are potentially patentable one by one.  A
reason why patents are inappropriate.

> What, really, is hardware?  Traditionally, hardware was where components
> were soldered onto a PC board, but today hardware design involves a
> textual description of the physical problem.

OK, then we are probably talking about software which is transformed into
hardware by some already known automatic mechanism.  The only difference
between this software and more usual software is that the medium in which
the information is stored (i.e. the produced hardware) cannot be directly
copied.

> Software is one layer further removed from the direct operations of the
> hardware.  Firmware is an odd animal, in which the software is somewhat
> more hardened, but not hard enough to be called hardware.  Firmware,
> typically used in embedded processors, is software that works closely
> with hardware.  Firmware can be something loaded at startup into a
> particular memory area, but you could also have firmware stored
> pernamently in a flash memory or an EPROM - it doesn't matter at a
> high level.

Indeed the "hardware" which the author describes is an "odd animal, in
which the software is even more hardened that in the case of firmware".

> In all three [hardware, firmware, software], we are actually looking at
> code as a textual representation.  So from a theoretical standpoint,
> everything is code, and there is little difference among hardware,
> software and firmware.
>
>     [Greg note: key point - and therefore shouldn't the patentability
>     of all three have little difference - such as no difference?]

Such as not allowing patentability of any of these three forms of
software?

As said many times, patents are not granted for hardware but for
inventions.

If the solution is in the realm of logics, it is not a technical
invention.

> It would benefit all designers to train themselves to think at higher
> levels of abstraction.  Abstraction is not always a way to cut time;
> abstraction may be the only means to solve a problem, as many examples
> in mathematics have proven.
>
> To ease the perception of hardware versus software, we propose a new
> abstraction layer for the communications industry, in particular. Then
> it would be irrelevant whether the final target is hardware or
> software, because the designer could capture just the design intent,
> and let the technology resolve whether the implementation is to be
> done in hardware, software or firmware.

What is new about this proposal?
Isn't that what people have been doing all the time since the ancient
Greeks?
Does this CEO perhaps want a patent on the very method of abstraction?

>     [Greg note: and it would be unreasonable to have this implementation
>     choice be influenced by the knowledge that some choices would be
>     patentable, and others not patentable.]

Maybe unreasonable according to some irrelevant standards of patent law
aesthetics.  Not unreasonable from a practical point of view.  E.g.
patents make more sense economically in the case of hardware MP3 players
than of software MP3 players.   That doesn't mean that we need them for
either.

> Ideally, the partitioning between various implementations should be done
> under user control at the specification level.  An engineer should be
> able to direct a design into hardware, firmware and software without
> making these decisions up front, as is required under conventional
> methods.  In that way, the solution should easily be able to fulfill
> the speed and area requirements and reduce design complexity by an
> order of magnitude compared with lower-level implementation techniques.

Some patent experts are keen on pushing the patent system into a conflict
which is likely to end with the abolition of the patent system.

The basic method for this is to consistently ignore basic philosophical
formation (particularly in the philosophy of science)  and then adorn this
ignorance with quotations from interesting but unrelated articles or
persons of authority, e.g. Einstein, Turing, Hawkings etc.  Greg does this
in a way that is sometimes even clever and entertaining.  And there seem
to be enough people in the patent profession who are seduced by it.

See more about Greg's method on

        http://swpat.ffii.org/players/aharonian/

To be updated.

-- 
Hartmut Pilch, FFII & Eurolinux Alliance              tel. +49-89-12789608
Protecting Innovation against Patent Inflation       http://swpat.ffii.org/
120,000 signatures against software patents      http://www.noepatents.org/