According to news reports, flamboyant billionaire Mark Cuban recently engaged in patent saber rattling, threatening to sue Wal-Mart for patent infringement as the company has come forth with announced plans to start selling a popular self balancing scooter. In a comment from Cuban on our earlier article on the topic (which he verified was actually him on his official Twitter account) he said he made no such threat. Cuban’s comment on IPWatchdog.com explained not that he would sue Wal-Mart, but that someone, such as a patent troll, would sue Wal-Mart for their plans to sell a version of a self balancing scooter.
Regardless of whether Cuban did or did not threaten to bring a patent infringement lawsuit against Wal-Mart, the comment Cuban left on Monday reiterates his long standing belief that software patents should not exist. Cuban explained that his position on software patents has not changed, nor will it change. Software patents should not be issued. He went so far as to say that he would open up the IP he owns that covers the self balancing scooter if software patents are banished. “Get rid of all software patents and I will HAPPILY put all the new IP we develop for the boards In the public domain,” Cuban wrote.
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.
To highlight the matter let’s take a look at the patent to which Cuban owns an interest — U.S. Patent No. 8,738,278, titled Two-wheel, self-balancing vehicle with independently movable foot placement sections. The ‘278 patent has nine patent claims total, one of which is independent and the other eight of which either directly or indirectly depend on claim 1. Claim 1 covers the following invention:
A two-wheel, self-balancing vehicle device, comprising:
a first foot placement section and a second foot placement section that are coupled to one another and are independently movable with respect to one another;
a first wheel associated with the first foot placement section and a second wheel associated with the second foot placement section, the first and second wheels being spaced apart and substantially parallel to one another;
a first position sensor and a first drive motor configured to drive the first wheel, a second position sensor and a second drive motor configured to drive the second wheel; and
control logic that drives the first wheel toward self-balancing the first foot placement section in response to position data from the first sensor and that drives the second wheel toward self-balancing the second foot placement section in response to position data from the second foot placement section.
Those familiar with patent claims and software might be taken back by Cuban’s strong dislike of software patents when the patent he controls contains a “control logic” limitation. Such a limitation ordinarily smacks of software. Is it really possible that Mark Cuban thinks software patents shouldn’t exist but is at the same time comfortable with the ‘278 patent? While a lot of Cuban’s positions on patents seem explainable based on the philosophy that the problem is with patents owned by others, there is a bit more nuance at play here. Indeed, nuance that is rather illuminating.
The Detailed Description of the patent in question doesn’t spend much time discussing the structural implementation of the control logic, which will be problematic during any enforcement action or subsequent post grant review of this particular patent, but it does seem that the ‘278 envisions a hardware based control logic platform, not a software based control logic platform. The patent explains:
The control logic for translating position data to motor drive signals may be centralized or split between the two platform sections. For example, control logic 150 may be electrically connected to sensors 120,140 and to drive motors 117,137, electrical conduits connecting through the connecting shaft 170 between sensor 140, control logic 150, and drive motor 137.
Alternatively, a separate processor/control logic 151 may be provided in the second platform section 130. Logic 151, in this case, would be is connect directly to sensor 140 and drive motor 137 and generate drive signals to motor 137 (and wheel 135) based data from sensor 140.
Perhaps Mark Cuban is not guilty of hating software patents owned by others and loving software patents he controls, but the matter can’t end there. This type of hair splitting, self-serving, arbitrary view completely exposes the absurdity found with software patent hatred. Those who hate software patents, presumably including Mark Cuban, seem to have no problem when the processes are directed by hardware, but for some inexplicable reason when the processes are directed using software that which was a worthwhile, original innovation is transformed into something unpatentable, if not evil.
Surely Cuban has to realize that this self balancing scooter could accomplish the same exact functionality if the control logic were software based, right? Indeed, if Wal-Mart wanted to copy the self balancing scooter found in the ‘278 patent without any fear of patent infringement liability all they would have to do is implement the core functionality in a software solution, rather than a hardware solution. I wonder if Mark Cuban would feel the patent system failed if such a purposeful and intentional copy could be sold without rights obtained under the ‘278 patent? Of course, that is precisely the problem with glorifying a distinction without a difference. In this case the design choice can manifest either in hardware or in software, but that doesn’t change the reality that the invention in question is a self balancing scooter.
Can or should a design choice made with respect to the implementation of core processes matter in a patentability context? Of course not. Former USPTO David Kappos recently addressed this very issue in an interview we published here on IPWatchdog.com. In part 2 of our conversation Kappos explained just how artificial the distinction between hardware and software processes are:
What we’re really talking about is algorithms that actually may or may not be implemented in software. It’s actually common, and you’re seeing it now in the smartphone area. 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.
Microsoft’s Chief Patent Counsel, Micky Minhas, also brought up this point during an interview conducted earlier this year. In part 2 of my conversation with Minhas the discussion turned to design choices for implementing an innovation.
QUINN: … What many people not familiar with software don’t seem to understand is that whether an innovation is expressed in software or hardware is a design choice. But if it is designed in hardware we don’t have a patent eligibility issue, where if it is designed as a software solution there is a significant hurdle to patentability.
MINHAS: Yes. In the debate, we often hear people talk about what is the right level of protection for software patents. And I think what gets lost sometimes is that how a given company or any inventor decides to embody an invention, whether in a software product or to embody the invention in a hardware product, is often nothing more than a design choice. Whether an innovation is embodied in software or hardware feels like it should be irrelevant to whether or not it’s patentable. The law should be agnostic as to whether it’s embodied in software or hardware. We should let the debate be whether or not this invented concept is worthy of patent protection, whether it be on subject matter grounds or whether it be on 102 or 103 grounds. I don’t see that being discussed very often, but I think it should.
Minhas would go on to take issue with critics who sometimes claim that implementation choices are arbitrary themselves. “It’s optimized for whatever that product is.” Minhas explained. “The determination of whether or not that underlying compression algorithm is worthy of patent protection should be completely independent of whether it is implemented in hardware or software.”
There is no reason to be afraid of software. Similarly, there is no legitimate reason to create an arbitrary patentability distinction that exalts tangible processing at the expense of intangible processing. Such a distinction without a difference turns the focus away from whether there is an innovation present, which is antithetical to the very purpose of the patent system.
In the year 2015 there is something enormously out of touch with driving old fashion technical prejudice into an innovation discussion. Those who think hardware and software processing are meaningfully different are fooling themselves and standing in the way of innovative advances like so many previous generations of those who were afraid to technologically evolve.