Posts Tagged: "computer software"

Mark Cuban, a software patent troll who hates software patents

While hedging risk is a well known and widely accepted investment tactic, there is something rather bizarre about someone who is such a vocal critic doing exactly what they criticize others for doing.

Mark Cuban: “Get rid of all software patents”

A dim view of software patents does not make Mark Cuban unique, but his latest foray into the patent debate does provide interesting insights into his arbitrary views on innovation. Like your technophobic grandfather, Cuban seems to believe that innovators are entitled to patent rights as long as the innovations are tangible. When those innovations manifest themselves in the form of intangible software the underlying innovation is for some reason no longer entitled to patent protection. Surely Cuban has to realize that this self balancing scooter could accomplish the same exact functionality if the control logic were software based, right?

It makes no sense for an algorithm to be unpatentable simply because it is implemented in software

KAPPOS: “Back when I was an engineer we saw it in mainframe computers where you’d make an invention and frequently initially the software wasn’t fast enough to be able to run the algorithm. So the algorithm would first be built in silicon, really expensive, but you’d wind up then fabbing up chips to be special purpose chips to run the algorithm. And then later as the software got faster the underlying computer systems got faster you’d reimplement the same algorithm in software, same algorithm, same invention but just reimplement it in software and then even later after that when the ASIC density got good enough you’d reimplement yet again in an application-specific integrated circuit, an ASIC. And so you’d have a little bit of a hybrid, if you will, but more on the hardware side, it’s an IC. It’s again putting the algorithm in a chip. And so what you’d see by looking at that is that it made no sense to say that an algorithm was patentable if it was implemented in a hardware chip. But the same algorithm implemented in software was unpatentable. Just didn’t make sense to say that.”

The Case for Software Patentability, An Interview with David Kappos

KAPPOS: ”Companies like Microsoft and Apple and GE — all of whom are members [of the Partnership for American Innovation] along with IBM, Ford, DuPont and Pfizer as well as smaller companies like Many Worlds and Second Sight — all of them are engaged in the hard work of making major, I’ll call it bone-grinding innovations. Second Sight is literally coming up with electro mechanical and implantable human interfacing medical technology that enables blind people to see. And like you said, Gene, serious software development involving lots of super smart people and putting in tremendous amount of time with a lot of specialized expertise, devising solutions to very important problems. You know, enabling blind people to see — it’s hard to imagine a more tangible, practical and important problem than that.”

Software Patents and Murphy’s Law: Uncertainty is Where Patentability Resides

It is not as easy to get software patents as it once was, but software is still patent eligible in the United States. Broadly speaking, software patents are any patents that covers a computer implemented process.

Picking winners and losers based on innovation design is unsound, unwise, and just plain stupid

On some basic level everything can be characterized as an idea. It is also all too easy for those who are not technically trained to believe, no matter how wrongly, that implementation is a trivial or ministerial act. Just monitor the windmills, if they are operating at a less than optimal level adjust them, tilt the blades a little. No big deal. Anyone could have thought of that, and a college student could have written the code over a weekend. Moreover, windmills are extremely old technology, so merely applying a computer process to something so old can’t be patent eligible.

Patenting business methods and software still requires concrete and tangible descriptions

The key to obtaining a software patent is to thoroughly describe the system and processes from a technological level. As to Judge Chen explained in DDR Holdings, in order for software patent claims to be patent eligible they must not “merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet.” To be patent eligible claims to software must be “rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks.” Of course, this patent eligible example of software patent claims is extremely relevant for business methods because a naked business method is no longer patent eligible. To have a realistic chance of being patented business methods must be tied to a particular compute technology in a meaningful and substantial way. Said another way, the business method really needs to be performed by and through a concrete and tangible system, where the system and processes are painstakingly described.

John Deere, GM push back against consumer modifications of vehicle software

One of the more active areas during this round of public comments collected by the Copyright Office involves the prohibitions against circumvention for Proposed Class 21, which covers vehicle software for diagnosis, repair or modification. John Deere also suggests that enabling these exemptions could encourage the piracy of copyrighted music or film recordings by tampering with infotainment software systems installed on vehicles. As well, modifying vehicle software to reduce the car’s maximum speed when lending it to a teenager or activate lights when the windshield wipers are turned on, both of which are suggested by John Deere, constitutes commercial activity which goes against non-profit fair use principles used to consider exemptions.

How to Fix the Software Patent Mess: Go Back to Basics

If U.S. patent eligibility rules were more clear and predictable, the useful art of software development would be more prevalent. The “notorious computer” of the European Patent Office offers a viable option for reaching this objective. This approach would make business less uncertain as to whether not their proposed investments in software could receive patent protection. And reducing this risk would promote the future useful art of software development.

