scholarly journals Patent Absurdity

Queue ◽  
2021 ◽  
Vol 19 (4) ◽  
pp. 19-22

The main reason a lawyer will give for not reading a software patent is that, if you run afoul of the patent and it can be shown that you had knowledge of it, your company will incur triple the damages that they would have, had you not had knowledge of the patent. That seems like reason enough to avoid reading them, but there is an even better reason, and that is, as design or technical documents, software patents suck.

2016 ◽  
Author(s):  
Mark Lemley

Software patents have received a great deal of attention in the academicliterature. Unfortunately, most of that attention has been devoted to theproblem of whether software is or should be patentable subject matter. Withroughly 40,000 software patents already issued, and the Federal Circuitendorsing patentability without qualification, those questions are for thehistory books. The more pressing questions now concern the scope to beaccorded software patents. In this paper, we examine the implications ofsome traditional patent law doctrines for innovation in the softwareindustry. We argue that patent law needs some refinement if it is topromote rather than impede the growth of this new market, which ischaracterized by rapid sequential innovation, reuse and re-combination ofcomponents, and strong network effects that privilege interoperablecomponents and products. In particular, we argue for two sorts of new rulesin software patent cases.First, we advocate a limited right to reverse engineer patented computerprograms in order to gain access to and study those programs and toduplicate their unprotected elements. Such a right is firmly established incopyright law, and seems unexceptional as a policy matter even in patentlaw. But because patent law contains no fair use or reverse engineeringexemption, patentees could use the grant of rights on a single component ofa complex program to prevent any "making" or "using" of the program as awhole, including those temporary uses needed in reverse engineering. Whilepatent law does contain doctrines of "experimental use" and "exhaustion,"it is not at all clear that those doctrines will protect legitimate reverseengineering efforts. We suggest that if these doctrines cannot be readbroadly enough to establish such a right, Congress should create a limitedright to reverse engineer software containing patented components forresearch purposes.Second, we argue that in light of the special nature of innovation withinthe software industry, courts should apply the doctrine of equivalentsnarrowly in infringement cases. The doctrine of equivalents allows afinding of infringement even when the accused product does not literallysatisfy each element of the patent, if there is substantial equivalence asto each element. The test of equivalence is the known interchangeability ofclaimed and accused elements at the time of (alleged) infringement. Anumber of factors unique to software and the software industry - a cultureof reuse and incremental improvement, a lack of reliance on systems offormal documentation used in other technical fields, the short effectivelife of software innovations, and the inherent plasticity of code -severely complicate post hoc assessments of the "known interchangeability"of software elements. A standard for equivalence of code elements thatignores these factors risks stifling legitimate, successful efforts todesign around existing software patents. To avoid this danger, courtsshould construe software claims narrowly, and should refuse a finding ofequivalence if the accused element is "interchangeable" with prior art thatshould have narrowed the original patent, or if the accused improvement istoo many generations removed from the original invention.


2020 ◽  
Vol 21 (3) ◽  
pp. 205-212
Author(s):  
Michael C. Greenbaum ◽  
S. Gregory Herrman

Software patents have garnered a lot of attention in recent years due, at least in part, to the proliferation of software-enabled devices, such as smartphones and tablets, and the use of software to control a range of devices from automobiles to kitchen appliances. Enforcement of software patents involves unique legal issues that should be considered before asserting a patent against an accused infringer. A primary issue to consider is whether the patent claims are still patent-eligible under recent changes in the law. Also, certain types of software patents are vulnerable to attack in U.S. Patent Office proceedings, but these proceedings are not available unless the patent owner takes step to provoke them. In addition, software inventions are often implemented as method patents, which have unique requirements and restrictions that should be considered. For example, steps of a method patent must all be performed by an accused infringer in the United States and must all be performed by the same entity (or under the direction or control of that entity). Where a software invention is not implemented as a method patent, pre-suit damages may not be available unless the patentee's own products are properly marked with the patent number, and software has very different requirements for marking than more tangible products. A careful consideration of each of these issues is essential before moving forward with a lawsuit.


