4 ms·

I don't think that is a problem only with software patents. Even for mechanical patents, say, you could "implement" a mechanism in any of a thousand different a

I don't think that is a problem only with software patents. Even for mechanical patents, say, you could "implement" a mechanism in any of a thousand different alloys as long as they provide the appropriate physical properties required. Or for electronics patents, you could use any of a thousand combinations of various passive or active components to achieve the same electronic properties. Or for drug patents, you could deliver the "active" chemical compound in any of a thousand different coatings. For patents, the specific implementation has always been a secondary consideration (to be precise, for "enablement"), as long as the true "essence" of the invention is protected. It may seem that it's only in software that all ways of achieving an outcome get encompassed by claims, but this may be due to 1) the prevalence of software patents in litigation these days (as evidenced by the GAO report) and 2) the propensity of tech media to trivialize all patents to soundbites without regards to the actual claims, and then proclaim them to be broad and vague. Note that broad and vague patents do exist, in many fields, including software-related inventions. However, in my experience, they are not as widespread as it may seem and, as I said before, getting such broad patents is becoming harder and harder, and has been so since the mid '00s. I don't know what to attribute this to, but one of my hunches is the availability of Google search.

AnthonyMouse 13y ago
>Even for mechanical patents, say, you could "implement" a mechanism in any of a thousand different alloys as long as they provide the appropriate physical properties required. That's not really what I'm talking about. Maybe an example would help. Suppose you're the first to invent disc brakes and you get a claim something like this: A device for decelerating a vehicle comprising: a rotor affixed to a rotating axle of a wheel; a stationary brake pad; and a hydraulically actuated caliper compressing the brake pad against the rotor. So now you want to talk about doctrine of equivalents and say that it doesn't matter what material the brake pads are made of, and maybe you're still covered if the calipers are pneumatic instead of hydraulic, etc. Fine. The problem is that software patent claims don't look like that. The equivalent ends up looking something like this: A method for decelerating a vehicle comprising: an interface allowing a user to request deceleration; a means for converting kinetic energy into thermal energy; and engaging said means for converting kinetic energy into thermal energy when deceleration is requested in said user interface. Do you see the difference? The latter covers disc brakes, it covers drum brakes, it covers drag car parachutes, engine braking, dragging a stick against the ground etc. etc. It covers implementations that have exactly nothing to do with the patentee's invention other than employing the same law of physics in their operation in order to achieve the same result. The way the patent system normally deals with this is that because the second claim covers everything, it doesn't get granted because of prior art. You can't invent disc brakes and get the second claim because drum brakes already exist. The trouble comes when the problem being solved is itself novel, because there is then by definition no prior art solution, so the first person to get to the patent office can get a patent on every possible solution by proposing any possible solution (even if their implementation sucks), since any solution gets you enablement and there is no prior art to invalidate the exceptional claims. So that's half of the issue. The other half is the zero reproduction cost of computer software. Once a problem is solved it's over. You have a good solution and the solution costs nothing to copy infinitely, so soon everyone has the good solution and further solutions to that problem are no longer anywhere near as interesting. In consequence software development is dominated by the process of creating solutions to novel problems -- exactly the scenario that the patent system allows the first mover to massively over-claim. Hence the enormous trouble specifically with software patents.

AnthonyMouse 13y ago

>Even for mechanical patents, say, you could "implement" a mechanism in any of a thousand different alloys as long as they provide the appropriate physical properties required. That's not really what I'm talking about. Maybe an example would help. Suppose you're the first to invent disc brakes and you get a claim something like this: A device for decelerating a vehicle comprising: a rotor affixed to a rotating axle of a wheel; a stationary brake pad; and a hydraulically actuated caliper compressing the brake pad against the rotor. So now you want to talk about doctrine of equivalents and say that it doesn't matter what material the brake pads are made of, and maybe you're still covered if the calipers are pneumatic instead of hydraulic, etc. Fine. The problem is that software patent claims don't look like that. The equivalent ends up looking something like this: A method for decelerating a vehicle comprising: an interface allowing a user to request deceleration; a means for converting kinetic energy into thermal energy; and engaging said means for converting kinetic energy into thermal energy when deceleration is requested in said user interface. Do you see the difference? The latter covers disc brakes, it covers drum brakes, it covers drag car parachutes, engine braking, dragging a stick against the ground etc. etc. It covers implementations that have exactly nothing to do with the patentee's invention other than employing the same law of physics in their operation in order to achieve the same result. The way the patent system normally deals with this is that because the second claim covers everything, it doesn't get granted because of prior art. You can't invent disc brakes and get the second claim because drum brakes already exist. The trouble comes when the problem being solved is itself novel, because there is then by definition no prior art solution, so the first person to get to the patent office can get a patent on every possible solution by proposing any possible solution (even if their implementation sucks), since any solution gets you enablement and there is no prior art to invalidate the exceptional claims. So that's half of the issue. The other half is the zero reproduction cost of computer software. Once a problem is solved it's over. You have a good solution and the solution costs nothing to copy infinitely, so soon everyone has the good solution and further solutions to that problem are no longer anywhere near as interesting. In consequence software development is dominated by the process of creating solutions to novel problems -- exactly the scenario that the patent system allows the first mover to massively over-claim. Hence the enormous trouble specifically with software patents.