4 ms·
The "on a computer" trick doesn't work post 2014. Alice v. CLS Bank killed it. Business method + a computer now gets you into an art unit with a sub 5% allowa
by josaka 9y ago
The "on a computer" trick doesn't work post 2014. Alice v. CLS Bank killed it. Business method + a computer now gets you into an art unit with a sub 5% allowance rate. http://www.bilskiblog.com/blog/2016/06/two-years-after-alice-a-survey-of-the-impact-of-a-minor-case-part-2.html http://www.bilskiblog.com/blog/2016/06/two-years-after-alice...
- betterunix2 9y agoSo what is the new trick? Software patents are still being granted and the nature of software (as a kind of math) has not fundamentally changed.
- _rpd 9y agoNow you need to have "significantly more" than being implemented with a computer. Opinions differ over exactly what this means.
- CalChris 9y agoSignificantly more was Thomas writing in a rare Supreme Court patent decision. The Supremes aren't going to draw this line certainly not in a single case. The DC Court of Appeals hears 100s of patent cases and they'll draw that line with case law.
- johncolanduoni 9y agoWhy do you think software is more "a kind of math" than e.g. mechanical engineering?
- betterunix2 9y agoOther than convenience, does it make a difference if you evaluate an algorithm by hand (e.g. with a pencil and paper) versus using a computer? I assume you have at least used the addition, subtraction, multiplication, and division algorithms on paper at some point in your life -- the results are the same (up to human error) as they would be if you wrote a program that did the same operations. It does not matter how you compute something, all that matters is what you compute. Writing an algorithm on paper is just as good as writing it using Emacs in some programming language. There is also the question of representations. How you represent an algorithm is not terribly important, and programmers routinely convert one representation of an algorithm to another (e.g. with a compiler). One representation available for any algorithm is a lambda expression, and there is not much room for arguing about whether or not lambda calculus is a field of math (it absolutely is, especially when you consider typed lambda calculus). For mechanical engineering, simulating something on paper is not the same as building it, and the particular materials, shapes, etc. that you use in a mechanical system make a big difference. There is math involved in ME, but the math is not the final product. Yes, some ME work today is purely algorithmic, but that is just overloading the term "mechanical engineering" to cover a particular subset of CS that is of interest in ME.
- CalChris 9y agoRewording that, other than convenience, does it make a difference if you manufacture a widget by hand or with a machine? Utility classes. Utility patents, issued under 35 U.S.C. 101, protect any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. Software is a process. Now there are judicial exceptions: laws of nature, natural phenomena, and abstract ideas The business method patents getting nuked by Alice [1] are abstract ideas tied to a computer with a shoestring. The software patents getting issued by Enfish [2] "improve the functioning of the computer itself". Stallman, as always, is too simplistic. [1] https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_International https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_Intern... [2] https://en.wikipedia.org/wiki/Enfish,_LLC_v._Microsoft_Corp https://en.wikipedia.org/wiki/Enfish,_LLC_v._Microsoft_Corp.
- betterunix2 9y ago"Software is a process" Except that the "process" is poorly defined, as the representation of the software is not actually relevant. Changing the compiler flags will change the process; certainly changing the compiler will. Writing the same algorithm in a different language will change the process, in some cases dramatically (e.g. an imperative language versus a declarative language). Evaluating an algorithm by hand will involve a very different process than using a mechanical computer, which will be different from using an electronic computer. An algorithm is an abstract idea, and it can be expressed or evaluated in infinitely many ways (this is well known). An algorithm can "emerge" from a system unintentionally, as an abstract consequence of a system (template metaprogramming in C++ is an example -- it was an unintended consequence of how templates are processed). If software represents a "process," what exactly is "processed?" Different representations of an algorithm can have totally different input/output encodings, intermediate states, etc. It is the same algorithm regardless, certainly for the purposes of a software patent (otherwise the patent would be pointlessly narrow and very easy to evade). Basically, the only meaningful way to patent software is to have a patent that covers infinitely many "processes," without regard to the specific intermediate steps of the "process" or even to the particular inputs and outputs (just their abstract "meaning"). In other words, what is patented is the possibility of some particular computation -- which is exactly how software patents play out in practice. That is an abstract, mathematical idea, "tied" to "a computer" that is completely hypothetical (what CPU architecture? what hardware configuration? etc.).
- amelius 9y agoNot all software is about just "a business method". E.g., compilers, differential equation solvers, linear program solvers, graphics rendering routines, ... Some software is more ingenious than a lot of "mechanical" patents. (By the way, this raises the question why e.g. mechanical engineers can make money using patents, while software engineers could not.)