THE INFOBLOG
Company news, plus our musings on Enterprise 2.0, organizational culture, knowledge workers, and information management.
More Patent Foolishness
I seem to have software patents on the brain lately. After I wrote about our decision not to move forward with Infovark’s provisional patent, several recent articles and blog posts have caught my attention.
What started the latest round of software industry soul-searching was an article in the Harvard Business Review written by Nathan Myrhvold regarding his company, Intellectual Ventures. It’s called The Big Idea: Funding Eureka. His company aims to make money from enforcing patent rights created by both in-house and independent inventors. You can read a recent profile of Intellectual Ventures and its strategy in the New York Times.
I didn’t know about Intellectual Ventures at the time I wrote our blog post, but it’s exactly the sort of company I was thinking about when I described the collect ‘em, trade ‘em patent game. Intellectual Property lawyers call it a Non-Practicing Entity or NPE, but most folks in software and technology would call it a patent troll.
Big tech companies have a lot of time, money and effort invested in their patent portfolios, and they are very worried about the impact companies like Intellectual Ventures will have on innovation.
The venture capital community is also concerned. Brad Burnham of Union Square Ventures thinks that software patents are the problem, not the answer. Other prominent VC bloggers, like Fred Wilson and Brad Feld, agree.
Changes in the wind?
It looks like the idea of software patent reform is gathering momentum. Business method patents, like Amazon’s famous “one-click” shopping cart patent, have always seemed wrong to me. I also dislike the idea of software patents in general. A computer is fundamentally a machine for doing math. If mathematical formulas are not patentable, why should software be?
But it’ll be a long, hard road to get the law changed. And there’s only so much change that a reinterpretation of existing law, like the In re Bilski case, can bring about.
For one thing, investors must be persuaded to stop putting a premium on businesses and start-ups with patents pending. Companies that have patents must stop using them as competitive weapons — ways to tangle and trip up their competitors in red tape. Accountants must stop treating patents as a corporate asset or as capital.
Ultimately, companies will still pursue patents so long as they have a financial incentive to do so. And the companies that own patents have a vested interest in keeping the status quo. Even some of the VCs that back patent reform admit that they advise their portfolio companies to protect what they can.
There are enormous incentives to play by the rules, even when the rules themselves are broken.
The Second Biggest Mistake of Enterprise 2.0
I imagine most folks begin their journey toward Enterprise 2.0 by saying, “I wish we had some of these Web 2.0 tools at my company.”
Actually, I imagine that people are more specific than that. Substitute Wikipedia, Facebook or Twitter for “Web 2.0 tools” and you’d have the starting point for most organizations.
What happens next can determine the success or failure of your Enterprise 2.0 effort.
Watch your step
The Tao Te Ching reminds us that “a journey of 1000 miles begins with a single step.” Taking that first step is important.
I’ve read lots of advice regarding that first step. Probably the most common advice is to know why you you need the tool. It’s not enough to want to be “more 2.0.” What objectives do you want to achieve with the new technology?
Many Enterprise 2.0 bloggers are quick to point out that you must be specific. The answer can’t be “to work better together” or to “share information more effectively”. If you can tie the technology to the improvement of a specific work process or output, you’ve got a much better chance of the enterprise 2.0 implementation succeeding.
But I won’t spend any time on that, because frankly, the “Why are we doing this?” question comes up all the time during an implantation. If you have to justify resources for your enterprise 2.0 effort, you’ll get asked this question repeatedly. And if you don’t have a specific answer, the E2.0 effort won’t get underway, period.
Look before you leap
The second biggest mistake companies make is picking a specific tool or technology too early.
Software evaluation practices at many organizations are backwards. You evaluate the features and functions of one tool versus another, and then you ask the question, “how do I buy?”
It’s tempting to consider the tool or technology in the abstract, separate from issues of support, maintenance and training. Don’t fall into this trap! Most software works. But whether it will work for you or your team is about much more than its features and benefits.
How you buy software is the second biggest challenge to implementing Enterprise 2.0.
I think it might be better to consider these question in reverse: “What sort of vendor relationships do I want? What sort of product does that imply?”
For example, do you want your own IT shop to implement the product, or do you want to bring in outside consultants? Is a pay-as-you-go cloud solution feasible, or do you prefer to own the solution outright?
These provider arrangements have almost nothing to do with the technology itself. Frequently, they’re left out of the evaluation process. In the government sector, buying a software product is often a different line item than buying consulting services. Sometimes they fall under different contracts altogether. Trying to force a one-stop-shop vendor into this procurement model can be a disaster in the making.
Before picking a tool, you should know what your team is able to support. Finding a tool or a vendor that matches your procurement process can be more important than the tool itself.
Think broadly about a focused implementation
The good news is that companies today have lots of choices when it comes to implementing Enterprise 2.0 solutions. You can construct a deal that works for all of the groups involved. But that often means that you can’t be wedded to a particular tool or technology at the start. You have to know what sort of financial and working arrangements will suit your organization first.
Ribbon Hero uses game design principles to help users learn Microsoft Office
Kathy Sierra, design and usability advocate, is famous for saying, “If you want people to RTFM, make a better FM.” In 2007, Danc, a game designer and author of the Lost Garden blog, claimed that any user activity that can be learned, measured, and returned as feedback can be made into a game.
An alternative to Minesweeper?
Some folks on Microsoft’s Office Labs team took up the challenge. They’ve released a game called Ribbon Hero, which helps users master the Microsoft Office “ribbon” toolbar.
Danc discusses the design philosophy behind Ribbon Hero and shares his thoughts on turning a traditional application design into one that incorporates learning, fun, and a sense of accomplishment.
I’ve always thought that computer games have a lot to teach the rest of the software industry about design and usability. It’s fascinating to see software developers putting those ideas into practice.
Patent Foolishness
Our provisional patent expires today. We chose not to pursue an official, non-provisional one. It was a tough decision.
I won’t rehash the history of software patents here. And better writers than me have already written at length about the software patent debate. Paul Graham’s essay on software patents comes to mind.
This is about the decision process Gordon and I went through when we decided to pursue a provisional patent, and the reasons why we chose not to pursue the official one. The short version is: It’s the economy, stupid.
Mixed feelings
I’ve always had mixed feelings about software patents. As a programmer, I think they’re silly. It’s hard enough to write software as it is. Must I worry about all the thorny intellectual property issues, too? Code is more like sculpture than chemical engineering. Copyright should be enough to protect my work.
As a business owner, I understand why patents are necessary protection against other firms with large patent libraries. To put forth all the R&D and market development effort only to watch it drained away by litigation is a tech entrepreneur’s worst nightmare.
From an investor’s point of view, software patents are protection against downside risk. Unlike copyrights, patents are tradeable. There’s a market for patents, so even if the software business fails, you’ve still got an asset to sell to someone. You can get some of your principal back.
As long as we were in a bootstrapping phase, Gordon and I were content to leave the patent issue alone. Building working software and establishing a business were more important priorities. As a founder in a startup, you’re focused on delivering the upside, not managing the downside.
When we began seeking outside investment, that equation changed. The balance shifted toward getting a patent because it reassures potential investors. Gordon and I aren’t ideologues. We had no problem applying for trademark protection. So we swallowed our distaste and called a lawyer.
Patents: The Gathering
If the world of intellectual property seemed like one of those collectible card games from the outside — Hey, I’ll trade you two business method patents for three user interface licenses — it seemed even more so once we started the process.
First, we had the problem of defining our unique IP. You want to stake your claim as soon as possible, but since the software is currently under development, you make the broadest claims you can. We weren’t exactly sure what final form our “affinity engine” was going to take. We just knew that we needed to capture user behavior as a way of ranking the relevance of related items of content.
Then you hire a lawyer or law firm to search the patent office’s database of previous filings to determine whether somebody else has patented something similar. Since somebody else was making equally broad claims, it’s likely that you’ll need to refine your patent application a bit. This gets expensive quickly.
Once you file your official application, it can take quite a while before you find out whether it’s been approved or not. If it’s granted, you now have the ability to sue anyone that infringes on your rights. This is very expensive.
Intellectual property: How does your deck stack up?
The real point of having the patent is so that you can negotiate with other other patent-holders in case someone alleges infringement. It’s a strategy of mutual assured destruction. Rather than sue, counter-sue, and fight it out in the courts, you simply trade software licenses among yourselves.
The larger your deck of patent rights, the better the chance you hold the cards for something the other player wants.
For a start-up, this can mean that you can get acquired by a big firm solely because you hold an important patent. And if your business flops, you can sell your IP to a patent troll to use as ammunition against other companies. Investors like to see patents because it improves the valuation of a company and hedges against risk.
So it’s a costly and time-consuming distraction for a small business, but often a necessary one. We spent quite a bit of money on our provisional application in the hope that it would help attract additional investment.
Sunk costs
But then the economy soured, and investment began to dry up. It no longer made financial sense for us to pay for legal work if we weren’t going to raise additional funding as a result of it.
Another complication is that the future of software patents is in doubt. According to the recent In re Bilski case, software patents are only valid in cases where the software is tied to a physical device or is used to make changes in physical objects. Do either apply to software whose main purpose is to organize digital information?
It seemed dumb to come this far along on a patent only to abandon it, but we had to be pragmatic. It’s water under the bridge. We need to preserve what little cash we have left in the bank until our business gets going and the economy improves.
Conclusion
Building a software company is a long journey. Sometimes you make a wrong turn or stumble into a blind alley. We had no way of knowing when we began this process that venture capital would suffer a major contraction in 2009. It was a reasonable choice to make at the time.
I think that deciding not to go forward with our patent application is a reasonable choice now, given the economy and our need to bootstrap the business longer than we planned.
But that doesn’t make the decision any less hard to make.
