Software Patents: Are they really “Soft”—ware?
|Written by Gene Quinn
Patent Attorney & Founder of IPWatchdog, Inc.
Principal Lecturer, PLI Patent Bar Review Course Posted: September 8, 2013 @ 10:45 am
Recently U.S. Patent No. 8,515,829 (the ‘829 patent) came to my attention. It is a patent issued to Google, which is titled Tax-free gifting. See Google Patents Tax-Free Gifting. The invention is interesting in its own right, but as I reviewed the patent I noticed an interesting figure — Figure 14 really caught my attention. Before proceeding to discuss the importance of Figure 14, allow me to provide some background information about this particular patent.
Generally speaking, the invention relates to a system and related techniques for gifting, and paying for, digital content, including media, such as audio and video. The core of the invention, as suggested by the title, relates to giving someone something tax-free. While the title may suggest the invention is potentially nefarious, or at least aimed at exploiting some tax loophole, that is not the case. The government is not going to be cheated out of collecting taxes. Instead, the invention relates to a method that allows for the giver of the gift to pay for the tax imposed by the jurisdiction where the gift (i.e., gift card) is redeemed.
Indeed, Claim 1 in the ‘829 patent specifically includes a limitation specific to the payment of the tax that would otherwise be imposed when the gift is redeemed. Claim 1 recites (emphasis added):
1. A method performed by one or more processing devices, comprising: presenting media content via an audio/visual display to a purchaser; presenting to the purchaser, at a point during presentation of the media content, an option to purchase the media content as a gift; in response to presentation of the option, receiving, from the purchaser, information for purchasing the media content as a gift for a recipient; issuing, to the recipient, a token that is redeemable to obtain the gift; and requesting payment for the gift from the purchaser, the payment consisting of a cost of the gift and a tax imposed by a jurisdiction in which the token is redeemed.
The only other independent claim in the ‘829 patent, claim 10 (with emphasis added), also has a similar limitation:
10. One or more storage devices storing instructions that are executable to perform operations comprising: presenting media content via an audio/visual display to a purchaser; presenting to the purchaser, at a point during presentation of the media content, an option to purchase the media content as a gift; in response to presentation of the option, receiving, from the purchaser, information for purchasing the media content as a gift for a recipient; issuing, to the recipient, a token that is redeemable to obtain the gift; and requesting payment for the gift from the purchaser, the payment consisting of a cost of the gift and a tax imposed by a jurisdiction in which the token is redeemed.
By any fair estimation the claims of the ‘829 patent cover a computer implemented process, which makes this patent a “software patent.” That in and of itself is interesting given that Google publicly decries software patents specifically and patents more generally, saying that they only get them for defensive purposes and because they feel compelled to do so. Of course, that doesn’t really seem to jive with reality when you factor into the equation that they have been over aggressive in seeking to enforce the Motorola portfolio they acquired to the point where they violated FRAND agreements with respect to standard essential patents. See Motorola wanted a free license.
Notwithstanding Google’s Jekyll and Hyde approach to patents, Figure 14 together with the associated textual discussion is extremely interesting because it shows rather conclusively that “software” isn’t really all that “soft.” Figure 14 is shown below.
First, the reality is that software is nothing more than a process. Software is not math and anyone who tells you otherwise is simply being intellectually dishonest, trying to fool themselves or simply ignorant with respect to what is really going on fundamentally inside a computer. Software directs a machine, such as a computer, to accomplish a defined task based on certain identifiable inputs. Furthermore, on a tangible, mechanical level software merely directs the operation of logic gates and switches (more on that later). Thus, software is not math, which would be self evident to anyone who stopped to think about it for even a split second.*
In any event, process have always been patent eligible in the United States and eventually when the Federal Judiciary is made up of judges who have grown up using computers and the Internet software will be patentable as a process without the need to obfuscate that reality. In the meantime, at least since the Federal Circuit en banc decision in Bilski v. Kappos we have had to satisfy the so-called machine-or-transformation (MOT) test, which requires software to be described as being tethered to a certain machine embodiment. For more on MOT see A Guide to Patenting Software and Patenting Business Methods and Software in the U.S.
Despite the tortured description and mental gymnastics required by MOT, it makes sense when you realize that the goal was to prevent purely mental processes from being patented. Of course, it would have been far easier and far less destructive if the courts had simply said just that — namely that mental process are patent ineligible. But because they didn’t state the simple, obvious rule that addressed their concerns we are left with MOT. **
Thus, when drafting a software patent application you absolutely must include discussion of the underlying technologies. This has typically been accomplished by including reference to storage units, databases, processors and the like. To those in the field this type of discussion is well understood and quite tangible. But software patents are under attack in the media, who is turning the public against software patents specifically and patents more generally. Software patents are also under attack by some of the giants of the technology industry, such as Google ironically. Decisions are made by judges who in many cases simply do not use computers, as difficult as that may be to believe.
|Patent Prosecution & Litigation Consulting|
Indeed, POLITICO recently reported that Justice Elena Kagan says the Justices of the Supreme Court are not tech savvy and still communicate with each other using paper memos rather than e-mail. POLITICO went on to report: “Kagan said the justices often turn to their clerks, who are much younger, to help them understand new technologies.” This is astonishing for many reasons. First, no one on the Supreme Court has any patent experience except with respect to the cases they decide, which is scary in its own right. Second, none of the clerks at the Supreme Court have any patent experience other than perhaps a law school class. Third, the Justices of the Supreme Court seem to some extent to be deferring to their clerks in a disproportionate and perhaps inappropriate way with technology issues. Finally, if the Justices of the Supreme Court don’t even use e-mail how in the world can they even hope to understand even the most trivial software or Internet technologies? Still, these are the judges that will ultimately decide the fate of software patentability, and this report seems sadly representative of the technical sophistication and technology savvy of many judges within the Federal Judiciary. This is not to say they are not smart or are incapable, but some simply grew up in the profession never using computers and relying on secretaries to type using typewriters and then word processors.
It is no wonder that some judges are unfamiliar with software and the fact that is really isn’t so “soft” after all. As Figure 14 of the ‘829 patent demonstrates, in order for the computer implemented process to be carried out there are a great number of tangible components that are needed. Confirm this even with this small sample of the textual description of Figure 14 found in the Detailed Description:
Computing device 1400 includes a processor 1402, memory 1404, a storage device 1406, a high-speed interface 1408 connecting to memory 1404 and high-speed expansion ports 1410, and a low speed interface 1412 connecting to low speed bus 1414 and storage device 1406. Each of the components 1402, 1404, 1406, 1408, 1410, and 1412 are interconnected using various busses…
The high speed controller 1408 manages bandwidth-intensive operations for the computing device 1400, while the low speed controller 1412 manages lower bandwidth-intensive operations. Such allocation of functions is exemplary only. In one implementation, the high-speed controller 1408 is coupled to memory 1404, display 1416 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports 1410, which may accept various expansion cards (not shown). In the implementation, low-speed controller 1412 is coupled to storage device 1406 and low-speed expansion port 1414.
The memory 1464 stores information within the computing device 1450. The memory 1464 can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. Expansion memory 1474 may also be provided and connected to device 1450 through expansion interface 1472, which may include, for example, a SIMM (Single In Line Memory Module) card interface.
Indeed, there are an awful lot of tangible components (i.e. “hard”—ware) required in order for the computer implemented process (“soft”—ware) to actually work. Those familiar with the technical reality of software also know that any computer implemented process that can be accomplished using software can also be accomplished using logic gates. Indeed, logic gates are foundation for all digital electronic circuits and microprocessor based systems. Thus, software can be explained on its core level as a process for manipulating logic gates.
Thus, if a method of manufacturing is patentable (see e.g. U.S. Patent No. 8,456,392 and U.S. Patent No. 8,356,980) and a method of testing is patentable (see e.g. U.S. Patent No. 8,348,499), and a method of using an apparatus is patentable (see e.g. U.S. Patent No. 8,356,737), then why wouldn’t a method of manipulating gates be similarly patent eligible?
The ‘829 patent goes a long way to demonstrating the level of technological discussion that can and probably should be inserted into software patents, at least if the applicant can afford to go to these lengths. It may also be worthwhile to drill down even further to discuss what is going on with the building blocks of the circuits and microprocessors, which relates to the use and manipulation of logic gates and switches.
Those familiar with software know that is really isn’t “soft,” but judges, politicians, the media and the public at large do not understand that and believe it is some kind of magical, mystical creation that embodies nothing more than an idea or mathematical concept. Even many so-called math experts and mathematicians refuse to acknowledge what is really happening on the basic level within a computer when “soft”—ware is being used, instead preferring to pretend that it has to do with basic math rather than manipulation of logic gates and switches. We can complain and lament their lack of understanding if it makes us feel better, but in the meantime we need to realize that their ignorance with respect to what is really occurring is having an enormously negative impact on the future of software patentability.
The moral of the story is this: Do not assume that those who have decision-making authority will understand that the process you are describing necessarily incorporates tangible components manipulated by design to accomplish the desired task. Describe it in bloody detail so that they are forced to deal with the reality that software isn’t any different from the numerous methods of use that have been patentable since the beginning of United States patent history. If that requires discussion of logic gates and switches then so be it, at least until judges and decision-makers are familiar enough with computers that they actually use e-mail.
* Please note that on IPWatchdog.com we require comments to be intellectually honest. Those the persist in denying self-evident truths are banned. Software is not math. You cannot solve or reduce software code, math is descriptive of reality while software directs action. Still, if you feel compelled to demonstrate your ignorance on this issue and and choose to pretend that software is math please visit one of the many other places on the Internet that will allow you to spew such provably false nonsense.
** The Supreme Court, of course, did not fully endorse MOT, but rather said it was an important clue to patent eligibility. Still, ever since Bilski, the Patent Examining Corps at the United States Patent and Trademark Office has treated MOT as a safe harbor. If your claims are meaningfully tethered to a machine they are patent eligible. It is a little more complicated than that, but really not much. For more on this See. Of course, the Patent Trial and Appeals Board does not view MOT as a safe harbor, and in fact has implicitly (and necessarily) ruled that claims that satisfy MOT are patent ineligible. See Did the PTAB Kill Software Patents? It is widely expected that this PTAB decision will be overruled because it announces a test that would render all software patent ineligible, which conflicts with Supreme Court precedent and the Patent Act. See Navigating the Software Patent Quagmire and Did the Federal Circuit Ignore the Supreme Court? and Is IBM’s Watson Still Patent Eligible?- - - - - - - - - -
For information on this and related topics please see these archives:
Posted in: Companies We Follow, Computers, Gene Quinn, Google, IP News, IPWatchdog.com Articles, Patents, Software, Software Patent Basics
About the Author
Gene Quinn is a Patent Attorney and the founder of the popular blog IPWatchdog.com, which has for three of the last four years (i.e., 2010, 2012 and 2103) been recognized as the top intellectual property blog by the American Bar Association. He is also a principal lecturer in the PLI Patent Bar Review Course. As an electrical engineer with a computer engineering focus his specialty is electronic and computer devices, Internet applications, software and business methods.