> Clearly we have both had miraculous enlightenment because legally this is “not obvious”.
To be precise, legally it is "not obvious back in 1996." There is a lot of stuff that is obvious today that wasn't 25 years ago. That said, this one in particular probably would have been invalidated as obvious if it was ever litigated (and it was not). Also, the USPTO has reined in software patents a lot in recent years (but always people advocating for more or less).
The patent issued in 1996 and wasn't revisited since then (because never asserted in litigation). The USPTO is a lot different now, a quarter-century later.
I don't think that's the point the commenter was making. The analogous situation would be if someone posted that they made their kitchen table from scratch, and the commenter said that it's great but not everyone has a lathe in their basement, so good that places like Ikea exist as well.
For what it's worth, this isn't limited to invalidity. For example, ITC findings that a product infringes also are not binding on courts. The reason for all this is that the ITC is an administrative agency rather than an Article III tribunal.
You can, and everyone always does, litigate invalidity before ITC. (I am an IP litigator who has done it.) Note that the ITC cannot itself invalidate patents like district courts do, but they can--and often do--decline to issue an exclusion order because they believe the patent at issue is invalid.
> big tech firms got big and stay big, not because of network effects or political power, but because of their rare expertise; and that they cannot keep their advantage in expertise forever
I am pretty sure Facebook got and stays big primarily because of network effects. You could create a website with all the technical features of Facebook, and few would use it because their friends aren't on it.
In my view, it is the pendulum of antitrust law swinging back to stricter enforcement that will end big tech, if at all. The hope that everything will just magically get better now that your local coffee shop can deliver beans to you with off-the-shelf software seems slightly optimistic.
I left software engineering and became a litigator at one of the big U.S. law firms for the last decade. Here are some thoughts based on my experience.
First, although a technical degree is generally required to become a registered patent attorney, there are a lot of people who do patent and other IP litigation without technical degrees. Software comes up all the time in cases, and being able to read source code is a big advantage.
Second, I firmly believe that programming wires your brain in such a way that makes you good at law school and subsequent practice. The law is really a very detail-oriented endeavor. There is just something about stressing for years about whether there is a missing parenthesis or whatever that exercises your brain in the same way that looking for loopholes in a contract or whatever invokes.
That said, at least in the U.S., the biggest decider of your early success in law will be your LSAT score and undergrad GPA. If you think you might be interested in law, just take the test, estimate what schools you could get into, and then do the cost-benefit analysis with that additional information.
Just to say more on this quickly, the relevant inquiry is not "does software progress without patents, yes or no?" Obviously it would. But the relevant inquiry is whether we have made more or less progress now than we would have had software patents not existed for the last 70 years.
For what it's worth, I tend to agree with the ultimate conclusion that software patents today do more harm than good. But if you want to convince policy makers, you have to address the issue on a less superficial level. And that means actually acknowledging the other side's arguments and rebutting them with evidence or counterarguments.
> GNU/Linux
Free software such as the GNU/Linux and FreeBSD operating systems were developed without software patents. 91% of the top 500 super computers run GNU/Linux.
This is misleading. Linux has all sorts of stuff in it that used to be under patent protection but isn't anymore because the patents expired. The entire argument for patents is that they incentivize both the creation of new things and the public disclosure of them, with the idea that eventually they will become part of the public domain. There is a complicated cost-benefit analysis here that has been studied by academics for years, which the FSF just ignores. This is fine if you view this as an advocacy piece, but not fine if you want to actually learn something about the issue.
Honestly, the worst part about Debian is the name. Everything is deb-this and deb-that. Packages are .deb. Which is his ex-wife. Can you imagine getting a divorce and then for the rest of your life have this massive thing associated with your ex and will never go away be named after you? Yick.
Patent lawyer here. There is a lot of dubious stuff already in this thread, so be careful with legal opinions from people on the internet.
Some relevant claim language is below. Of course a lot of this stuff has been known for a while, but you have to have everything together--or an evidenced argument that combining things in this way would have been obvious--before you can conclude anything about the validity of the patent. And on unpatentable subject matter (i.e., being an abstract idea), there is a pretty good argument that this improves the functionality of the computer, not just uses a computer to do something known, which recent cases have started using as the de facto dividing line.
1. A system comprising:
one or more computer processors;
one or more computer memories;
a set of instructions incorporated into the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations for automatically managing a set of memory chunks within the one or more computer memories at runtime for a computer application, the operations comprising:
receiving a set of entities from the computer application, each of the set of entities including a set of components, wherein each component of the set of components has one type of a set of types;
classifying the set of entities into a set of archetypes, each archetype representing a different count of the set of components or a different combination of types of the set of components relative to other archetypes of the set of archetypes;
based on a determination that one of the set of archetypes corresponds to a new archetype, building a new memory chunk, adding the new memory chunk to the set of memory chunks, and populating the new memory chunk, wherein the populating of the new memory chunk includes adding data from the set of components included in one or more entities of the set of entities that are classified under the new archetype, the adding of the data including contiguously adding the data to ends of a set of component data arrays included in the new memory chunk, each of the set of data arrays included in the new memory chunk corresponding to a respective component of the set of components included in the one or more entities that are classified under the new archetype.
> It is not even theoretically possible to write a piece of software which will behave the same no matter how and where it is run.
Can you elaborate on that? I'm sure it's both true and false depending on your definition of "how and where it is run," but wondering what you had in mind specifically.
To be precise, legally it is "not obvious back in 1996." There is a lot of stuff that is obvious today that wasn't 25 years ago. That said, this one in particular probably would have been invalidated as obvious if it was ever litigated (and it was not). Also, the USPTO has reined in software patents a lot in recent years (but always people advocating for more or less).