1998: Federal Circuit Says Yes to Business Methods

It is really incorrect to say that the Federal Circuit eliminated the business method exception in State Street Bank, although the same net effect admittedly occurred regardless of how you characterize the ruling. It is better to say that the Federal Circuit went out of its way to explain that the business method exception had really never existed in the first place. The court explained that neither it nor its predecessor court, the CCPA, had ever applied the business method exception to a single case. Furthermore, Judge Rich explained that the cases relied upon to support the existence of the business method exception were In re Maucorps and In re Meyer were both rendered prior to the Supreme Court’s decision in Diehr, and prior to the Federal Circuit’s abandonment of the Freeman-Walter-Abele test. Furthermore, the Maucorps and Meyer cases were decided not on the business method exception, but on the mathematical algorithm exception.

I Thought Banks Didn’t Like Financial Software Patents?

The big banks have backed Schumer for years, which makes sense since he is the senior Senator from the States of New York, which is where all the bankers are located (i.e., on Wall Street). But given all the vitriol aimed at software patents, particularly those in the financial services sector, there is a real irony that big banks are able to get software patents that explicitly cover computer implemented methods in the wake of Alice v. CLS Bank when so many others aren’t. So much of this anti-software patent hysteria was started by the big banks but they seem unaffected. That is an unfortunate theme in America. The big banks on Wall Street destroyed the economy with reckless disregard and yet not a single person went to jail and big bonuses continued to be paid to the very bankers and executives responsible for the economic meltdown that lead to the Great Recession.

Federal Circuit Finds Software Patent Claim Patent Eligible

Of particular interest, the Federal Circuit found that the ‘399 patent constituted patent eligible subject matter, was not invalid and was infringed. This is big news because in the wake of the Supreme Court’s decision in Alice v. CLS Bank software patents have been falling at alarming rate. Assuming this decision stands any further review we finally have some positive law to draw from that will provide clues into how to tailor patent claims to make them capable of overcoming what has become a significant hurdle to patentability— namely the abstract idea doctrine. Of course, Judge Mayer was in dissent.

Freeman-Walter-Abele: A Tortured History of Software Eligibility

The influence of the thinking behind Freeman-Walter-Abele can also be seen in the Supreme Court’s decision in Alice. Thanks to Alice the focus is now on whether the claims cover an abstract idea or concept, and in order to make the determination we are not supposed to look at the language of the claims, but rather to look through the claims. This causes the apparatus claims to rise and fall with the method claims despite the fact that machines are clearly patent eligible according to the terms of the statute. Further, as the law associated with software developed the industry, with good reason, thought that it would be enough to say that the process steps had to be carried out on a machine (i.e., a computer). That clearly isn’t enough after Alice. While the Supreme Court hasn’t adopted the Freeman-Walter-Abele test, and the current articulation of the test is couched as whether the claims cover only an abstract idea, it does seem that if patent claims could be written to satisfy the moving target of the FWA test then the patent claims should work to satisfy the Alice test that adopts the Mayo framework.

The History of Software Patents in the United States

Software patents have a long history in the United States. Computer implemented processes, or software, has been patented in the United States since 1968… Originally in Benson, the Supreme Court decided that software was not patentable, but then later retracted the blanket prohibition against patenting software in Diehr. The Federal Circuit then spent the better part of two decades trying to figure out under what circumstances software (or computer related processes) should be patented. This seemed to culminate in the 1998 ruling of the Federal Circuit in State Street Bank & Trust Co. v. Signature Financial Group, Inc. Unfortunately, the waters were once again made murky as a result of the 2008 ruling by the Federal Circuit in In re Bilski. Some questions were answered when the Supreme Court issued its ruling in Bikski v. Kappos in 2010, notably saying that business methods are patent eligible, but the Supreme Court did not definitively say that software is patent eligible. Then in June 2014, the Supreme Court issued a decision in Alice Corporation v. CLS Bank, which has for the time being slammed the door shut for many, if not most, software patents.

Software Forensics: Qualifying Tools and Experts Who Use Them

One of the big reasons there is such a need for software forensics is to interject objectivity into what is otherwise a battle of experts who are supposed to be unbiased but who may be strongly influenced by, if not outright pressured to support, the positions of their clients. This is just as true of experts in other areas of litigation, but as more complex technologies are at issue in today’s IP cases, lay judges and juries are less capable of weeding through technical intricacies to weigh opposing views of experts. Compounding this reality is the ever increasing popularity of police dramas on television, which elevate the desire for juries to have some kind of objective information they can rely on; something of a smoking gun if you will. Software forensics can often provide that smoking gun and cut through the haze. But the question remains, how do we assure that software forensic tools are reliable and consistent and that the expert witnesses who use them are qualified and honest about their analyses?