On Tuesday Feb 12th, the US Patent Office is holding a roundtable in Silicon Valley to discuss issues surrounding the patenting of software, and I have an opportunity to get a seat at the table.
I'll attend if I get some opinions from other entrepreneurs on the topic.
Do you have an stance on patenting software that you want to be heard? If so, leave it in the comments below and I'll represent the opinions I get below in person.
I'll also video capture the session (if I can) and post it here afterwards.
UPDATE: Looks like I'll be attending, so please join the conversation if you have any opinions to share.
EVENT UPDATE: Unfortunately the event wasn't a "roundtable" as I expected, but rather more of a "USPTO sitting up on stage listening to a few hand-picked presenters," which meant I didn't have an opportunity to present the thoughts I aggregated here. A bit disappointing, as I was also going to share Groklaw's response to the USPTO, which I've embedded below.
What I took away from the "roundtable" was that:
I did capture some good video content at the event. I'm putting the third video first because it was the best and most relevant to software developers, and specifically mobile app developers. Presenting to the USPTO in this video were Jeremy Russell, talking about a way to standardize patents in a talk titled "Software patents, pseudo code, and UML" and Julie Samuels, staff attorney for the EFF (she also holds the "Mark Cuban Chair to Eliminate Stupid Patents").
Here's Julie & other software-savvy presenters:
Here is Groklaw's response to the USPTO:
And here are the first two videos (not as relevant for software developers but patent geeks will enjoy them):
I haven't had a chance to watch the videos yet, which I am planning to do. But "1.12(f)" is actually 35 U.S.C. 112(f) (or 112 paragraph 6 as it was known before the America Invents Act) .
It essentially sets up the way you can claim a patent by saying " I claim a means for X". The trick is that you don't have to particularly specify X, it is determined in light of your specification which can make it a confusing area particularly for things like software.
Isn't the specific way of solving a problem covered under copywriter for the code or design patents for design aspects?
Jim, not sure I understand the question?
Sorry, was on mobile, that should have been "copyright", got autocorrected.
It was in response to part 4 in your post. We already have a method for protecting people who come up with a specific implementation - copyright. Doesn't this imply we could protect this and just do away with software patents altogether?
Last call on this guys -- I'll be at the USPTO round table tomorrow morning and will bring your comments with me to share.
By the way, here's an awesome article shared by Jason about what Mark Cuban is doing about this issue.
I think it's important to define a few terms when having this discussion and looking at how the PTO and the courts view them vs. how most software developers view them:
How most people view it:Is this a cool new thing that will change the face of technology as we know it.
How the PTO views it:
The PTO views novelty as is this new. Not is it innovative, is it worthwhile, beneficial, smart, dumb, valuable, etc... Just simply has it been done before. And by has it been done before, this essentially means did someone publish a paper, sell, use, etc this thing before it was invented or more than a year before the original patent app was filed. If it has been previously done evidence of that is called PRIOR ART.
How most people view it:
Duh! If I had sat down and thought about it that is probably what I would have come up with. (Note that this is often much easier to do in hindsight.) The idea of "Of course you would pinch to zoom" would have been a completely foreign concept before multitouch arrived on the scene, but most people think that a patent on pinch to zoom that may have been created before multitouch was 'obvious'
How the PTO views it:
Is the patent merely two pieces of prior art that have been combined AND would someone having ordinary skill in the field have a reason or thought to combine those pieces of prior art. This also includes whether or not someone would have thought to use prior art from another field. (i.e. just because meshing algorithms existed for a long time does not mean the courts would assume a developer would have known to look for them.)
What the patent covers
How most people view it:
Everything under the sun that could be described by the title of the patent. If I manage to get a patent on "a thin computer display" suddenly everyone using a laptop owes me lots and lots of money.
How the PTO views it:
The claims, the claims, the claims. The only thing that matters are the claims. Suddenly my thin screen laptop becomes 'displays having a thickness of less than .00001 microns and made out of recycled matchsticks.' This isn't to say that some patents are overly broad, just that most patents don't really cover everything that a lot of people think they actually claim.
So after all of that, the goal is to encourage innovation. The patent systems assumes that when something is patented instead of the inventor hiding how they did it, they get exclusive rights in exchange for full disclosure. After the patent term expires than everyone can use that disclosure to make more cool stuff instead of still not knowing how it was made.
I think this is a correct sentiment. Consider compression algorithms. A patent on a new compression algorithm will protect the patent owner for some time, but require that they publish all the juicy details of how they do it. Than others can pick it apart and build on it once the patent term expires. The goal here is to encourage that type of iterative iteration.
When looking at novelty and obviousness, if it is truly obvious it is likely that someone just did it, wrote a blog post about it or published a simple paper, and sold it or told a bunch of people about it, at which point it is no longer novel. In theory, the normal small iterative course of invention likely occur organically because people will not view their improvement as so novel that they had to undertake a great expense and then will be undercut by the competition.
The problems of course occur in this area as in all others area of the law that those with deep pockets can outlast the small guys and the patent terms have become inconsistent with the technology it protects.
Hey Just started reading your blog. As a Newbie start up founder, I am looking forward to learning. I would like you to ask if there's any thought to the way the patent system stifles innovation by allowing patent holders with deep pocket to push around start ups and small business using the legal system. Is anyone at patent or commerce concerned by the chilling effect the patent system has on start up business? Is there any thought of an administrative action as oppose to using ALJ's to make the granting of patents harder? How do they feel about a system that stifles iteration of ideas which is central to the growth of internet technology?
I'm not an expert in this area (at all) but your comment triggered a thought which may be relevant. I think in some cases startups think the wrong way about patents. VCs/Investors will often ask "do you have a patent?" and it's often thought this is a somewhat pointless question as 99% of the time the startup would not have the resources to defend the patent if needed (to your point) so are better to spend the money on growing their business. But generally I do not believe this is what the investor means.
As you have pointed out if a startup goes to market assuming the protection of a patent they may quickly realize that its protection is only as good as the lawyer who defends it, and that doesn't come cheap. So what's the point? Well consider that the startup does in-fact have a winning idea and is successful at commercializing the idea, and does have a patent for the idea. This won't prevent a larger company with deeper pockets doing the same, and likely executing with greater effectiveness due to their ability to throw resources and sales channels at the problem, but what it WILL do is make the startup a more attractive acquisition target.
The larger company is not necessarily being nefarious. It may be they just happened to think of the same idea, just AFTER the startup, and although they are likely not interested in battling the startup for the patent as they know they'll win purely based on financial resources available, they may very well be interesting in defending their position against THEIR competitors. If Google implements the same concept as the startup, there's not much the startup can do to defend their position but they will very likely be an attractive acquisition target so Google can defend their position against Apple/IBM/Yahoo/Microsoft etc.
So when an investor asks, "do you have a patent?" they are thinking of exit value, not protection. And startups should not look to patents as protection, but as adding to their attractiveness as an acquisition target.
The alternative of course is to just sit on the patent, allowing others to copy until the startup is as big as Google, then battle it out.. although obviously this rarely happens.
OK but for both of you, my question is: How would you like to see the process changed? (Beyond what you wrote above, Jason about it being an obvious vs. non-obvious claim). I want to be able to offer up tangible recommendations based on feedback from the comments here.
I have a lot more to post on the subject (particularly the obvious vs. non-obvious distinction and the idea of 'bad patents'), but for me the biggest change I think that is necessary is for the PTO to recognize that different technology areas surely require different validity lengths for patents. The current 20 year period is simply way to long for most current technologies in the computer space. For something like drugs, it certainly makes sense. I certainly benefit from the fact that the patent on ibuprofen has expired while the Drug companies certainly got the protection they needed for a sufficient time on Advil to benefit from their investment. When I was 13, I had a IBM clone pc with an 80386SX processor (complete with a turbo button to bump the bus speed to 50mhz). A patent on that processor would still be valid today despite the fact that the technology has been worthless for years. This is compounded by the fact that a technological leap in this technology area that used to take 10 years, now takes 1. That said, If the patent term is adjusted based on technology area, companies would still be able to get patent protection for the most valuable timeframe of their invention while still ensuring that the patent expires early enough so that the public can innovate.
The downside to this approach, is that some patents don't become fruitful until towards the end of their term. For instance, Apple put a lot of time and money into the development of the original iphone. No one can deny it was a complete game changer, and while they have patents to cover many of the components, many of those patents expired shortly after the iphone was released. The invention was created and patented long ago, but it took a long time for the technology to find it's calling. A shortened patent term might hinder these inventions. Perhaps the term could run from the time of first sale or licensing? Regardless, I feel that the patent term is one of the biggest hinderances to meeting the aims of the patent system when applied to the rate at which software/computer/internet technologies evolve.
OK Nick so around this line of thinking: How would the USPTO determine (and agree on) how long the patent should be valid for? And would it be defined by industry vertical?
The USPTO already classifies patents by type of technology. It doesn't seem to much of a reach to have different patent lengths for different types of technologies. People would argue about which area their patent falls in, but that is just another of any number of arguments that a patentee has to make anyways. Pharma patents would keep their 20 year term, which makes sense because it is still meaningful, while things like software patents would have a term more commensurate with their appropriate usefulness.
Because your term wouldn't be as long, you may save money on fees, and perhaps you have to show that you are actively trying to license or leverage the patent in order to maintain it's enforceability for the full term.
It certainly would not be the easiest system to maintain, but the MPEP (the rules that govern patent examiners) is already 3000+ pages. The categorizations exist, capping them based on studies or determinations of typical usefulness by patent category wouldn't be too difficult to add.
I love the thinking around just using time to change the dynamic and I think that a concept of "in use" does have merit. That is, a patent is only defensible if it's "in use" by the owner and only remains defensible if it's been "in use" for less than some time, e.g. 5 years. If the patent is not in use, then it cannot be defended as there cannot be a case for claiming "current" economic damage (vs. future damage). Conversely if the patent has already been "in use" for 5 years then the owner has had all the time they are allowed to make the best of it and if they can't in that time then it's open for someone else to try.
As a former company founder and having previously attempted (and failed) to register a software patent I have some views on the subject. Be aware however that these are merely opinions. It seems to me there are a lot of "binary" opinions out there. That is, either for or against. I think there is definitely significant room for improvement in the current system, but I do believe there is a place for software patents. One must first either acknowledge or otherwise the value of patents in the technology landscape more broadly, then contrast this with the specifics of the software landscape within this set. If we can agree that the basic concept of protecting an innovation so as to allow its inventor sufficient time to commercialize that innovation is generally a "good idea", we can then simply address the two questions that naturally fall from this. Namely, "do patents in their current form serve to protect innovation?", and "are the patents granted representative of innovation?". I cannot speak to the efficacy of the former and can only assume that notwithstanding those who would seek to deliberately circumvent the law, the current legislation provides adquate protection under law to the extent that the government can, or should influence. As to the latter however, I feel this is where there is the most wiggle room.
The foundation premise of protecting innovation clearly assumes that the subject of protection is "innovative". This is a topic heavily tainted by subjectivity but nonetheless in my opinion is the crux of the problem. The question ought not to be, "is the invention merely an adaptation of an existing idea?" (a pivotal question in the process of evaluating patents), but specifically where software is concerned, "does the invention describe a natural evolution of ideas based on currently available information". That is, if left to its own devices would the industry in general have evolved naturally to the conclusion that the "innovation" was the next most logical step in solving a given problem. If so, one could say the invention is not "innovative". If however the invention is NOT something that would have evolved naturally but rather representative of genuinely new and different way of solving a given problem, then we could say the solution was innovative. A simple test for this is to sit any competent programmer (or programmers) down and ask them to solve the problem at hand. If their solution is a match for the "invention" then it's likely that it's not innovative, and should not be patented because doing so acts to hinder progress more than it helps. There are clearly other simple examples of this such as, "improve upon the performance and effectiveness of current compression algorithms". There is not likely to be many (or any) programmers who are capable of doing this, hence the solution to this is naturally innovative. Conversely, "build a system that allows a user to make a purchase with one click" is something almost any competent programmer could build.
Of course none of this idealistic nonsense talks to how this might be achieved, but simply acknowledging that there IS a distinction between the two might be a valuable first step.
Note that this would allow companies that actually expend a lot of resources to solve a problem to capture a patent, since it will be in the category of "the industry has been trying to solve this problem for a long time", while simple "discovery" patents would be rejected (the ones of the form "hey I found a new use for this plant").
@Jason to distill what you're recommending: Should every software patent claim be subject to a review process by development peers? Let's take the compression algorithm example you illustrated, and let's say I think I have a novel solution for it. If I applied for a patent for that solution, would the USPTO then post the following publicly:
"Patent application for a novel compression algorithm is pending"
And would there be a period (let's call it 90 days) where the USPTO could "crowdsource" compression algorithm solutions? And if nobody comes up with anything substantially similar to the (not public) solution the patent inventor has claimed, then the patent would be granted as "innovative"?
I'm happy to think outside the box, like you are, and suggest completely different ways to approach software patents. I agree it's unlikely that much would come of it, but it's a fun exercise nonetheless... and who knows. Big ideas are free :)
That makes sense, but I suspect my example is a little too contrived to use as a real use case. Many patents are simply too general in their wording so it may just be very unlikely that the crowd-sourced solution is similar regardless of the fact that the invention may indeed not be innovative. Striking a balance between disclosing enough information about the invention so as to provide sufficient information for alternate solutions while not disclosing enough to reveal either the invention itself or even the mere concept may be impossible. Consider for example a patent to protect a multi-touch screen technology before multitouch was even a glimmer in the technology vernacular. The simple act of seeking alternate solutions would be disadvantageous to the inventor as the cat would be out of the proverbial bag.
In practice the solution to the problem of "obvious" patents is likely to be very difficult to implement, and in fact there is already provisions in the system to reject such applications. Perhaps the real issue is that the current process is simply inefficient. Both from a time perspective, and an accuracy one. The resource constraints on the approval process mean review times are long and important details are often missed, leading to extended re-examinations and appeals after the fact. Happily these problem all point towards crowd-sourcing as a basis for a solution even if the specifics are some way off.
To use the touch screen example: The question could've been something like "ways to use a monitor to provide input data" or something sufficiently obscure. I guess what I'm saying is that if the idea is so novel, then by definition others won't come up with it when asked... and that's the entire point, right?
Maybe the person with the idea is responsible for coming up with an appropriate litmus test?
Maybe there's some double-blind way to do it so as not to put ideas into people's heads?
Or to attack the "obviousness" issue from another angle: Maybe it's not that the inventor has to prove that the invention is non-obvious but rather, we make it easier to invalidate patents once granted.
So for example, you can still get a patent with the current process. But the patent is somehow more vulnerable to being invalidated without going through the court system. Maybe the USPTO puts the burden on the original examiner: If someone says they already had a similar method to what was patented, then the examiner is required to re-examine the patent and consider that as prior art that could invalidate the patent.
In this manner, it would become much easier to invalidate patents, and so only the strongest ones (and therefore the most "true" to actual innovation) would survive. Kind of a Darwinian approach.
What's nice about the "reexamination" mechanism you suggest is that it already exists. That wiki link has a nice summary, but essentially if I have prior art that invalidates a patent, I can tell the patent office. I don't have to be the patentee or a licensee or anything.
This has already been used often. Almost always, one of the first things a defendant in a patent suit might do is request a re-exam. Samsung already had some of Apple's patents ruled as invalid following the landmark infringement case. I believe. While it would be better if the patent was never issued, this is impractical. Examiners have technical degrees but likely have little to no real experience. They do their best to try to find prior art to ensure a patent should be granted, but the system is never going to be perfect. The re-exam helps fill this void and as Wiki points out the recent AIA changes will make it easier to invoke this process.
Julie Perlmutter's phenomenal Web Managers Roundtable event series continued yesterday with the United States Holocaust Museum hosting an event on Mobile Analytics. PointAbout was a sponsor of the event. You can also find a PDF of the PowerPoint deck here.
The event was titled "Proven Metrics Strategies for Finding Your Audience on the Mobile Web." The speaker was Greg Dowling, VP at Semphonic and previously the head of analysis at Nokia.
Event description: Mobile technologies are so new that few organizations have a handle on the metrics strategies needed to make sure their own mobile initiatives succeed. In this program of strategic insights, mobile analytics expert Greg Dowling will provide the road map.
Here's a video of the event:
Julie Perlmutter's phenomenal Web Managers Roundtable event series continued yesterday with the United States Holocaust Museum hosting an event on Mobile Analytics. PointAbout was a sponsor of the event. You can also find a PDF of the PowerPoint deck here. The event was titled "Proven Metrics Strategies for Finding Your Audience on the Mobile Web." The speaker was Greg Dowling, VP at Semphonic and previously the head of analysis at Nokia. Event description: Mobile technologies are so new that few organizations have a handle on the metrics strategies needed to make sure their own mobile initiatives succeed. In this program of strategic insights, mobile analytics expert Greg Dowling will provide the road map. As creator of the first worldwide mobile web analytics implementation standard, he'll discuss that work, the issues that make measurement standardizing difficult, the hurdles involved in navigating mobile's rapidly evolving terrain, and new ways to successfully address key mobile metrics issues. Here's a video of the event:
Update: At the bottom of this post, I've linked to two large and quite different discussions of this post, both of which are worth reading...
Update 2: If the contents of this post make you angry, okay. It was written somewhat brashly. But, if the title alone makes you angry, and you decide this is an article about "Why Testing Code Sucks" without having read it, you've missed the point. Or I explained it badly :-)
Some things programmers say can be massive red flags. When I hear someone start advocating Test-Driven Development as the One True Programming Methodology, that's a red flag, and I start to assume you're either a shitty (or inexperienced) programmer, or some kind of Agile Testing Consultant (which normally implies the former).Testing is a tool for helping you, not for using to engage in a "more pious than thou" dick-swinging my Cucumber is bigger than yours idiocy. Testing is about giving you the developer useful and quick feedback about if you're on the right path, and if you've broken something, and for warning people who come after you if they've broken something. It's not an arcane methodology that somehow has some magical "making your code better" side-effect...
The whole concept of Test-Driven Development is hocus, and embracing it as your philosophy, criminal. Instead: Developer-Driven Testing. Give yourself and your coworkers useful tools for solving problems and supporting yourselves, rather than disappearing in to some testing hell where you're doing it a certain way because you're supposed to.
Have I had experience (and much value) out of sometimes writing tests for certain problem classes before writing any code? Yes. Changes to existing functionality are often a good candidate. Small and well-defined pieces of work, or little add-ons to already tested code are another.