ESP Wiki is looking for moderators and active contributors!

Difference between revisions of "Software patent quality worse than all other fields"

m (Undo revision 21293 (spam) by Ezadetedek (talk))
(19 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{navbox}}
 
 
Quality problems can happen in any category of patents, but the quality of [[software patents]] is particularly bad.  This is probably a fundamental problem that can't be avoided in a domain as abstract as software.
 
Quality problems can happen in any category of patents, but the quality of [[software patents]] is particularly bad.  This is probably a fundamental problem that can't be avoided in a domain as abstract as software.
  
==Possible reasons==
+
The main cause is probably that '''[[software is too abstract]]''', making and applying examination rules is just too difficult.
# Abstract algorithms can be described in so many ways
+
 
# Jargon and lack of tangible components can make a mundane software idea sound technical
+
==Evidenced in Allison's 2010 study==
# Professionals working in the patents industry only see the ideas submitted for patenting, and therefore fail to realise that they are not qualitatively different from the ideas that good software engineers come up with every day of the week, most of which are considered too obvious to write up and publish
+
{{also|Patent Quality and Settlement Among Repeat Patent Litigants}}
# US Patent law merely asks a patent invention be non-obvious to a person having ordinary skill in the art. This is a very low standard almost implying that almost anyone practicing in the art would come upon that invention given a few years time if not minutes or hours. We need only look at the bell curve to see how many things that would be obvious for many on the top third (or top half) of the curve would be eligible for a patent by not being obvious to those in the central region (or exactly in the middle). This might not be a major problem for society and for other inventors if you have to have 100 million dollars to build a business off your invention, but it is a problem for cheap software cloned and distributed essentially for no cost since anyone can play.
 
# The low bar to inventiveness and significant power grant that is a patent encourages inventor-lawyers to dumb down and broaden the patent claims as much as possible to increase scope of infringement. The effect is that even a genius idea will get watered down to just barely meeting the minimum criteria of non-obvious to a PHOSITA so as to maximize the ROI. [Why is this dumbing down incentive particularly large for software? The power that comes with a software patent is particularly large and dumbing down is particularly easy. See other points for more details.]
 
# The very large number of software creators means the likelihood is that much greater that a patent will be gotten on broader dumber idea. This is because with more people a more diverse range of quality will make itself to the patent office first. Additionally, it's easier and faster to write the broader more dumb patent, and this trumps the more precise patent if the dumber one comes first. [So this is a case where competition brings the average quality down! This detrimental effect exists because being first means everything (20 years). Ordinarily, being first to market means some (or means nothing if all you have is a broad idea), but being better a year or two later means a fair amount. Unfortunately, no such balance exists with patent exclusivities.]
 
# Too much public FOSS exists and is created daily for the patent examiner to become familiar with it on a daily basis. If it is virtually impossible to read all new patents and understand them, it is even more difficult to read all public source code and understand it and its implication as prior art. Also, FOSS is a relatively new phenomenon.
 
# The nature of software means that every bit counts. Changing very few details (even the average tiny one) can cause a product to fail: many details must be specified precisely. With most physical materials, this is certainly not the case, so a standard way of describing inventions arose where the smallest of details (and even medium ones) could be discarded in the patent claims language. The result is that patent claims on software are very sloppy and broad relative to the degree of detail needed to properly implement the invention. [Related to this is that a great many variations are possible, each variation requiring a full analysis for correctness rather than simply changing the blade on the saw or pigment concentration in the dye and then ignoring the huge number of small variations that could arise. Software has already been digitized, and the computing machine is generally very demanding on accuracy because of its "stupidity".]
 
# Software inventions are not limited by Mother Nature. This means creating an invention can be like writing fiction. Conjure it up, and it can be created. [Related to this is that, with software products being manufactured by so many, a patent author can be extra bold and not worry as much about being too far ahead of the times.] [Together all of this points out that software develops very fast, which adds to the relative contrast pointed out earlier of how newly created software is rich in details relative to the descriptions in the patents.]
 
  
==The ideas are too abstract==
+
Page 28 (pdf page 29):
 +
<blockquote>
 +
