[%TAGS (074db819ec% %074db819ec) %]
(074db819ec% IF user.email && action == 'arc' %074db819ec)
(074db819ec% END %074db819ec)
- From: Hartmut Pilch <phm@a2e.de>
- To: patents@aful.org
- Subject: GregNews: "The growing blur of hardware and software"
- Date: Mon, 8 Dec 2003 13:56:04 +0100 (CET)
Another piece or G.A.'s well-known blur rhetoric, using favorite words
such as "growing", "increasing" etc, posturing as a pundit of the latest
mysterious developments in rocket science and nuclear physics etc, see
http://swpat.ffii.org/players/aharonian/
this time designed specifically for lobbying the European Parliament.
Note that "Marshall Phelps", "IP leader of Microsoft", also announced
recently announced that the focus of their campaign should be on getting
MEPs to understand "that there is no difference between software and
hardware".
===8<==============Original message text===============
!20031208 The growing blur of hardware and software
EPO/European arguments about software patent policy for too long have
ignored the growing blurring of hardware and software. What follows are
excerpts from various articles and papers, many European based, that
illustrate the vagueness of terms such as "hardware" and "software",
especially in light of everyone refusing to properly define "technical".
The use of "technical" to discriminate against software patents is bad
science, bad engineering and bad linguistics. That it is good politics
is not worth the betrayal.
Greg Aharonian
Internet Patent News Service
====================
The 6 December 2003 issue of The Economist, in its Technology Quarterly
insert, has an article on page 31 titled "How the radio changed its spot",
reporting on the growing movement towards software radios. The article
starts out:
When is a radio not a radio? When it's a computer program.
So when is a radio patentable and when isn't it? The article goes on:
This translation [of RF signals] involves several steps, most
of which are done by dedicated signal processing chips.
Presumably such chips processing analog signals are technical for
transforming physical electromagnetic signals of nature.
But given enough processing power, the same job can also be
done using software, rather than hardware. The result is a
"software defined radio", also known as a "reconfigurable"
or "smart" radio.
Which suddenly loses its patentability?
====================
U.S. Patent 6,230,307 issued in 2001 to Xilinx illustrates the practicality
of viewing hardware as software and software as hardware:
System and method for programming the hardware of field
programmable gate arrays (FPGAs) and related reconfiguration
resources as if they were software by creating hardware objects.
You try drawing the line for patentability of inventions made using
Xilink's technology!!! The abstract:
A method and system for programming the hardware of field
programmable gate arrays and related reconfiguration resources
as if they were software by creating hardware objects that
implement application level functionalities, operating system
functionalities, and hardware functionalities. Further
controlling and executing the hardware objects via high level
software constructs and managing the reconfigurable resources,
such that the reconfigurable resources are optimized for the
tasks currently executing.
====================
Scottish researcher Adam Donlin (University of Edinburgh), in 1998
published a paper titled "Self modifying circuitry - a platform for
tractable virtual circuity", the abstract of which ends with:
A discussion of the programming environment of the Flexible
URISC is given, and provides the medium for identifying how
the flexible URISC's single instruction - MOVE - effectively
minimises the hardware/software divide.
Imagine that, one word minimises the hardware/software divide. Time
to start whispering this word in the ears of the European Parliament
(though don't show them Donlin's article - the exposure to such science
will melt their brains).
====================
A new engineering design tool from a French company is a good example of
the blur between hardware and software. The startup company, CoFluent
Design (Nantes, France), has released its first product, CoFluent Studio,
a functional and architectural design tool.
Users with no proconceived ideas about a hardware/software platform can
start by developing a timed and executable functional model, and then go
through an interactive architectural exploration cycle that helps find the
best solution in terms of hardware/software partitioning, CPU utilization,
processor selection, bus architecture, throughput and other criteria.
AT THIS POINT, the design tool can then generate C code for the software
aspects of the implementation and VHDL for the hardware portions.
Company director Vincent Perrier is quoted as saying "You think in terms
of solving your problem, not in terms of hardware and software. Once
you have solved the problem, then you think of the physical architecture
that provides this functionality." And then you automatically generate
a prototype's hardware and software. The mix of hardware and software
is a fluid choice, often done by a computer. So why should one half of
this choice, the hardware, be patentable while the other half, the
software, not be patentable?
CoFluent's product is just one of many coming out of Europe (and more in
America) that are making hardware/software distinctions increasingly
irrelevant practically (another example, tools that directly C software
code directly into FPGA hardware netlists).
So there is little logic to talk about software patenting without jointly
talking about hardware patenting. Such talk shows contempt for companies
such as CoFluent. Don't like software patents? Fine, but get rid of the
hardware patents as well. Both or none. That is where the science and
engineering is going In Europe - so to must the law.
====================
An article in the October 2003 issue of Electronic Business, page 17,
talks about the economics of the hardware/software convergence. The
article, titled "Software or Silicon", starts out with:
Complicated chip designs are forcing semiconductor companies
to adjust their design tactics. One of the trickier decisions
is about where the intellectual property (IP) will reside -
in silicon or software.
"More chip IP is in adjoining sofware, not in the silicon.",
says Avner Goren, architectures marketing manager at TI.
TI's OMAP platform for cell phones, he adds, the IP can go in
silicon, software, flexible programmable hardware accelerators
or programmable digital signal processors (DSPs).
Where to place IP blocks might sound like a detail to be
determined by system architects, but these decisions affect
customers, time to market and the chip's success. With
[multimillion dollar R&D costs] that high, CEOs are paying
closer attention to issues such as how their designers
decide which IP goes in silicon and which goes in software.
Such decisions should not have to worry about how such choices affect
patentability. An arbitrary rule based on an ill-defined term such as
"technical" should not be allowed to complicate such choices.
====================
Two more papers from Europe show how professional software development
is an engineering process, like all other engineering processes in other
TECHNICAL FIELDS. The papers are from the Ninth Annual European Workshop
on Software Process Technology (a workshop I suggest some European
Parliamentarians attend for a dose of reality). Here are their abstracts:
Integrated Measurement for the Evaluation and Improvement of
Software Processes
Felix Garcia, Francisco Ruiz, Jose Antonio Cruz, Mario Piattini
University of Castilla-La Mancha, Spain
Abstract
Software processes have an important influence on the
quality of the final software product, and it has motivated
companies to be more and more concerned about software process
management when they are promoting the improvement of final
products. The management of software processes is a complex
activity due to the great number of different aspects to be
considered and, for this reason it is useful to establish a
conceptual architecture which includes all the aspects necessary
for the management of this complexity. In this paper, we
present a conceptual framework in which the software process
modeling and measurement are treated in an integrated way for
their improvement. As a support to the improvement a collection
of software process model metrics is proposed. For the
management of the measurement process, GenMETRIC, an extensible
tool for the definition, calculation and presentation of
software metrics, has been developed.
Modeling, measurement, metrics, tools, architecture. Sounds like technical
engineering to me.
Emprical Validation of the Prospect Method for Systematic
Software Process Elicitation
Ulrike Becker-Kornstaedt and Holger Nau
Fraunhofer Institute for Experimental Software Engineering,
Kaiserslautern, Germany
(note: hasn't the Fraunhofer Law institute told Fraunhofer
Experimental Software institute that software is not
technical, so it can't be experimented on?)
Abstract
This paper describes Prospect, a systematic approach to
software process elicitation, and its validation in an
industrial environment. Descriptive process models are
important assets if software process improvement. A survey
of the state of practice indicates that software process
models are insufficent in quality, the models are developed
in an uneconomic way, and the success of modeling activities
depends largely on the Process Engineer's experience. We
present the results of an empirical study to show that Prospect
circumvents these problems.
===8<===========End of original message text===========
--
Hartmut Pilch, FFII & Eurolinux Alliance tel. +49-89-18979927
Protecting Innovation against Patent Inflation http://swpat.ffii.org/
290,000 votes 2000 firms against software patents http://noepatents.org/
- GregNews: "The growing blur of hardware and software", Hartmut Pilch
(074db819ec%|loc%074db819ec)Archive powered by(074db819ec%END%074db819ec) MhonArc 2.6.16.
(074db819ec%TAGS [% %]%074db819ec)