Software Patents and the Return of Functional Claiming
Mark A. Lemley
Stanford Law School
October 12, 2012
Stanford Public Law Working Paper No. 2117302
Commentators have observed for years that patents do less good and cause more harm in the software industry than in other industries such as pharmaceuticals. They have pointed to a variety of problems and offered a variety of solutions.
While there is some truth to each of these criticisms, the real problem with software patents lies elsewhere. Software patent lawyers are increasingly writing patent claims in broad functional terms. Put another way, patentees claim to own not a particular machine, or even a particular series of steps for achieving a goal, but the goal itself. The resulting overbroad patents overlap and create patent thickets.
Patent law has faced this problem before. The Supreme Court ultimately rejected such broad functional claiming in the 1940s as inconsistent with the purposes of the patent statute. When Congress rewrote the Patent Act in 1952, it adopted a compromise position: patentees could write their claim language in functional terms, but when they did so the patent would not cover the goal itself, but only the particular means of implementing that goal described by the patentee and equivalents thereof. These “means-plus-function” claims permitted the patentee to use functional language to describe an element of their invention, but did not permit her to own the function itself however implemented.
Most software patents today are written in functional terms. If courts would faithfully apply the 1952 Act, limiting those claims to the actual algorithms the patentees disclosed and their equivalents, they could prevent overclaiming by software patentees and solve much of the patent thicket problem that besets software innovation.
Number of Pages in PDF File: 60working papers series
Date posted: July 26, 2012 ; Last revised: October 24, 2013
© 2014 Social Science Electronic Publishing, Inc. All Rights Reserved.
This page was processed by apollo1 in 0.500 seconds