ESP Wiki is looking for moderators and active contributors!

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

(Expert evaluations: syntax)
(7 intermediate revisions by the same user 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.
  
==The ideas are too abstract==
+
The main cause is probably that '''[[software is too abstract]]''', making and applying examination rules is just too difficult.
  
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>
+
==Evidenced in Allison's 2010 study==
 +
{{also|Patent Quality and Settlement Among Repeat Patent Litigants}}
  
In software, ideas are described as "''point of sale location''", "''material object''", or "''information manufacturing machine''".
+
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>
  
 
==Possible reasons==
 
==Possible reasons==
Line 13: Line 18:
 
# Jargon and lack of tangible components can make a mundane software idea sound technical.
 
# 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.
 
# 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.
 
==Expert evaluations==
 
 
From NPR's article [http://www.npr.org/blogs/money/2011/07/26/138576167/when-patents-attack When Patents Attack]:
 
 
<blockquote>
 
[[David Martin]], who runs a company called M-Cam. It's hired by governments, banks and business to assess patent quality, which the company does with a fancy piece of software. We asked Martin to assess Chris Crawford's patent [US5771354].<br />
 
<br />
 
At the same time Crawford's patent was being prosecuted, more than 5,000 other patents were issued for "the same thing," Martin says.<br />
 
<br />
 
Crawford's patent was for "an online backup system." Another patent [US6003044] from the same time was for "efficiently backing up files using multiple computer systems." Yet another [US6587935] was for "mirroring data in a remote data storage system."<br />
 
<br />
 
And then there were three different patents [US6049874, US6038665, and US6014676] with three different patent numbers but that all had the same title: "System and method for backing up computer files over a wide area computer network." [...]<br />
 
<br />
 
We also asked Rick Mc Leod, a patent lawyer and former software engineer, to evaluate Chris Crawford's patent. "None of this was actually new," he told us.
 
</blockquote>
 
  
 
==Examples==
 
==Examples==
Line 37: Line 26:
  
 
==Related pages on {{SITENAME}}==
 
==Related pages on {{SITENAME}}==
* [[Raising standards is not our goal]]
+
 
 +
* [[Raising examination standards wouldn't fix much]]
 
* [[Silly patents]]
 
* [[Silly patents]]
 
* [[How to read patents]]
 
* [[How to read patents]]
 
* [[Why software is different]]
 
* [[Why software is different]]
 
* [[Software patents produce legal uncertainty]]
 
* [[Software patents produce legal uncertainty]]
* [[Software is too abstract, software patent quality is terrible]]
 
 
* [[The disclosure is useless]]
 
* [[The disclosure is useless]]
* [[Infringement is unavoidable]]
 
  
 
==External links==
 
==External links==

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