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.).
> If software represents a "process," what exactly is "processed?"
Class 719:
A coherent sequence of steps undertaken by a program to manipulate data such as an internal or external data-transfer operation, handling an interrupt, or evaluation of a function.
> Basically, the only meaningful way to patent software is to have a patent that covers infinitely many "processes," ...
No. There are the judicial exceptions: law of nature, natural phenomenon, or abstract idea. Really, the software patents you don't like are covered by the abstract ideas exception.
Basically, I don't think I'll change your mind and that's ok. But I do want to know how you expect to incentivize software developers to take risks without protecting their work?
"A coherent sequence of steps undertaken by a program to manipulate data such as an internal or external data-transfer operation, handling an interrupt, or evaluation of a function."
Except that the sequence itself is poorly defined, as it depends on the particular language used, the particular compiler and compiler flags used, how the software is run, etc. This is true for all software; so if you want to patent software you would need to specify all the above, which would be almost pedantically narrow.
"Really, the software patents you don't like are covered by the abstract ideas exception."
What I stated is true for all software, so I guess I do not really understand what other software patents you are referring to. At most all I can see is a patent on some larger machine that happens to use some software e.g. in a microcontroller, but that does not seem like a "software patent" as most people understand the term.
"I do want to know how you expect to incentivize software developers to take risks without protecting their work?"
First of all, patents are one of the three ways developers typically "protect" their work. Copyrights and trade secrets are a much better fit for this ___domain.
Second, I cannot think of any software innovations that would not have happened without software patents. In almost all cases the patents seem to just be after thoughts that some corporation or university insists on, without having much relevance to the willingness of innovators to try new things. Patents are completely irrelevant to open source software, and major breakthroughs tend to be announced in academic venues long before patents are granted.
Finally, in almost all cases I personally deal with (as a cryptographer), patents only slow the pace of innovation and are actively harmful to our ability to actually deploy innovations. Just the other day I found out that a technique I have seen used in dozens of research systems was patented, and therefore too risky to use in any real-world system -- the latest in a long line of such patents. Put simply, software patents hamper our ability to innovate far more than encourage it; software patents have always been a drag on crypto, going all the way back to the early patents on PKE and RSA.
I think Diffie Hellman Merkle key exchange was a brilliant idea and an awesome patent. I understand that the Brits had discovered it in secret but didn't have the compute power at the time. That actually didn't invalidate it; the interplay between trade secret and patents is not one sided either way.
Diffie Hellman Merkle was assigned to and prosecuted by Stanford as was Larry Page's PageRank patent. I do not think Stanford or other universities (non-practicing entitites really) would develop so much IP if they didn't get something substantial back.
Yes, it is the nature of the limited monopoly of patents to both impede and incent. It is the rare patent, Diffie Hellman Merkle key exchange was rare, that is truly amazingly novel. Most patents are incremental and society benefits from the increment.
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.).