2016 ◽  
Author(s):  
Mark Lemley

Patents constitute our foremost policy tool for encouraging innovation.However, because each new technology provides an important input tosubsequent innovation, the exclusive rights conferred by a patent may alsoimpose significant costs upon follow-on innovators. Optimal patent policyshould seek to maximize the patent incentive effect, while minimizingburdens placed on future innovation by tailoring the scope of the patent tothe characteristics of each technological sector affected.In the case of software, recent scholarship has illuminated the innovationprofile of the current industry. Software is characterized by incrementalinnovation, relatively low development costs, and short, volatile productlife cycles. Interoperability and compatibility between complementaryproducts is a major concern, making technical transparency or reverseengineering critical to product development. This suggests a need forrelatively narrow patents that are relatively easy to obtain, and subjectto the exceptions necessary to ensure interoperation and follow-ondevelopment.However, current software patent doctrine bears little relationship to thisindustrial profile. The United States Court of Appeals for the FederalCircuit has set an extremely lax standard of disclosure software patents,resulting in patents scope unconstrained by doctrines of enablement andwritten description. Recent changes that make patent law amenable tosoftware have produced a flood of new applications, allowing firms to adopta patent thicket strategy for licensing leverage. At the same time, FederalCircuit case law suggests that a stringent standard for patentnon-obviousness will be applied to such patents, resulting in relativelyfew valid software patents. Optimal software patent doctrine wouldconstrain scope to deal with patent thicket while lowering thenon-obviousness standard to validate more issued software patents.


2016 ◽  
Author(s):  
Mark Lemley

On Feb 12, 2013, the PTO held a roundtable about software patents atStanford. Software patents have received a lot of attention and we don'tbelieve it is undue: software patents are behind a disproportionate shareof patent litigations -- more specifically, over half (55%) of all patentdefendants and 82% of PAE ("patent troll") defendants are there because ofa software patent, applying the Graham-Vishnubhakat definition to dataprovided by RPX Corporation. In this presentation, we more rigorously apply35 USC 112(f) in accordance with the proposal Mark Lemley outlines in hisWIRED oped "Let's Go Back to Claiming the Problem Not the Solution" to 30patents - 10 PAE and 20 control patents, provided by Patent Freedom. Wefind that 1) PAE patents are overwhelmingly functionally claimed (100%),but non-PAE patents are also functionally claimed (50%), 2) 40%-50% of thePAE patents were only supported by the highest levels of abstraction, butthat 3) not all code is created equal - low-level code over genericelements does not necessarily promote technical progress. We provide 5examples to support these findings, and discuss their implications.


2016 ◽  
Author(s):  
Mark Lemley

Commentators have observed for years that patents do less good and causemore harm in the software industry than in other industries such aspharmaceuticals. They have pointed to a variety of problems and offered avariety of solutions.While there is some truth to each of these criticisms, the real problemwith software patents lies elsewhere. Software patent lawyers areincreasingly writing patent claims in broad functional terms. Put anotherway, patentees claim to own not a particular machine, or even a particularseries of steps for achieving a goal, but the goal itself. The resultingoverbroad patents overlap and create patent thickets.Patent law has faced this problem before. The Supreme Court ultimatelyrejected such broad functional claiming in the 1940s as inconsistent withthe purposes of the patent statute. When Congress rewrote the Patent Act in1952, it adopted a compromise position: patentees could write their claimlanguage in functional terms, but when they did so the patent would notcover the goal itself, but only the particular means of implementing thatgoal described by the patentee and equivalents thereof. These“means-plus-function” claims permitted the patentee to use functionallanguage to describe an element of their invention, but did not permit herto own the function itself however implemented.Most software patents today are written in functional terms. If courtswould faithfully apply the 1952 Act, limiting those claims to the actualalgorithms the patentees disclosed and their equivalents, they couldprevent overclaiming by software patentees and solve much of the patentthicket problem that besets software innovation.


Sign in / Sign up

Export Citation Format

Share Document