APIs Are Establishing New And Useful Processes Faster Than Patents Can Keep Pace With03 Feb 2015
I’m spending a lot of time reading API related patents lately. I downloaded all of the patent applications between 2005 and 2015, filtered for all patents that mention “application programming interface” in the title, abstract, or description of the API, resulting in a database of 16,485 patents. Currently I’m reading the 700+ that just mention API in title or abstract, and once done I’ll take a look at the rest.
First, let me state that patents are not a concept I subscribe to. Personally, I do not believe in defining, and locking up ideas, but I do not live in the world I’d like, and after beginning my patent API search, I see patents are a concept that like API copyright, will be increasingly wielded across many industries where APIs are being put to use. For this reason, I engage in my research, and overall patent awareness journey, not because I’m a believer in the patent system, or am looking to submit any patents--I want to better understand how patents are being used to define API processes, and help see the evolving role APIs are playing in the larger patent story over the last 20 years.
First, What Exactly Is An API Patent?
There are many incarnations of API, and making sense of whether a patent directly describes a specific API, or is more API adjacent can be very difficult to do. I’m operating under the assumption that if “application programming Interface” is present in title or abstract, it is likely that the patent describes an API fueled process, and my initial review of the 700+ patents support this. This realization moved the conversation in my head from “will patents affect APIs” to “APIs are being patented”, and we need to better understand what is going on, regardless of the precise definition of what an API is. Whether an API is more hardware related, system or specifically a web API as we know it today, becomes somewhat blurred on the current Internet landscape.
Precise vs. Broad Stroke Patents
One thing that really stands out as I read these API patents, is the varying scope of the API definition. Some are very precise, talking about a specific API call, to accomplish a very specific, granular task. While others are very broad, talking about using APIs, for an industry-wide use. This distance, represents the rapid expansion of the API space, and how the vision from technologist to technologist will vary widely on how aware of change they are in their specific domain. Some companies seem to just cast a wide net, claiming a whole region of cyberspace, as operating under their patented idea, with little or no regard for many iterations that have evolved within this very space, in just the time they've submitted the patent.
Internet of Things Blurring The Landscape
As I read through patents, it is easy to dismiss some of the application because they are very hardware focused, but when you consider the bigger Internet of Things (IoT) picture, where everyday, common devices are being connected to the Internet, using APIs—things get very blurry. A hardware API in the 1990s was definitely something that was pretty novel, and useful, but in 2015 these concepts are rapidly expanding, becoming commonplace, with the iterations and variations of process occurring at a staggering rate. I’m considering pulling patents all the back to 1995, to evaluate telecommunication era APIs, for re-use, and applying in the IoT era, in hopes of bringing more focus to this blurry portion of the API patent landscape(or quite possibly confusing myself further). What was once a pretty specific hardware specific API in 1998, could have thousands of uses, in an IoT crazy 2015.
The Pace of Change — New & Useful Processes At A Breakneck Speed
After reading the handful of patents that I have, as an API architect, my brain immediately sees the variances in their patent ideas, that when actually applied as an API would become the programmatic points where I can add variety, and iterate on the process being defined. If it's a new and useful way for analyzing network traffic using an API, I can immediately define hundreds of network scenarios with software defined networking, and then exponentially augment with different user and device scenarios on different ends of this patented process. At what point do all my variations fall prey to this patent, requiring me to cut a deal with patent owners, and at which point do my variations begin breaking the established patent idea, as the world that the definition applies to continues its rapid expansion. The automobile patent was new and novel until Henry Ford came long, and the automobile became ubiquitous, Amazon Web Services implementation of compute and storage was new and novel when it came out, at what point does is it just become the way things are done. The Internet is just escalating this process, which each passing moment—something the patent process doesn’t acknowledge.
How Does US Patent Office Maintain The Army Of Domain Experts To Determine What Is New & Useful?
As I read a patent about a specific API analytics patent, something I’d consider myself a domain expert in, I’m thinking this isn’t that novel or new, and is something that has been going on a while, and then I find several more variations on the same subject, with varying scopes, muting each patent along the way. As I read through some of the networking based API patents, which I probably do not consider myself a domain expert, I think WOW, that is pretty new and novel idea, to almost each one, with very little awareness of scope of each idea. I have to ask myself, how does the US patent office maintain the army of domain experts needed to keep pace with what is truly new and useful in this digital age? There is no way this can occur under a single government or institutional entity anymore, it has to be done openly on the Internet, in real-time.
APIs Are All About Re-Use, Remix, And Defining New & Useful Processes
As an API architect, I can confidently say that APIs are all about establishing definitions of new and useful processes, that if you do properly, allows you to re-use, remix, and redefine a sometimes dizzying amount of variants in that new and useful process. Each API or microservice is a single, potentially well defined process, and when you start daisy chaining, stacking and remixing with APIs, you can rapidly rethink legacy processes, with an agility that is seldom seen in the physical world, or earlier evolutions in software development. Ultimately I feel that the patent process is the antithesis of an API, but at the very least, I would make the argument that it is a very antiquated way to look at how we operate in a digital world.
1000LB Gorillas Are Filing Patents — Not The Doers, Defining Next Generation Processes
Another thing that stood out to me, when evaluating the 16K API patents I’ve targeted, is exactly who the characters are that apply for API patents. The two leading the charge are Microsoft and IBM, with a who’s who of enterprise dominating the list after that. The companies and individuals doing patents, are not the doers, at the forefront of each business sector, who are actually defining the next generation of new and useful processes using APIs, that are increasingly spanning both our virtual, and physical worlds. While I don’t have the research done to back this claim, at first glance at the areas in which API patents are being defined, this world does not reflect the API space I’ve been mapping the expansion of. Which tells me that there are two distinct layers to this API expansion, those that are defining and moving almost every industry being touched by APIs forward, and those that are filing definitions with the patent office to define, make bets on, and ultimately lay claim to what might be.
Doing Patents As A Defensive Measure — Its How You Play The Game!
I am sure there are numerous motivations for filing a patent on an API, and the popular claim is to say you are doing it as a defensive measure. Clearly software patents is a game of hardball, where companies can make or break your cool new startup, by burying you in legal woes—I’ve been there myself. Companies like Tesla, and Google are making an open patent pledge, stating that they only do patents as a defensive maneuver. I get this. I can’t argue with companies defending what they’ve built against the more aggressive corporate personalities in the space. I guess this is why I am building, and curating my database of API related patents, and the companies behind them, so that I can eventually connect it to actual litigation by these companies—only time will tell which open patent pledges actually hold out to be true.
Patents Are Rich Person’s Game — We Don’t All Have The Resources To Play!
To play in the patent game, you need money. You have to be able to afford to file your patents, and you need to be able to afford to defend them in court. This is not a doers game, it is a rich person’s game. My everyday world would be an extremely fertile environment for the defining of patents, as I spend my days playing with thousands of API resources, and deeply thinking how these APIs could be used in new an novel ways in our personal and business lives. However without the resource ($$) to be able to file the patents, and defend these virtual, API driven spaces, in a court of law, patents are a game I will never participate in. I can guarantee there are thousands of patentable ideas laying around my workbench, but because patents aren’t a concept I subscribe to, and I don’t have the resources to play in the game, you will never see a patent with my name on it.
Still Not Convinced You Can Define And Lock Up Ideas, Let Alone API Driven Ones
Even after about 60+ hours of patent API research, I’m still not convinced the patent process is something that is applicable in the API space. I’m barely sold on the concept when it involves the assembly of gears, conveyer belts, and physical elements, let alone with the new and useful process is algorithmic, allowing me to orchestrate infinite number of processes using APIs. I’m preparing a keynote talk in Sydney Australia next week, about the opportunities for orchestration with microservices and docker containers, using machine readable definitions like APIs.json and Swagger. As part of my work, I defined 18 specific processes that I depend on to operate as a business, and as soon as those were defined and deployed, I quickly define 8 new iterations on top of the existing processes. I’m still defining my overall approach to API orchestration with virtualized containers, but once ready, I will be able to define a new node on my network in seconds, and remix with other resources instantly, reworking existing processes and defining entirely new ones each day—why would I want to lock these up, I need these ideas to flow to be successful. Execution trumps definition.
If We Are Going To Apply Patents To APIs, We Need A Process That Will Keep Pace
Ok, say patents are even a thing we should be considering applying in the API space. At the very least we need a process that will keep pace with the world of APIs, and acknowledge not just the accelerated pace of change and iterations, but also the exponential variations that can occur, and the potential change of scope, in near real-time. I do not manually apply copyright to all my writing in 2015, because of the Creative Commons I can apply copyright across all of my digital exhaust—why are processes and workflows any different?
I strongly believe the concept of patents is counter to the essence of what an API is, but if we insist on defining our new and useful processes in this way, we need a real-time way of capturing the intellectual exhaust from processes we execute, map out the new and useful processes that exist, in a way that requires them to have to actually be useful and implemented, while also having a way to share and vet these definitions with the public audience, whether it be industry, government or both. I’m just getting started with my API patent research, and as with my other research in the API space, I’m sure my awareness will continue to expand rapidly, something I doubt I will also see with the patent process itself.