Serial Litigant Blue Spike Wins EFF's Stupid Patent Of The Month For September
from the impossible-to-define dept
Blue Spike LLC is a patent litigation factory. At one point, it filed over 45 cases in two weeks. It has sued a who's who of technology companies, ranging from giants to startups, Adobe to Zeitera. Blue Spike claims not to be a troll, but any legitimate business it has pales in comparison to its patent litigation. It says it owns a "revolutionary technology" it refers to as "signal abstracting." On close inspection, however, its patents1 turn out to be nothing more than a nebulous wish list. Blue Spike's massive litigation campaign is a perfect example of how vague and abstract software patents tax innovation.
The basic idea behind Blue Spike's patents is creating a digital fingerprint (which the patents refer to as an "abstract") of a file that allows it to be compared to other files (e.g. comparing audio files to see if they are the same song). In very general terms, the patents describe creating a "reference generator," an "object locator," a "feature selector," a "comparing device," and a "recorder." You will be amazed to learn that these five elements "may be implemented with software." That task, however, is left for the reader.
Even worse, Blue Spike has refused to define the key term in its patents: "abstract." In a recent filing, it wrote that even though the term "abstract" is "a central component to each of the patents," a single definition of this term is "impossible to achieve." This is a remarkable admission. How are defendants (or the public, for that matter) supposed to know if they infringe a patent when the central claim term is impossible to define? This is a perfect illustration of a major problem with software patents: vague and abstract claim language that fails to inform the public about patent scope.
Admitting that the key claim term in your patent is "impossible" to define is probably not a great litigation strategy. And the defendants in some of Blue Spike's cases have already protested that this means the patents are invalid. The defendants should win this argument (especially since a recent Supreme Court decision tightened the standards applied to vague and ambiguous patents). Though regardless of whether the defendants prevail, Blue Spike's litigation campaign has already imposed massive costs.
Blue Spike's patents illustrate another major problem with software patents: vague descriptions of the "invention" that provide no practical help for someone trying to build a useful implementation. This is why many software engineers hold patents in low regard. As one programmer told This American Life, even his own patents were little more than "mumbo jumbo, which nobody understands, and which makes no sense from an engineering standpoint." You can judge for yourself, but we contend that Blue Spike's patents consist similarly of little more than legalese and hand waving.
Real products take hard work. A commercially successful product like the Shazam app (one of Blue Spike's many targets) is likely to consist of tens of thousands lines of code. Actually writing and debugging that code can require months of effort from dozens of engineers (not to mention the fundraising, marketing, and other tasks that go into making a real-world product successful). In contrast, it's easy to suggest that someone create a "comparison device" that "may be implemented with software."
Last month, we selected a bizarre patent to illustrate that the Patent Office conducts a cursory review of applications. In contrast, this month's winner is not so unusual. In fact, Blue Spike's patents are typical of the kind of software patent that we see in litigation. That such a low-quality patent family could fuel over 100 cases is a stark illustration of the problem with software patents.
Dishonorable mentions:
US 8,838,476 Systems and methods to provide information and connect people for real time communications (a patent on presenting an advertisement at the outset of a "telephonic connection")
US 8,838,479 System and method for enabling an advertisement to follow the user to additional web pages (Lots of patentese that says put an ad in a frame and keep the frame constant as the rest of the page changes. Awesome.)
US 8,818,932 Method and apparatus for creating a predictive model (this patent claims to apply the "scientific method" to "the problem of predicting and preventing violence against U.S. and friendly forces" and includes hopelessly vague claim language such as "verifying causal links" and "utilizing the social models to … predict future behavior")
Reposted from the Electronic Frontier Foundation
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: patent trolls, patents
Companies: blue spike
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
Blue Spike LLC well on its way to petarding itself
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
sfv file checker
https://en.wikipedia.org/wiki/Simple_file_verification
there are ways to fool or get bad results but that in an dof itself is hard
[ link to this | view in chronology ]
the 2nd patent sound slike a tracking cookie
where if you visit a site it remembers and then uses that info at other sites in advertising....
ALSO VERY OLD
[ link to this | view in chronology ]
onclick
onload it starts an audio/video that may or may not popup
DISABLED BY MILLIONS FOR SPAM and may or may not even be legal in canada as an example....
you may have an audio chat that befor eany user may use said feature requires them to listen to some stupid ad.
NONE OF THIS IS INNOVATIVE , heck telelvision been doing it for damn years....
as to personal chats no one wants this kind of service anyhow ....and its not new
heck upon entering ajaxchat a 2008 web page chat/forum interface a sound rings....one could change that to HEY USERS here is my stupid bug yo uadd of the day...
so no not new technology
again its just some lax lazy lawyer looking for a quick east scam
[ link to this | view in chronology ]
A patent is a set of exclusive rights ... in exchange for detailed public disclosure of an invention
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
Quick, get more wool for his eyes!
[ link to this | view in chronology ]
Maybe
Maybe we could even use an automated patent generator
The costs would need to be crowdfunded - I'd contribute!
[ link to this | view in chronology ]
Patent-validation tests
There are longer and more legalistic ways to describe them - to fill in details, eliminate loopholes, address corner cases, and avoid unintended consequences - but the basic outline is:
One:
* Find a "person skilled in the art".
* Give that person access to the entire patent application.
* Ask that person to reproduce the invention, based on the description in the patent application.
If they do not succeed, then the patent application does not adequately describe the invention in question, and must be rejected - because it does not fulfill the purpose for which patents exist in the first place: enabling other people to reproduce the invention.
Two:
* Find another "person skilled in the art".
* Give that person access to only the summary / abstract of the patent application - the part which describes what the thing to be patented does, but not any of the details of how it does it.
* Ask that person to create something which does what is described in that summary text.
If they succeed, and what they create is close enough to the claims of the full patent application that it would be likely to be considered infringing, then the patent application covers something which is "obvious" to a person skilled in the art - and so should be rejected.
There are still other reasons why a patent application should potentially be rejected - prior art, for example, though the second test covers that to some degree if we assume that a "person skilled in the art" would probably be familiar with most such - but it seems to me that that would address the vast majority of bad patent applications.
[ link to this | view in chronology ]
Re: Patent-validation tests
[ link to this | view in chronology ]
Re: Re: Patent-validation tests
What about patent applications which do provide implementation details, but not enough of them, so that you can't actually implement the patented thing just based on the information in the patent? It's not always going to be obvious what is and is not "enough", unless you are in fact "a person skilled in the art" - which, for any given field, most patent examiners are not.
What about patent applications which are for something which would be obvious to anyone in the field who bothered to work on the problem?
There are many categories of possible reasons why a patent application can be bad. My proposed pair of tests wouldn't address all of them, but I think it would address most of them, including particularly the ones which are not being properly addressed under the current approach. Your proposed test (in addition to lacking detail by which to judge what is and is not "only an idea") seems to me as if it would only address one or two of them, at most.
[ link to this | view in chronology ]
Re: Re: Re: Patent-validation tests
[ link to this | view in chronology ]
Re: Re: Re: Re: Patent-validation tests
I still think it's a useful line to start on, though - almost a thought experiment; it serves to help frame the problem in the right way, and point out what things actually need to be addressed, even if it isn't practical as a way of addressing those things by itself.
There are a number of other corner cases and loopholes and so forth as well, which would have to be addressed by any fully-detailed proposal in this direction, but I figured the version I gave is legalistic enough that I'm risking people not bothering to read it even as is. A more detailed legalese version is percolating in the back of my head; I've gone over three or four main variants on it so far already.
[ link to this | view in chronology ]
Re: Re: Re: Re: Patent-validation tests
These two tests represent, and possibly exemplify, two essential basic questions which should be asked of any patent application, under and below (as contrasted with "over and above") questions like prior art:
* "Could a person skilled in the art reproduce the invention based on the description in the full patent? If no, the patent application must be rejected."
* "Could a person skilled in the art reproduce the invention based on the description in the abstract of the patent? If yes, the patent application should be rejected."
The rest of the details of my proposal are mostly a way to define how to determine whether a person skilled in the art could reproduce the invention with the given information. Even if you don't go as far as finding such people and having them actually do it, however, I think it could still be useful to explicitly codify these questions as rules in the patent-application-handling process.
(Note also the difference in the use of "must" vs. "should" in the two tests. I included that difference intentionally, because there are some corner cases where it could potentially make sense to grant a patent application even when the second test might fail, and I wanted to leave room for that in the details.)
[ link to this | view in chronology ]
Re: Patent-validation tests
I love it. The expense would be an issue, but I'm sure there are ways around it. Make patent applications from corporations have a cost scaled to annual revenue or something.
[ link to this | view in chronology ]
I'm sorry but they walked right into that one.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
I have a question
Seems like the sort of thing somebody should be looking at.
[ link to this | view in chronology ]
Re: I have a question
[ link to this | view in chronology ]