VIII. Appendix A: Defend Innovation -- Open up the patent granting process
Problem: Software patents are hard to understand. Really hard, because patent lawyers can get away with writing them in extremely vague and broad language. This means that innovators are left without clear guidance on what patents they might be infringing. It also allows trolls to exploit the vague and confusing patent language to extort higher licensing fees than they would otherwise be entitled.
Solution: Patent applicants should be required to provide an example of running software code for each claim in the patent and tell the Patent Office which claims are covered by which lines of that code. Think, for example, of early Patent Office practice requiring the submission of a “model” of the working invention to the Patent Office.
Comments:
I would add to this that the demonstration program be should definitive in terms of setting the boundaries of the scope of the patent. Too often the patent claims are written in the vaguest, broadest language possible so as to maximize potential infringement and prevent workarounds. If the demo program outlined the definitive scope of the patent, then the incentive to write vague overbroad patents goes away.
I want to address differences in computer platforms and why something would or would not be Obvious or nonobvious. There should be a rule in software patent law that doesn't allow a patent to be valid just because the type of computer system or network, etc. is different. I will explain why below. (The requirement of non-obviousness essentially means that the invention must not be an obvious variation or combination of subject matter previously known. http://www.dougweller.com/novelty.html) Some technical jargon I may or may not have correct... my lay understanding is roughly that any Turing Machine/Von Neumann machine can emulate any other. My point, which might not be clear is that any computer can emulate any other. Any computer can do something in software that any other computer could do -- THUS -- based on the issue of Novelty and Non-obviousness, if something has been done in prior art on one platform (in software) doing this on a different platform should be NON Novel and clearly Obvious. Thus any platform-specific software patents should be invalidated and there should be a review process for removing any existing patents which would violate this rule. If a particular inventor feels this basic tenet of computer science doesn't apply to their "invention" and desires some form of redress a neutral three-person expert panel would need to be certified as experts and brought into an appropriate hearing at the PTO to give testimony and to certify why a particular software patent is novel and Non-obvious.
The overall proposal by the EFF is excellent however it doesn't address one of the key points of failure for the PTO; that failure point is searches for Prior art. The PTO doesn't have the right databases nor the proper training to find and identify prior art (according to many insiders). Given the detailed level of domain expertise required to find and evaluate prior art, there needs to be crowd sourced review process. I am proposing a two-level review which will accept comments from the general public as well as from member of a class of accredited peers. My vision is: Tier 1 would be open to anyone but not binding on the PTO. Tier 2 members would accepted based on review of credentials (set by peer committee and PTO). Any prior art indicated by Tier 2 members as well as any Tier 1 art endorsed by a Tier 2 member would have to be addressed by the PTO before any valid patent is issued.
We need to efficiently locate patents which we are in danger of infringing. This is the 'Notice function' of property, which in "Patent Failure" Bessen and Maurer correctly state is failing in the case of patents. As noted by Lee and Mulligan in "Scaling the Patent system", software patents are not indexable in the same way that you can index chemicals by their chemical formula. In fact, indexing software is impossible in the general case (if you could do it, you could also solve the halting problem!). I have been thinking about a system along the following lines: Imagine that at a given point in time, the patent database included not just the individual patents, but a '20 questions' style index, whereby any patent could be located. Crucially, no patent could be enforced against anything outside the 'bucket' in which it is indexed. (A patent could be indexed in more than one bucket, but only by paying the fee for each.) This would have two effects: first, it would be a lot easier to find patents you are in danger of infringing. Second, the boundaries between buckets would be defined much more precisely than those of an individual patent. Why? When drafting a patent, the incentives are to make it as vague as possible. But in the case of the buckets, the incentive is more like drawing a boundary line in real property: because the line affects those on both sides, one's loss is the others gain, so each pushes to make sure his own property is clearly demarcated. Such an index would have to be rebalanced every so often, like a binary tree. So patent owners would need to monitor where their patent had been moved to. Ironically, patent lawyers may actually like that - it would involve them in more work.
The problem is not simply that too many patents don't involve running code, but that even the ones that do are not limited to the actual solution the patentee came up with. The patent claims are written in broad functional language, so that the patentee owns ANY solution to the problem, not just the one they provided. There is a simple legal fix to this: require software patent claims to be limited to the actual solution disclosed or its equivalent. My paper "Software Patents and the Return of Functional Claiming" discusses the problem and how to solve it.
The proposal states that "applicants should be required to provide an example of running software code for each claim in the patent." I'd be happier if the proposal used the language of patent law rather than the colloquial phrasing that it uses because then I would feel more confident that the proposer actually knows what he is proposing and why it is wrong. One of the requirements of getting a patent is that the patent must be enabled. There are two ways to enable a patent, those being actual enablement and constructive enablement. A patent is actually enabled by a working invention. A patent is constructively enabled by a description of how to practice the invention, but lacks a working invention. A blueprint is a constructively enabled house. It describes how to build a house, but usually does not actually come with a house. A house is an actually enabled house. If you were to purchase one of those, the blueprint would generally be cheaper than the actual house, but that is not to say that architects cannot be paid for creating blueprints at all. In terms of patent law, the proposal here is to disallow constructive enablement of patents, but only for software. Ask two questions. First, what purpose is served by constructive enablement, both generally for patent law as a whole and for software specifically? Understand what you're throwing out before you throw it out. Second, what is special about constructive enablement as applied specifically to software? Understand whether it makes more sense to figure out how to fix constructive enablement system-wide rather than just applying a (probably ill-considered) ban on constructive enablement for exactly one specific type of invention.
When submitting code, one alternative is to submit compiled object code which is executed by a reference hardware/OS combination. The reference hardware/OS can be provided by open source communities and by private OS builders (Microsoft, Apple, BlackBerry). The reference hardware/OS would have an emulator which would have to be maintained over time, so that people could go to the USPTO and run applications on the emulators. Hardware/OS providers have an incentive to maintain these reference environments, because doing so would attract developers to the platform and because it would greatly reduce troll activity. Source code could also be provided, but in an encrypted form, for use during (rare) litigation. The "reference" environments would have to include "dummy" client/server units with which the software interacts (most software patents involve multiple third party components), but these can be built showing test interactions and don't have to be a real client/server. Failure to maintain a software application so that it can be run (failing to maintain a "reference" build) would invalidate a patent. A patent could be granted immediately for "everything new and non-obvious" in the submitted software. The initial submission would be relatively inexpensive and wouldn't require a patent attorney. However, enforcement of the patent would require defining what was "new and non-obvious," which is when money would have to be paid to lawyers/experts (same as happens in patent litigation now).
IX. Appendix B: Links
Solution: Patent applicants should be required to provide an example of running software code for each claim in the patent and tell the Patent Office which claims are covered by which lines of that code. Think, for example, of early Patent Office practice requiring the submission of a “model” of the working invention to the Patent Office.
Comments:
I would add to this that the demonstration program be should definitive in terms of setting the boundaries of the scope of the patent. Too often the patent claims are written in the vaguest, broadest language possible so as to maximize potential infringement and prevent workarounds. If the demo program outlined the definitive scope of the patent, then the incentive to write vague overbroad patents goes away.
I want to address differences in computer platforms and why something would or would not be Obvious or nonobvious. There should be a rule in software patent law that doesn't allow a patent to be valid just because the type of computer system or network, etc. is different. I will explain why below. (The requirement of non-obviousness essentially means that the invention must not be an obvious variation or combination of subject matter previously known. http://www.dougweller.com/novelty.html) Some technical jargon I may or may not have correct... my lay understanding is roughly that any Turing Machine/Von Neumann machine can emulate any other. My point, which might not be clear is that any computer can emulate any other. Any computer can do something in software that any other computer could do -- THUS -- based on the issue of Novelty and Non-obviousness, if something has been done in prior art on one platform (in software) doing this on a different platform should be NON Novel and clearly Obvious. Thus any platform-specific software patents should be invalidated and there should be a review process for removing any existing patents which would violate this rule. If a particular inventor feels this basic tenet of computer science doesn't apply to their "invention" and desires some form of redress a neutral three-person expert panel would need to be certified as experts and brought into an appropriate hearing at the PTO to give testimony and to certify why a particular software patent is novel and Non-obvious.
The overall proposal by the EFF is excellent however it doesn't address one of the key points of failure for the PTO; that failure point is searches for Prior art. The PTO doesn't have the right databases nor the proper training to find and identify prior art (according to many insiders). Given the detailed level of domain expertise required to find and evaluate prior art, there needs to be crowd sourced review process. I am proposing a two-level review which will accept comments from the general public as well as from member of a class of accredited peers. My vision is: Tier 1 would be open to anyone but not binding on the PTO. Tier 2 members would accepted based on review of credentials (set by peer committee and PTO). Any prior art indicated by Tier 2 members as well as any Tier 1 art endorsed by a Tier 2 member would have to be addressed by the PTO before any valid patent is issued.
We need to efficiently locate patents which we are in danger of infringing. This is the 'Notice function' of property, which in "Patent Failure" Bessen and Maurer correctly state is failing in the case of patents. As noted by Lee and Mulligan in "Scaling the Patent system", software patents are not indexable in the same way that you can index chemicals by their chemical formula. In fact, indexing software is impossible in the general case (if you could do it, you could also solve the halting problem!). I have been thinking about a system along the following lines: Imagine that at a given point in time, the patent database included not just the individual patents, but a '20 questions' style index, whereby any patent could be located. Crucially, no patent could be enforced against anything outside the 'bucket' in which it is indexed. (A patent could be indexed in more than one bucket, but only by paying the fee for each.) This would have two effects: first, it would be a lot easier to find patents you are in danger of infringing. Second, the boundaries between buckets would be defined much more precisely than those of an individual patent. Why? When drafting a patent, the incentives are to make it as vague as possible. But in the case of the buckets, the incentive is more like drawing a boundary line in real property: because the line affects those on both sides, one's loss is the others gain, so each pushes to make sure his own property is clearly demarcated. Such an index would have to be rebalanced every so often, like a binary tree. So patent owners would need to monitor where their patent had been moved to. Ironically, patent lawyers may actually like that - it would involve them in more work.
The problem is not simply that too many patents don't involve running code, but that even the ones that do are not limited to the actual solution the patentee came up with. The patent claims are written in broad functional language, so that the patentee owns ANY solution to the problem, not just the one they provided. There is a simple legal fix to this: require software patent claims to be limited to the actual solution disclosed or its equivalent. My paper "Software Patents and the Return of Functional Claiming" discusses the problem and how to solve it.
The proposal states that "applicants should be required to provide an example of running software code for each claim in the patent." I'd be happier if the proposal used the language of patent law rather than the colloquial phrasing that it uses because then I would feel more confident that the proposer actually knows what he is proposing and why it is wrong. One of the requirements of getting a patent is that the patent must be enabled. There are two ways to enable a patent, those being actual enablement and constructive enablement. A patent is actually enabled by a working invention. A patent is constructively enabled by a description of how to practice the invention, but lacks a working invention. A blueprint is a constructively enabled house. It describes how to build a house, but usually does not actually come with a house. A house is an actually enabled house. If you were to purchase one of those, the blueprint would generally be cheaper than the actual house, but that is not to say that architects cannot be paid for creating blueprints at all. In terms of patent law, the proposal here is to disallow constructive enablement of patents, but only for software. Ask two questions. First, what purpose is served by constructive enablement, both generally for patent law as a whole and for software specifically? Understand what you're throwing out before you throw it out. Second, what is special about constructive enablement as applied specifically to software? Understand whether it makes more sense to figure out how to fix constructive enablement system-wide rather than just applying a (probably ill-considered) ban on constructive enablement for exactly one specific type of invention.
When submitting code, one alternative is to submit compiled object code which is executed by a reference hardware/OS combination. The reference hardware/OS can be provided by open source communities and by private OS builders (Microsoft, Apple, BlackBerry). The reference hardware/OS would have an emulator which would have to be maintained over time, so that people could go to the USPTO and run applications on the emulators. Hardware/OS providers have an incentive to maintain these reference environments, because doing so would attract developers to the platform and because it would greatly reduce troll activity. Source code could also be provided, but in an encrypted form, for use during (rare) litigation. The "reference" environments would have to include "dummy" client/server units with which the software interacts (most software patents involve multiple third party components), but these can be built showing test interactions and don't have to be a real client/server. Failure to maintain a software application so that it can be run (failing to maintain a "reference" build) would invalidate a patent. A patent could be granted immediately for "everything new and non-obvious" in the submitted software. The initial submission would be relatively inexpensive and wouldn't require a patent attorney. However, enforcement of the patent would require defining what was "new and non-obvious," which is when money would have to be paid to lawyers/experts (same as happens in patent litigation now).
IX. Appendix B: Links
Copyright 2014-2015 by Dennis O'Reilly/Rag Hall -- All rights reserved.