If we consider just patent owner wins and defendant wins on the merits, non‐software patent win 37.1% of their cases across both the most‐litigated and once‐litigated data sets, owners while software patentees win only 12.9%.  If we include default judgments, non‐software patent owners win 51.1% of their cases, while software patentees win only 12.9%.  Each of these results is highly statistically significant.
 +
(...)
 +
Once settlements are included, non‐software patent companies win judgments in 4.0% of their suits, while software patentees win judgments in only 1.4% of their suits.  Adding default judgments changes these numbers to 7.2% for non‐software patent owners and 1.4% for software patentees.
 +
</blockquote>
  
In chemistry, ideas are described concretely, such as ''Trans-6-[2-(3- or 4-carboxamido- substituted pyrrol-1-yl)alkyl]-4-hydroxypyran-2-ones''.<ref>http://www.researchoninnovation.org/swconf/bessenslides.pdf</ref>
+
==Possible reasons==
  
In software, ideas are described as "''point of sale location''", "''material object''", or "''information manufacturing machine''".
+
# Abstract algorithms can be described in so many ways.
 +
# Jargon and lack of tangible components can make a mundane software idea sound technical.
 +
# It's impossible for a patent examiner to judge obviousness.  Software developers use so many ideas during their work, only a tiny percent ever get submitted to the patent office or otherwise published.
  
 
==Examples==
 
==Examples==
Line 26: Line 26:
  
 
==Related pages on {{SITENAME}}==
 
==Related pages on {{SITENAME}}==
* [[Raising standards is not our goal]]
+
 
* [[The disclosure is useless]]
+
* [[Raising examination standards wouldn't fix much]]
 
* [[Silly patents]]
 
* [[Silly patents]]
* [[Software patents are unreadable]]
 
 
* [[How to read patents]]
 
* [[How to read patents]]
 
* [[Why software is different]]
 
* [[Why software is different]]
 +
* [[Software patents produce legal uncertainty]]
 +
* [[The disclosure is useless]]
  
 
==External links==
 
==External links==
* [http://eupat.ffii.org/analysis/trivial/ Why are Software Patents so Trivial?] [http://www.ffii.org/Why_software_patents_are_trivial other version (possibly identical)]
+
* [http://eupat.ffii.org/analysis/trivial/ Why are Software Patents so Trivial?] [http://www.ffii.org/Why_software_patents_are_trivial other version (possibly identical)], by '''[[FFII]]'''
 +
* [http://opensource.com/law/10/11/software-too-abstract-be-patented Is software too abstract to be patented?], 18 Nov 2010, '''Rob Tiller''' ([[Red Hat]])
 +
* [http://www.groklaw.net/article.php?story=20101007030644178 Why Software is Abstract, by PolR], 7 Oct 2010, '''[[Groklaw]]'''
 +
* [http://www.groklaw.net/article.php?story=2010092621054289 An Open Response to the USPTO — Physical Aspects of Mathematics], 26 Sep 2010, '''Groklaw'''
  
 
==References==
 
==References==

Revision as of 15:11, 11 January 2013

Quality problems can happen in any category of patents, but the quality of software patents is particularly bad. This is probably a fundamental problem that can't be avoided in a domain as abstract as software.

The main cause is probably that software is too abstract, making and applying examination rules is just too difficult.

Evidenced in Allison's 2010 study

See also: Patent Quality and Settlement Among Repeat Patent Litigants

Page 28 (pdf page 29):

If we consider just patent owner wins and defendant wins on the merits, non‐software patent win 37.1% of their cases across both the most‐litigated and once‐litigated data sets, owners while software patentees win only 12.9%. If we include default judgments, non‐software patent owners win 51.1% of their cases, while software patentees win only 12.9%. Each of these results is highly statistically significant. (...) Once settlements are included, non‐software patent companies win judgments in 4.0% of their suits, while software patentees win judgments in only 1.4% of their suits. Adding default judgments changes these numbers to 7.2% for non‐software patent owners and 1.4% for software patentees.

Possible reasons

  1. Abstract algorithms can be described in so many ways.
  2. Jargon and lack of tangible components can make a mundane software idea sound technical.
  3. It's impossible for a patent examiner to judge obviousness. Software developers use so many ideas during their work, only a tiny percent ever get submitted to the patent office or otherwise published.

Examples

Related pages on ESP Wiki

External links

References