SOFTWARE patents are certainly a dying breed of patents in the United States, especially after Alice. Those who deny these trends are typically lobbyists of the software patents interest groups/profiteers. This report which was authored by Charles Bieneman, says that even the Court of Appeals for the Federal Circuit (CAFC), originator of software patents in the United States, walks back on the issue and "Maintains Unpredictability of the Law of Patent-Eligibility". To quote Bieneman: "The Federal Circuit vacated a summary judgment of invalidity under 35 U.S.C. €§ 101 after disagreeing with a district court that claims of U.S. Patent No. 7,604,929 were “directed to a patent-ineligible law of nature–that hepatocytes [liver cells] are capable of surviving multiple freeze-thaw cycles–and that the patented process lacks the requisite inventive concept.” Rapid Litigation Management, Ltd. V. Cellzdirect, Inc., No. 2015-1570 (Fed. Cir. July 5, 2016). Reading this case for broader lessons on Section 101 validity – as I read all cases that implement the Mayo/Alice patent-eligibility test – the main lesson to be drawn here is that outcomes under Section 101 remain highly situational. Patent-eligibility determinations, even more than other questions of patent law, frustratingly depend on the context of the litigation, specific words that may or may not be included in a patent claim, and, let’s be honest, the particular judge or judges hearing the case."
"The courts which actually count and are not known for corruption quite unequivocally reject software patents."At the CAFC, as noted here many times before, trial misconduct is common. It's a corrupt process. Consider the recent BASCOM case which is still mentioned in the news this week. SCOTUS, which bypasses CAFC, continues to reject challenges to Alice, e.g. the Sequenom case -- a subject which was also revisited earlier this week. The courts which actually count and are not known for corruption quite unequivocally reject software patents.
Europe, on the other hand, risks going in the very opposite direction.
According to last week's blog post from Cambridge Wireless Blog (based in the UK), "not all software is patentable, and never has been. But this is generally true: not everything is patentable. As straightforward examples, you cannot patent a piece of art, or a book, or a theme or story for a book, say. These are regarded as “non-technical”. Likewise, you cannot patent a pure business method, again in essence because they are regarded as “non-technical” and for policy reasons. You also cannot patent “scientific theories” or “mathematical methods”, again essentially for policy reasons: no-one should be allowed to patent what is already “out there”, waiting for humans to uncover it."
""fluffy" software is not patentable but "hard" software is," Benjamin Henrion noted about the premise of the above. "There is no such thing as hard software," he added. This is perhaps where the EPO loophole comes into play. If one pretends that the software is tied or combined with a device, then suddenly the software is deemed patentable. Another loophole for software patenting in Europe has been FRAND. We wrote about this for nearly a decade. FRAND has been a vector of software patents injection into standards, even where software patents are not at all valid. "FRAND And The Clash Of Industries," an article published earlier today, says the following:
They use open source licenses to handle the copyrights and patents, community governance to handle trademarks and other patents and public benefit entities to protect everyone from everyone else. Each participant in the collaboration works at their own expense in order to achieve a shared outcome that benefits all, including themselves. When they create an enhancement, fix a defect, participate in a design, they are not “working for free” or “donating their work” so much as they are “participating in co-development”. It’s a new way to leverage IP for greater benefit than directly monetising its scarcity.
[...]
But that’s not the case in markets where collaboration happens at the level of specifications and de jure standards rather than code and de facto standards, such as the telecommunications industry. Decades of comfort with SEPs and FRAND terms have resulted in a heavy investment in patents licensed in such a way that they create mutually-assured control. Telecommunications standards are so heavily encumbered with SEPs that patent pools and cross-licensing have become the norm. That in turn has created a barrier to newcomers that has made the telecommunications industry a cartel of giants.
That cartel of giants now sees its mesh of complex physical technologies coming to a lifecycle point where software dominates. The rise of apps and smart devices for the user and of software-defined and implemented infrastructure for operators, means that there is more and more of an incentive to move in to the computer and software technology markets. This in turn has created an impetus to adopt the working practices of that industry, which notably today means collaboration over shared implementation rather than just over mutually essential specifications. As a result, they seek to introduce open source into their business.
[...]
So will we create a new opportunity with regulations like EIF, or allow an existing industry to hobble another as the two collide? That’s the real question about FRAND terms for SEPs. Trying to force-fit FRAND into open source by mistakenly asserting it’s just a matter of compliance is sure to fail. Despite the name, FRAND is always discriminatory.