Amid The API Copyright Controversy, An API Patent Claim Surfaces

Editor's Note: As far as ProgrammableWeb knows, APIs themselves cannot be patented. Copyrighted? That's before the Supreme Court to decide in the case of Oracle v. Google. But patented? So, when we encountered a claim of an API patent from an API provider, we immediately challenged it on the grounds that APIs cannot be patented and that such claims will only further confuse the issue of API intellectual property beyond the point that the question of copyrightability (introduced by Oracle's case against Google) already does so. As a result of our inquiry, the API provider retracted the claim but left open the possibility of the claim surfacing again.

Every morning, the ProgrammableWeb editorial team gathers via Google Hangout to discuss what happened in the API economy over the last 24 hours and then we decide what we're going to do about it. Each of us has our own technique for scrubbing the Web down for anything noteworthy and before the meeting, we all contribute our findings to a shared Google Doc. Some of our "discoveries" get assigned to writers to cover as news. Others turn into new entries in our API directory.

History Repeating Itself?
When a company is found to have violated antitrust laws, one of the remedies is to keep that company from repeating another monopoly. Dating back to the days when Web services were all the rage and IBM and Microsoft were declaring their intellectual property rights to Web service protocols like SOAP, WSDL, and UDDI, the US Department of Justice was concerned that Microsoft might repeat a monopoly. It was then that I began to pay very close attention to antitrust laws, the nuanced differences between the various intellectual property rights (patents, copyrights, trademarks, etc.) as they apply to technology, and the legal ins and outs of open source licensing. 

That history has a particular application today now that Oracle's lawsuit of Google is before the Supreme Court in a landmark case that will ultimately determine if APIs can be copyrighted or not. Java APIs were essentially "copied" [sic] once before when Microsoft came up with a version of desktop Java for Windows and Internet Explorer that not only responded appropriately to desktop Java APIs, it also offered extensions that that bridged Java functionality into Windows and vice versa. In 1997, Java's inventor Sun Microsystems (much later acquired by Oracle) sued Microsoft. But interestingly, not for API copyright or even patent infringement. Rather, it sued Microsoft for breach of contract over its usage of the Java trademark. Back then, in order for anything to use that trademark, it had to pass a very rigorous suite of compatibility tests that proved 100% compliance with the Java specification. Microsoft bypassed this requirement and used the Java trademark anyway. Sun sued and eventually prevailed in an out-of-court settlement.

In a May 2014 ProgrammableWeb APIcon conference session that debated the merits of API copyrights in the wake of Oracle's lawsuit against Google, attorney Annette Hurst was one of the panelists representing the law firm Orrick that has been Oracle's legal counsel in that contest. At one point in the debate, Hurst alludes to the potential hypocrisy raised by the objection to Oracle's suit of Google over Java while Sun prevailed in its lawsuit over Java against Microsoft.

But there were two key differences between the two lawsuits. Sun's lawsuit was over breach of contract and trademark misuse versus API copyright infringement and, at the time that Sun sued Microsoft, Java was a proprietary technology subject to Sun's licensing terms. By the time Google included its forked version of Java in Android, Java had long-since been contributed by Sun to the open-source community and Google was not putting the Java trademark on its product as though it were claiming full compatibility with Java. One of the main tenants of open source is the ability for developers to fork it as Google did. 

As you can see, the nuanced differences between the various forms of intellectual property are critical to any discussion, particularly when it comes to APIs.  This brings us to a recently issued press release regarding PokitDot's announcement of a specialized calendaring system for the healthcare industry. That press release said the following:

"While the $2.9B health industry has made tremendous gains in the last decade employing Electronic Health Records (EHR), most group practices lack an electronic calendaring program that captures availability of every physician in the network. PokitDok puts it all under one roof through a patent-pending Application Programming Interface (API) for developers."

Already, there's a raging debate about the copyrightability of APIs that has reached the Supreme Court and along comes PokitDot claiming to have a patent pending on an API (this is the first time that ProgrammableWeb has ever heard of a potential patent on a the API itself; a Web API that is). 

What's the difference between a patent and a copyright? Does it even matter? You bet it does. Let's say there's a business process (and there is and most of us are familiar with it) whereby a scanner can scan a QR code that in turn triggers a Web browser to open a tab to a specific Web address. Supposing no patent exists for that business process, I can create and sell an implementation of that process using Objective C as my coding language and iOS as my target platform. But once I write that code, I have a copyright to that code. If you create the same implementation by copying some or all of my code without a license from me, then you are infringing on my copyright and I can sue you. 

But let's say someone has a patent on the business process itself (which someone very well could). Then it wouldn't matter if I built an implementation using Objective-C, Javascript, Java or bacon and eggs. No matter how I build that implementation, so long as it implements the patented business process, the patent-holder can sue me and anybody else with an implementation for patent infringement. 

Therefore, the idea that an API could be patented raises all sort of red flags. If it's possible to represent a business process in an API itself (and I'm not convinced that you can), then that business process is patentable. But to the extent that an API is simply one implementation of a business process and there are other potential implementations, the API itself is not, in my opinion, patentable. Is it copyrightable? That's a separate question that is currently before the Supreme Court. But here at ProgrammableWeb, we reject the notion that APIs themselves should be copyrighted. Keep in mind that I am not a lawyer. This is just the opinion of one layman who has paid absurdly close attention to the intersection of technology and intellectual property law for well over a decade.

