ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Siri's (Apple) Patent Application

To: Debmacp <debmacp@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Edward Barkmeyer <edward.barkmeyer@xxxxxxxx>
Date: Wed, 19 Oct 2011 18:58:36 -0400
Message-id: <4E9F561C.2080605@xxxxxxxx>
Deb,    (01)

you 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
>       (02)

I have trouble parsing that first sentence.  Most current practice in 
'cyberphysical systems' (devices controlled by built-in software) is to 
patent a combined software/hardware mechanism for a well-defined 
function that is part of the function of the whole system. I don't know 
how that relates to "phased development".  The design of such a product 
is a joint hardware/software team activity, because each influences the 
design of and requirements on the other.  But a smart platform, like an 
iPhone, can support a lot of independent software mechanisms that only 
operate on the hardware via platform interfaces, just like software on 
your PC platform.  And obviously, this latter stuff is separable and can 
be phased in.    (03)

A product like the iPhone has at least a dozen different patents.  It is 
typical of a complex product to have patents on each separate 
function/mechanism pair for which the function is well-defined and the 
mechanism is in some sense separable from other mechanisms, what we 
might call a subsystem.  So there will be patents on the keyboard 
technology, the display technology, the wireless signalling technology, 
the wireless encoding technology, the ergonomic instrument shape, the 
internal signal bus, etc.  There are often patents on connectors.  And 
several of the patents on devices in the iPhone may well be licensed to 
Apple rather than held by them.  And there will be larger patents on the 
major subassemblies, as the body of those components for the primary 
function(s) of the subassembly.  This trick of 'layers of patents' makes 
it easier for the company to reuse components in next year's model or in 
some related product, and it makes it easier for a competitor to produce 
a competing overall design, while also making it necessary for him to 
re-engineer every component, and/or acquire the same licenses.  The 
theory is that you don't hog the technology market, you just make the 
competitor make the same size investment, and start later.    (04)

So the issue is whether the mechanism that some part of the software 
implements is a a meaningful function that is usefully described as 
independent of the function performed by the combination of that 
software element and some related hardware element(s).  And of course, 
it depends on whether that software mechanism alone has ever appeared in 
the literature.  Often what is patented is the use of a known 
general-purpose algorithm applied to a specific knowledge-base 
(ontology) to decide which special-purpose signals should be generated 
when.  Using the public domain algorithm is not an infringement, but 
using it on an identical knowledge-base is, or using a very similar 
knowledge base with the same algorithm to generate identical (e.g., 
standard) signals in the same situations.  By comparison, when you 
actually invent an algorithm for decoding a particular kind of digital 
voice encoding into known commands, that software signal processing 
algorithm may well be patentable.  Or it may be that just the algorithm 
for decoding those particular signals to phonemes is patentable, while 
the algorithm for associating phoneme sequences with reference command 
phoneme sequences was published long ago.  And it may depend on whether 
you integrate phoneme and command recognition in a way that involves 
feedback or just do them sequentially.  This is why being a patent 
investigator is a difficult job.    (05)

In the electromechanical industries, and in most current 'cyberphysical 
systems', strong narrow patents, and lots of them, have become the 
common practice.  The broad patents on generic mechanisms have pretty 
much died, unless the mechanism is a truly new technology (and we 
haven't yet learned how to describe its aspects narrowly).  If you find 
the philosopher's stone, you can probably still patent a device with any 
similar atomic and crystal structure that turns base metal into gold, 
and you may not have to know exactly which are the active and catalytic 
elements.  Good luck!    (06)

-Ed    (07)


> Sent from my iPhone
>
> On Oct 19, 2011, at 5:08 PM, Edward Barkmeyer <edward.barkmeyer@xxxxxxxx> 
>wrote:
>
>   
>> 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 
>> technologies.
>>
>>     
>>> 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 
>> patent?
>>
>>     
>>> 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.
>>
>> Best,
>> -Ed
>>
>>     
>>> I'm not saying that you should not get patents yourself, in the
>>> current system that's probably your only option.
>>>
>>> cheers,
>>> Kristof
>>>
>>>
>>>       
>>>> 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.
>>>>
>>>> -Ed
>>>>
>>>> --
>>>> 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
>>
>>         (08)


-- 
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    (09)

"The opinions expressed above do not reflect consensus of NIST, 
 and have not been reviewed by any Government authority."    (010)


_________________________________________________________________
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    (011)

<Prev in Thread] Current Thread [Next in Thread>