4 ms·
Good points. However, I think 35 USC 103 (non-obvious requirement) could be used knock out the X plus Computer claims these days. E.g., If X is not novel and
by pnw_hazor 6y ago
Good points.
However, I think 35 USC 103 (non-obvious requirement) could be used knock out the X plus Computer claims these days.
E.g., If X is not novel and computers are not novel -> no invention because it is obvious to combine them.
Also, I agree that USPTO (and courts) should require more proof of invention/implementation. This could be handled by increasing the requirements for meeting 35 USC 112 (enablement). For example, I think it would reasonable to require more explicit disclosure of pseudo code, data structures, protocols, sequence diagrams, state machines, experimental proof of claimed performance improvements, and such. Quality software patents tend to have a lot of this stuff already. The idea here is to prove the inventors have actually invented the innovations they are claiming not necessarily restrict the invention to one particular data structure or protocol.
Some bio/chem patents have additional requirements when compared to gadget patents. Software patents could be improved similarly.
I would also be open to considering changes in the length of patent terms for certain types of software patents. Not sure how that rule would work though, because there really is no such thing as a software patent. Inventions in so-called software patents are usually described as being part software and part hardware with the assertion that some or all of the software parts could be implemented as hardware or vice versa.
We got into this current mess, because courts latched on the subject matter arguments instead of looking harder at novelty, non-obviousness, and enablement. I am not sure why they didn't rely on obviousness more when they started down this path. The early software patent cases screwed things up back when no one knew how to handle them.
- Natsu 6y ago> E.g., If X is not novel and computers are not novel -> no invention because it is obvious to combine them. This is a fair point, but 'novel' seems to get read as 'someone has already patented this before'. > This could be handled by increasing the requirements for meeting 35 USC 112 (enablement). This is also reasonable, enablement right now is kind of a joke, higher standards for that would generally be good. I'd like to see any working implementation of the claimed invention in software for patents that include that. It need not be a fully formed app, but it should compile and demonstrate whatever is claimed, IMHO. > Some bio/chem patents have additional requirements when compared to gadget patents. I don't claim to have read many patents in that area, but I'd expect that bio/chem patents should have to give the chemical formulas and synthesis, which should do a lot for enablement. > I would also be open to considering changes in the length of patent terms for certain types of software patents. Not sure how that rule would work though, because there really is no such thing as a software patent. Yeah, I know there are complications on defining 'software patent', but generally we understand when someone patents a process performed on an ordinary computer or something similar. > The early software patent cases screwed things up back when no one knew how to handle them. They're trying too hard to preserve existing precedent while moving in a new direction. I agree that they need to reform some of those factors to get to a better place and that the existing rulings just aren't very clear. Reading the EFF's article, it sounds like they want to take a tact much like the one I want. I just wish the Supreme Court had written a clearer holding.