Hardware and software are developed together in apple products to get
the maximum out of the user experience, which is the main competitive
advantage of Apple. This has generated a really strong brand that
gives them a considerable premium in the market and that is really
hard to copy, unless you really make a clone, but than that is illegal
for other reasons (e.g. copyright, trademark). (01)
On Wed, Oct 19, 2011 at 11:47 PM, Debmacp <debmacp@xxxxxxxxx> wrote:
> What about situations where hardware and software should not be so separated
>to encourage phased development. One example is most apple products, another
>is measuring devices.
> Deborah MacPherson
> Sent from my iPhone
> On Oct 19, 2011, at 5:08 PM, Edward Barkmeyer <edward.barkmeyer@xxxxxxxx>
>> Kristof Van Tomme wrote:
>>> Patents started as a system that encouraged the sharing of trade
>>> secrets so that they could sooner belong to the public domain. In
>>> exchange, governments granted a monopoly which length was only a
>>> fraction in the lifecycle of that technology. Today patents have
>>> evolved into a system that protects vested interests for a
>>> considerable part of the lifetime of these technologies.
>> Yes. This is one aspect of the problem -- the pace of technological
>> advance. The lifetime of an innovative technology, as the lead
>> technology for cost or effectiveness in some area, is now in the 10-20
>> year range. The lifetime of an innovative application may be less than
>> 5 years overall, and most will be re-engineered into competitive
>> products in 2 years. This problem is not restricted to software,
>> software tends now to be part of all the products that use innovative
>>> I believe that inventions that are easily reverse engineered should
>>> not be protectable, especially in markets that are so big and that
>>> require comparatively low investment costs.
>> This touches on the other aspect of software -- it has essentially no
>> production cost. There is no need to finance and build, or retool, a
>> plant to make the product. Further, the industry has a tradition of
>> irresponsibility that sees no need for warranty, and thus no need for
>> the delays produced by verification and field testing. One does not
>> need the patent protection to afford time to finance, time to test, and
>> time to market.
>> Given all that, and the fact that, like other smart startups, a major
>> player in the industry will either buy you out or compete with advantage
>> in 2 years (their time to study the market and either re-engineer or
>> acquire the established name), what is a good lifetime for a software
>>> Strong competition will not stop companies from investing in them,
>> Yes, by re-engineering to bypass the patent, or outright acquisition of
>> the patent along with the patent holder.
>>> in such markets protecting
>>> inventions is against the best interest of the public, they are a tax
>>> on innovation.
>> I disagree. The innovator at least needs the patent to make the
>> acquisition of his company an alternative. The patent, and perhaps the
>> market name, if it has been achieved, is the value in the company. That
>> alternative is a viable strategy for would-be competitors, and the more
>> foreseeable competitors who might try to adopt it, the more interesting
>> that strategy becomes to each of them. (A few years ago, when a
>> colleague sold his 7-year-old company to a major software firm and
>> pocketed 40M$, I told him his hard work had paid off. His response was:
>> "Finally. It sure as hell didn't pay off while I was running the
>> company.") So, I really think patent protection has value to the
>> inventor, even in cheap apps for large markets. The only difference is
>> in the monetary value of the patent.
>> The problem is to make the patent lifetime long enough that competitors
>> must acquire, license, or re-engineer, rather than just waiting it out,
>> and thus grant the inventor some fruits of his labor, but not so long as
>> to lock up an entire technology over its probable lifetime, and thus
>> discourage further related innovation. And that is becoming a fine line.
>> In the mechanical and electrical fields, the adjustment has been in
>> interpreting the scope of patents more narrowly, and discarding broad
>> patents with ill-defined mechanisms. We may hope that that will begin
>> happening in the software field, as the patent process becomes common,
>> and the need for careful interpretation evolves. The USPTO has limited
>> staff, and limited expertise, and this is a relatively new area. We are
>> all recovering from 50 years of gold rush; it will take a while for
>> order to set in.
>>> That is why I don't see the arrival of these engineering best
>>> practices as something that should cause celebration.
>> Well, we disagree. The computer-controlled power-steering in my car
>> does not come with a warranty that says that if it fails and runs off a
>> cliff, we only promise to replace it with the latest update, if that.
>> But that is because the software in my car was built under an
>> engineering contract that makes the software supplier liable for the
>> expenses of a recall to fix a software problem, which in turn caused the
>> software supplier to adopt engineering practices, in order to avoid
>> potentially devastating downstream cost. Similar behavior is observed
>> in the development of avionics software that controls automated takeoff
>> and landing of commercial aircraft. And yes, all of that software is
>> patented, although as part of the mechanism of the overall device patent
>> in most cases. Yet we routinely trust vital business information to
>> software built with no such engineering practices, and we only hope that
>> our competitors do the same. That is the situation I hope will change.
>> Patent is a valuable part of the engineering process, because it affords
>> the opportunity for recovering the cost of properly executing that process.
>>> I'm not saying that you should not get patents yourself, in the
>>> current system that's probably your only option.
>>>> Kristof Van Tomme wrote:
>>>>> If you are in this field and you might be doing things that infringe
>>>>> on this patent, I would advise you to not read any of this or at least
>>>>> not comment on it, unless you have the money and reason to dispute the
>>>>> validity of these patents. In the other case, if you ever get
>>>>> prosecuted it will save you a lot of money if you didn't know about
>>>>> the exact claims that have been granted.
>>>> I would be surprised to find that this advice is supported by
>>>> experience. In most engineering activities, the engineer or his/her
>>>> staff is expected to do a patent search before committing a design to
>>>> production. The purpose of the search is to protect the company from
>>>> potential patent infringement claims after committing significant monies
>>>> to production and marketing. The whole idea is that one can determine
>>>> whether the central features of the design are patented by others, thus
>>>> negating all value in the design, and whether there are 'touching
>>>> patents' whose potential claims can be avoided by making minor
>>>> modifications to the design. In patent infringement cases, ignorance of
>>>> prior patent is /not/ a defense, unless the domain and function of the
>>>> patent was described in terminology that was not readily recognizeable
>>>> as the same as the domain and function of the claimed infringement.
>>>> (This latter is more of an international patent issue, in that it arises
>>>> from language translations and inconsistencies in terminology across
>>>> national boundaries, notably British terminology vs. American
>>>> terminology. But it also arises across specialized discipline areas,
>>>> like pharmaceuticals vs. chemical agricultural products.) Standard
>>>> practice is to do the patent search. If you didn't do the patent
>>>> search, you are liable. You can only be excused if a reasonable search
>>>> might not have identified the patent as relevant, and even that doesn't
>>>> free you from future liability. (That is why they send 'cease and
>>>> desist' letters -- if you were ignorant, now you aren't.)
>>>> I repeat what is becoming a mantra: Knowledge engineering and software
>>>> engineering are engineering disciplines, and they are finally becoming
>>>> exposed to the expected behaviors in good engineering practice.
>>>> Edward J. Barkmeyer Email: edbark@xxxxxxxx
>>>> National Institute of Standards & Technology
>>>> Manufacturing Systems Integration Division
>>>> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
>>>> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800
>>>> "The opinions expressed above do not reflect consensus of NIST,
>>>> and have not been reviewed by any Government authority."
>> Edward J. Barkmeyer Email: edbark@xxxxxxxx
>> National Institute of Standards & Technology
>> Manufacturing Systems Integration Division
>> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
>> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800
>> "The opinions expressed above do not reflect consensus of NIST,
>> and have not been reviewed by any Government authority."
>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>> Shared Files: http://ontolog.cim3.net/file/
>> Community Wiki: http://ontolog.cim3.net/wiki/
>> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
ir. Kristof Van Tomme
9940 Sleidinge, Akkerken 6, Belgium
6721 Szeged, Vidra utca 1B, Hungary
Web: www.pronovix.com (05)
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (06)