So, after seeing the press release, I reached out to PokitDot to find out more about its claim to have a patent pending on an API. I also asked for a link to the pending patent. Via email the company's CTO and co-founder Ten Tanner responded:

"PokitDok is patenting the system and method for scheduling (that uses an algorithm) and the API is the interface to the system and method for scheduling. The patent application is provisional, so it isn't public and will remain private for intellectual property protection reasons. The press release on Wednesday may not have been worded in the clearest way, so that piece was removed, but it does remain a gray area. What is clear, regardless of the outcome of the Oracle vs. Google case, is that patents will play an important role in emerging business models in health. This is especially true as the API economy takes hold, which is a key reason PokitDok has taken measures to patent our approach."

Indeed, the offending line about the patented API has been removed from the canonical Business Wire copy of the press release (from which other copies such as the previously linked Yahoo one was made). In his statement, Tanner appears to clearly distinguish between a patent on a "system and a method" and the API as the interface to that system.

While ProgrammableWeb doesn't share the view that it's a gray area, there is some truth to Tanner's reference to the API economy. That's because, as mentioned earlier, a patent can be issued for a business process independent of implementation. Therefore, an implementation of a patented business process that includes the usage of certain APIs could easily constitute patent infringement. For example, if someone patented the business process of automatically routing a photo from a digital camera to an online Web site, then an implementation that routes photos from a camera to Twitter using an EyeFi card, an IFTTT-based API, and Twitter's API could infringe on that patent regardless of what IFTTT or Twitter think. So, while the APIs themselves might remain unpatentable, their usage within a patented business process might constitute an infringing implementation which in turn could be the source of significant intellectual property confusion. 

Finally, Tanner statement did not answer the question of whether or not Pokidot sought, is seeking, or will seek a patent on the API itself. So I asked via email and after not receiving a reply for two days, I published this report. If I do get a reply, I will update this post.

Update 1/26/2015: Over at APIevangelist.com, in response to this post, Kin Lane has done some additional research on API patents and has discovered "428 patents where 'application programming interface' shows up in the title, abstract, description, or anywhere else in the content of a patent application."  He's digging deeper because some of these patents don't necessarily apply to the Web-as-a-Platform APIs (not just HTTP, but others like APIs in the browser) that he and ProgrammableWeb spend most of our time on. But Lane has so far concluded "APIs are being patented at an increasing rate, and is something we just don't talk about publicly."  

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.

Comments