{"API Patents"}

Patent #20150363171: Generating Virtualized API From Narrative API Documentation

I like to pick worrisome patents from my API patent research and share them on my blog regularly. Last week I talk about Patent #US9300759 B1: API Calls With Dependencies and today I want to talk about patent #US09471283: Generating virtualized application programming interface (API) implementation from narrative API documentation, which according to its abstract is:

A virtualized Application Program Interface (API) implementation is generated based upon narrative API documentation that includes sentences that describe the API, by generating programming statements for the virtualized API implementation based on parsing the narrative API documentation and generating the virtualized API implementation based on upon the programming statements for the virtualized API implementation. The parsing of the narrative documentation may use a natural language parser and a domain-specific ontology for the API that may be obtained or created for the API. The virtualized API implementation may be generated using an API virtualizer.

I generally won't talk smack about folks filing patents, except I'm a pretty strong believer that the API interface and the supporting elements that make an API do the API thing should be left out. All the elements present in this patent like virtualization, documentation, and narrative need to be open--this is how things work. Just when we are all beginning to get good when it comes to crafting useful APIs, learning to speak in complete sentences with multiple APIs, we are going to patent the process of telling stories with APIs? Sorry, it just doesn't compute for me. I know this is what ya'll do at bigcos, but it's counterproductive.

Instead of filing this patent I wish they would have taken their idea and launched as open source tool, then also launch an accompanying service running in the cloud, and get to work letting us crafting narratives around our APIs. As I've said before, these patents really mean nothing, and it will all come down to keeping an eye on the court filings using the CourtListener API for any cases that are being litigated using API related patents.

It won't stop me from complaining, though. I just wish folks would spend their time on more productive things, instead of slowing down the world of APIs.

See The Full Blog Post

After Looking Through 23414 API Patents I Think It Will Just Come Down To Who Litigates

After looking through the 23,414 API related patents from between 2005 and present day from 4,283 companies, it is clear that the API patent game will be all about which companies decide to litigate using their "intellectual property". There is definitely a lot of education that could occur across all industries where these patents will be put to work, and hopefully we can see some reforms at the USPTO regarding how important it is to the economy that the APIs themselves to remain open and reusable, but I think that ultimately the world of API patents will be hammered out in courts across the United States, and other countries around the world.

While I'm not a fan of the concept of the patent, especially when they are applied to algorithms and abstract ideas, I cannot intelligently argue for companies to not patent the "process that occurs behind the API" (at the moment), however I feel pretty strongly that it is pretty critical that the concept of the API should be left out of the process. At the moment I'm just not knowledgeable enough on the whole software patent world to know what the hell I am talking about, which is why I have my API patent research to help me evolve my awareness and understanding and strengthen my position.

To compliment my patent research, I am going to start pulling any court cases for the 4,283 companies who have filed API related patents across 471 jurisdictions in the United States using the CourtListener API, so that I can identify any potential litigation that involves their patent portfolio. Like the other 75 areas of the API universe that I keep an eye on, I'll just keep watching the patent applications, profiling the companies who are filing them, and see who has the most API patents, and most importantly the ones who are actually using these patents in a court of law.

See The Full Blog Post

23K Patent Applications With API References Since 2005

I am working to organize the 23,414 API related patents from between 2005 and present day, submitted by 4,283 companies--present in my API patent research. Not all of these APIs are "web APIs", but I think each companies portfolio tells a lot of what they are doing with APIs, their motivations behind, and is also a reflection on the overall state of the industry.

To help me better understand the growth in API related patents I'm slicing and dicing the data, and publishing in different ways--I recently dumped the number of patents by year and published as a D3.js bar chart.

It is pretty depressing to see the growth in patent applications that mention "application programming interface". I'm not sure what this means, but I know it can't be good for making the web work. I'll keep slicing and dicing things, and see if I can keep deriving any meaning from it all. I'm thinking I will publish each companies patent portfolio by itself, as I work to profile each company to see what they are up to with APIs.

See The Full Blog Post

More Patents Turning APIs Into An Invasive, Royalty Generating Virus

The relationship between API provider and consumer is a fragile one. As an API provider I am offering up my valuable digital asset, data, content, and digital resources. I would like you to take this Application Programming Interface or SDK that I have built, and put it in your business systems and applications. As an API consumer, I'm given access to valuable business API asset, which I'm expected use in a respectful way, that is always in alignment with a providers terms of service -- an environment where so much can go wrong, and does each day.

I watch companies take a wide range of tones when it comes to setting the stage for this relationship. Some companies are super protective of their valuable content (like Marvel Comics), some are very communicative and inviting like Slack (inject your bot into us). where others wobble between a more open, the back to strict, like Twitter has done over the last couple years. In my opinion, it comes down to how you see your digital resources, and your belief in intellectual property -- when I you, I mean you and your investors.

I try NOT to read all the patent notifications that come into my reader, as it fucking depresses me, but everyone once in a while I have to revisit to help remind everyone, what an illness patents will be, when it comes to APIs working. This fragile relationship I speak of above, operates well, or not very well, depending on how loose, or how much friction exists at this layer. There are plenty of examples out there of APIs who do not do well when they restrict, or too heavily meter API consumers. 

To help build an image in your mind. Imagine the Twitter API, and all the apps that have been built on it. OK, now add in Stripe for payments, Dropbox for storage, Instagram for Images, Facebook for Social, Amazon EC2 for compute, and YouTube for videos. Now, think about enforcing copyright on every API design, and patent licensing on each process involved. It will grind these billion dollar revenue engines to a screeching halt. Nobody will build on these platforms if they have to bake your legal heavy design, and process into their business.

Modern web APIs are balance between the technical, business, and politics of how data, content, and algorithms are exchanged. Simple, ubiquitous web technology is working on the technical side of things. Simple, pay as you go, utility based, and tiered access is helping strike balance on the business side of things. TOS, privacy, security, transparency are the knobs and dials of the political side of things, let's not willingly invite in something so invasive, like patents into the API layer. Patent your algorithm, copyright your content, and license your data, but keep the API definition copyright free, and your API process patent free.

In the "secure cloud storage distribution and aggregation" patent I'm reading this morning, its not the patent that offends me. It is the patent being so focused on the API being the thing that makes the patent. Patent how you index, search, and secure your file storage wizardry, but the API design, and operations should NOT be a focal point of your patent. You want people to integrate with your "secure cloud storage distribution and aggregation", bake the API design and process into their businesses, you want the cloud storage industry to speak your API -- don't lock it down, otherwise API consumers will look elsewhere.

See The Full Blog Post

The Unintended Consequences Of API Patents

As I was reviewing patent #20160070605: Adaptable Application Programming Interfaces And Specification Of Same, from yet another person I know, after I pick my head up off the desk, I begin thinking about all of the unintended consequences of API patents. Here is the abstract from this work of beauty:

Aspects of the disclosure relate to defining and/or specifying an application programming interface (API) between a client and a computing device (such as a server) in a manner that the client, the computing device, or both, can evolve independently while preserving inter-operability.

This is something that WE ALL should be building into our clients, and is fundamental to all this API shit even working at scale. This particular patent is owned by Comcast, so I'm assuming it will be wielded in the courtroom, and leveraged in back room net neutrality discussions among cable and telco giants. There really isn't a lot of unintended consequences involved when two or three 1000 lb gorillas battle it out. The little people always suffer in these battles, and there really isn't much I can do--I will leave this to my friends in the federal government to take on.

Where I feel like I should be speaking up more, is when it comes to the patents being filed by my startup friends, like the hypermedia patents I talked about a few months ago. For weeks after I published that story, my friends came out of the woodwork to tell me this is what you have to do in this game, and they are well meaning, and would never ever use the patent for anything bad. Everyone I talked to I respect, and do believe they mean what they say, but its the unintended consequences that keep me up at night.

What happens after your startup is acquired, and you have cashed out, and long gone? Are you going to follow the company who acquired your startup and track on their litigation, and speak up? Maybe spending some of your fortune to protect the little guy or gal? What happens when your startup fails, and your investors parts out your company, and all of its assetts (cough cough patents), what recourse do you have here? Your VC's will assume your friendly stance on patent usage right? Right. 

I know many of you like to brush me off as being an optimistic hippie, and naive of how things work (all without actually looking at my background). My response to that, is you should probably look around a little, understand the beast you work for and the damage they do in the world. I think you should examine your decisions to make when getting into bed with certain money men, and realize the machine you've become a cog in the wheel of. Only then you'll realize that the stories you tell me, and yourself to help you sleep at night, are fairy tales handed to you by the machine that will consume you. 

See The Full Blog Post

If You Are Proud Of Your API Patents Publish Your Portfolio And Showcase Them

I'm going to keep beating the patent API drumbeat, until I bring more awareness to the topic, and shine a light on what is going on. While I will still be my usual self and call out the worst behavior in the space, I am also going to try and be a little more friendlier around my views, and try and help bring more options to the table. This is a serious problem, nobody is talking about, and one that has many dimensions and nuances--if you want my raw stance on API patents, you can read it here

One area I wanted to try and cover, in response to my friends trying to convince me their aren't bad people, in having patents. I know you aren't, and it isn't my goal to make you look bad in this, it is only to shine light on the entire process, how broken it is, and call out the worst offenders. If you truly believe in patents, protecting the work you've done, and that your intentions are good, share your patent portfolio with the world, and showcase it like you do the other aspects of the work you do. You will craft a press release about everything else you do, do the same for your patents. 

I do not think patents are bad. I think ill-conceived patent ideas, that haven't been properly vetted by the under resourced USPTO, that are used in back door dealings as leverage, and litigated in a court of law are bad. I'll take your word that your patents are good, and you aren't operating in any of these areas, if you are public, transparent, and openly proud of them, as you state in private conversations.

Part of the purpose of my research is to encourage good behavior in the sector, by highlight the common building blocks of the space. I think I will add a patent portfolio building to my research. While I have ZERO examples to highlight, I encourage API companies to do this, and would love to highlight in a positive way, any company that is straight up enough to showcase their patents. If you are proud of your API patents, and do not have bad intentions in having them, please publish your portfolio, show case them as you would anything else you are doing--help bring API patents out of the shadows.

See The Full Blog Post

My Stance On APIs And Patents

My post the other day on the hypermedia API focused patents from ElasticPath, has resulted in some very interesting conversations, with folks trying to understand this world, to those who are patent believers, and those who are just doing what they have to--in a world they do not control. This is why I write these stories, and frankly, it is why I am looking to push the patent conversation to new levels, to bring all y'all out of the woodwork.

In a collective response to these conversations, I wanted to share my stance on patents, when it comes to the world of APIs. Let's start closer to the median, and talk about patents, and the world that "exists today", and explore the common responses when you look to discuss API patents in the current climate.

I Do Not Want To Do Patents, I Only Do Them As a Defensive Response!
C'mon Kin! You do not understand why we have to do patents. We only do them to protect our space, against the worst, of the worst in the tech space--you know SAP, Sun, Oracle, Microsoft, IBM, and the other evil that lurk (the ones with most patents). I get it. It is the same reason all my redneck, and now hippie friends own guns--those over there have guns, and I need to defend myself. You never know when one of those situations will happen, and I will need to defend what I've invested so much to build.

I Need To Generate Intellectual Property (IP), Because It Is How We Define Value!
If I could spend my time as I wish, I wouldn't be writing up patents, and spending money on the patent process. My investors, CEO, and my wider stakeholder's expect that, as a startup, I patent the most valuable of the exhaust from our operations. Ok. So you do this because the people who give you money tell you to? Or do you do this because it actually defines the value you generate as a startup? So, as a startup in 2015, a process acknowledged in ancient Greece, and evolved after the dark ages, and further refined in the industrial age, define you? Ok. #DisruptionW00T!

Patents Are How You Make Money, Do You Know How Much Money IBM, Microsoft, SAP and Others Make?
The amount of money the large enterprise make off their patent portfolios is in the BILLIONS! This is how business gets done, and fortunes are made! This is how the leading companies that we hold up as shining examples make their billions, so why wouldn't I follow in their footsteps? Well, you know, all that disruption, innovation, and other bullshit you hear--that is why! Actually its not, but I'm just trying to use your own marketing against you, to try and change your tune. 

Let's Start With The Basic Differences Between Your View, And My View Of The Space
The concept of the patent process is about taking a unique and innovative process, locking it up, and preventing others from doing it. Which in a capitalist, physical world might make some sense, some of the time, but in a digital world it actually works against the way things actually operate--where reuse, interoperability, and global access is how you reach a wider audience, encourage ubiquitous integration, and yes make money (open source duh?). Locking things up, preventing others from using a successful pattern, and metering that usage doesn't get you as far in this digital world, as it did in the physical world of manufacturing and distribution. #Sorry

In conflict with your world of patents, I am in the business of opening things up, reducing friction, increasingly interoperability, educating more people, and making things work together. I like to make money, but in the end, I'm more in the business of making you money, than I am about making money--you just do not realize it. You are are so short sighted in your view of business, that you do not get what API is. You think SOA didn't work because of some technical flaw, and ignore the role your heavy hand has played in gumming up the gears. Only now are you noticing that API is even working, and you know what? It has nothing to do with you. It has been working because of your absence, and now that your heavy hand has come into play, trust me, shit will slow down. #GiveItTime

The Patent Process Is Broken And Few Actually Care (Or Willing To Talk)
The biggest thing that bothers me in taking my patent stance, and challenging the larger world of patents, is that the process is broken, and that many know, few care, and even fewer are willing to talk about it. Let's start with the basics, in that a process developed in the physical world, applied to physical processes, is transferable to the digital world with no adjustments. WTF! You will argue that taking an existing patent applied in the physical world, reapplied to web or mobile is now worthy of a new patent, but the patent process itself doesn't warrant the same response? WTF! #Broken. We could leave it there, but wait, there is more!

The US Patent Office Is Underfunded, Undertrained, And OverWhelmed With Demand
When you take the time to look through the work that goes into looking for prior works, you realize how little actually goes into the overall patent vetting process. Its less about invalidating an idea for a patent, than it is about make sure it gets approved. The USPTO is just one casualty in a larger war to defund the United States government, and part of the beautiful gift the 1% receives in waging this war. This the how power works. Weaken the process, defund the regulators, and give the power to those who own the patent. You are either smart and innovating, or you are a loser right? #VoteTrump

Patents Are A Rich Persons Game, Something The Rest Of Us Should Avoid
The patent game is for those with the resources, on the front-end and on the back-end. Do you have the time to carve out and define your patent, hire a lawyer to write and file your patent? Do you have the time to wait for the USPTO to approve your patent? Are you filing your patent, or is the company you work for filing the patent? You do!! Now do you have the time, and resources to defend your patent, upon attack by your enemies, in a court of law? A sustained attack? This is the two-sided beauty of how patents are a rich person game. You have to have what it takes to gneerate patents to please your VCs, and to defend against your perceived enemies, but do you also have what it takes to defend in the real world, in a court of law? I do not. Even if I could afford to patent my unique process on patenting APis, I couldn't litigate it ;-)

Nobody Wants To Talk About Patents, Because Someday I Need Funding, Or Will Be In The Club
Blogs like Techcrunch love to do gotcha stories, when it helps the cause of the powers that pull their strings, and similar publications will call foul when really scary patent related cases enters the legal system, but patent filing, and approved applications, in even the scariest of ways rarely make the news. As a patent filer or owner, you rarely talk about your patent portfolio publicly, let alone feed this information to news outlets, and interestingly, very few organizations go looking for this information. Hmmmm....

Patent Conversations Happen Behind Closed Doors, Way Before They Ever Enter A Court Of Law
When I hear the statement that patents are being filed in a defensive posture, focusing in on the legal battles that will no doubt come in the future, from the most aggressive in the space--I hear the passive aggressive tones from the shadows (takes one to know one). This statement leaves out the posturing that takes place behind closed doors, between executives, and investors. Do not tell me your patent portfolio, or perceived patent portfolio (patent pending) doesn't give you leverage in every day dealings, never even bringing litigation into the picture.

Are Patents Sending The Signals You Think They Are In the Space 
I just can't help but think that even though companies are playing the "patent game" by the rules, that they fully understand the signals they are sending. if I am watching the patent filings, and application approvals, and I know you are, don't you think your competition, and potential enemies are? Are you better off gaining a first mover advantage with your "unique process", or are you better off filing a patent for your process? IDK. I'm guessing this depends on how big your company is, and your general position in the space. Which means, I'm guessing it might not mean what you think it means for your little startup, and your view of the value vs. the view of your VC's might differ. Maybe it actually makes you a target for other types of bad behavior, and in the end, if necessary some actual patent litigation.

Patents Are Like Guns, I'm Doing Them Because Everyone Else Is Doing Them
Each time I listened to the stories of why my friends are doing patents over the last week, I think about the same stories I mentioned above from friends on why they have guns. Only difference is I have a long history with guns (love em), and not so much with patents. My friends have guns, because there are many other bad guys out there with guns, creating this really amazingly hostile environment, where nobody is safe. As a former thug, guess where you go rob when you see yourself as top tog in a market? You go rob the guys with all the guns, who might not have the resources to actually defend them. Guns have enjoyed much more "need" in the past, much like patents, but in the current climate we live in, we need to reassess their role, not do away with them, just take another look at the process involved--we should do the same with patents.

Patent Trolls Is Just The Illness Coming To the Surface Of Tech Space
The reason patent trolls can exist in this environment, is because of the buy / sell nature of companies, the scale at which the USPTO is equipped, government downsized, and coming down to who can actually afford the lawyers in the on-boarding, as well as offensive or defensive portion of the long patent game. If you have ever seen patent litigation play out, you know such a small portion of it is ever public, so what we hear publicly about the problem, is a very small piece of what is going on. This is just the part that plays out in the courtroom, and NEVER touches on what happens in the boardrooms of leading tech companies, or the investors behind the curtain.

Now We Get To The Part Where You Actually Hear My Stance On The Patents As They Apply To APIs
The concept of patent is broken, and the process that is patent is broken. For this reason I do not believe in it. Then you add the fact that it is a rich persons game, seals the deal for me. I cannot afford a patent, even if I wanted to, something that makes it an agent of power in my world. Something that also makes it such a hypocritical tell for startups. Why don't you push out press releases on your patents, that your VC's require you do? Alongside all of the innovation and disruption press releases? Oh yeah, we are using this really old process of the existing power structure. That is right, we aren't actually that proud of our patents--unless we work for IBM.

I Cannot Support This Concept Moving Forward If Nobody Will Stand Up And Fight To Evolve It
As a startup you will dismiss history, so that you can disrupt, find your funding, and convince all of us that your thing, is a thing. Government, banks, unions, institutions, and other entrenched entities are bad, and need disrupting in a digital era, but this centuries old process of locking of business processes, developing intellectual property, and building wealth portfolio deserves NO CHANGE in a digital age? WTF? Are you serious? The same concept applied to the cotton gin, applies to my cotton gin API? Don't even think about it, I've already applied for the patent! ;-) Sorry, I'm just not sold.

I understand why you are doing this, and I will keep accepting your requests to talk about, because I learn a lot along the way, and it is something that continues to anchor me in my stance. You will look to quickly dismiss me because I am not "playing in your league", and I don't understand the stakes, and the rules of the game. #Truth. I would also challenge that maybe you are so caught up in the stakes and rules of your game, you might be missing some opportunity, and potentially a whole other way of operating--one that actually makes all of this work, and less about you getting rich.

See The Full Blog Post

I Just Cannot Get Behind API Patents, Especially When They Apply To HTTP And Hypermedia

I got an email in my inbox, about a new API modeling language from Elastic Path earlier today. The product is called Helix, and is sold as being "the first enterprise-class API modeling language designed specifically for REST Level 3".  

The Elastic Path team is where I first learned about the concept of hypermedia, I believe back in 2011--honestly, I had heard the concept before, but never fully grasped what it was, and the potential until 2011 (I know I am slow). However it has been an awareness that has grown rapidly, the more I learn about hypermedia, study how people are practicing hypermedia, and even dabble in it myself with my curation, and building block APIs.

Elastic Path is an expert in the area of hypermedia, so it makes sense they would step up with some hypermedia focused API tooling, and even a modeling language. No surprises here, but where I was a little surprised, was when I read the "Why Helix":

Elastic Path built Helix because existing API modeling languages, such as RAML, Swagger, and API Blueprint, while good for describing standard APIs, are not well suited to designing hypermedia APIs. Elastic Path Cortex, our patented API technology, utilizes Helix definitions and a Helix-compatible implementation, allowing our partners and customers to extend existing APIs and quickly create new ones.

After reading, I wanted to explore the portion of their description that states, "Elastic Path Cortex, our patented API technology, utilizes Helix definitions and a Helix-compatible implementation, allowing our partners and customers to extend existing APIs and quickly create new ones.", but specifically the "patented API technology". Something a quick Google Patent search discovers as defined five separate patents held by Elastic Path

Linking functionality for encoding application state in linked resources in a stateless microkernel web server architecture
Publication # US9143385 B2
A method of serving a resource to a client via a computer network is provided. The method may include at an HTTP server system having a stateless microkernel architecture, the server system including one or more link resource servers, receiving an HTTP request for a resource from an HTTP client via a computer network, the request being to perform a resource operation, the resource operation being to retrieve the resource and send the resource to the requesting client, wherein the resource is a data object. The method may further include determining if the resource operation is authorized based on the request. If the resource operation is authorized, the method may include sending the resource operation to an object server associated with the resource identified by the request, in response receiving a data object from the object server, providing, via a linking engine, the data object to each link resource server of the one or more link resource servers, in response receiving one or more links from each of the one or more link resource servers, embedding the links in the data object, and sending the data object to the requesting client via the computer network.

Follow location handler and selector functionality in a stateless microkernel web server architecture
Publication # US8959591 B2
A method of serving a resource to a client via a computer network is provided. The method may include providing a follow location handler logically positioned on a WAN side of an HTTP server. At the follow location handler, the method may include receiving a POST request from the client, and forwarding the POST request to the HTTP server. At the HTTP server, the method may include receiving the POST request, creating a modified data object based upon the form data, generating a link to the modified data object, and returning the link. At the follow location handler, the method may include intercepting the link to the modified data object from the server, sending a GET request to the server to retrieve the modified data object, and, in response, receiving the modified data object. The method may further include forwarding the modified data object to the client.

Stop condition functionality in a stateless microkernel web server architecture
Publication # US20130179498 A1
A method of serving a resource from an HTTP server system having a stateless microkernel architecture and one or more link resource servers is provided. The method may include generating a data object in response to an HTTP request, sending the data object to each of the link resource servers, and at each link resource server receiving the data object from the handler and examining the data object for pre-determined information to perform a linking operation. The method may further include if the data object includes the pre-determined information, performing the linking operation by returning one or more links to the handler linking to related information provided by the link resource server. The method may further include if the data object does not include the pre-determined information, not performing the linking operation and instead returning one or more stop condition links indicating that the pre-determined information is not included. 

Stateless microkernel web server architecture with self discoverable objects
Publication # US20130179545 A1
A method is provided for exchanging a self discoverable data object between a client executed on a client computing device and a server with a stateless REST-compliant software architecture, which is configured to reply to HTTP requests from a browser engine of the client and to messages from a runtime executable program executed by a runtime executable program interpreter of the client. The method may include receiving an HTTP response from the server, the response including the data object, the data object including a self entity including a URI and a content type of the data object, passing the data object to the runtime executable program at the runtime executable program interpreter for processing. The runtime executable program may communicate with the server using the URI and content type of the data object. Cache controls and an HREF may also be contained in the self entity. - https://www.google.com/patents/US20130179545?dq=inassignee:%22Elastic+Path+Software,+Inc.%22&hl=en&sa=X&ved=0ahUKEwiRnsHvlaXKAhVC9GMKHbyMAuIQ6AEIOzAE

Encoding application state in linked resources in a stateless microkernel web server architecture
Publication # WO2013102272 A1
A method of serving a resource to a client via a network is provided. The method may include at an HTTP server system having a stateless microkernel architecture with one or more link resource servers, receiving an HTTP request from an HTTP client to perform a resource operation to retrieve a resource data object. If the resource operation is authorized, the method may include sending the resource operation to an object server associated with the resource identified by the request, and in response receiving a data object from the object server; providing, via a linking engine, the data object to each link resource server of the one or more link resource servers; and in response receiving one or more links from each of the one or more link resource servers, embedding the links in the data object, and sending the data object to the requesting client via the computer network.


I know you all think I'm some hippie dippie API dude, who doesn't get all this VC driven, business shit you are all calling startups, and innovation, and you are probably right. However, I'd argue that many of all you really do not get this Internet, or API thing either. This is a hard one for me, because I've worked with Elastic Path since way back in API Evangelist history, and I personally know and love their team. So its hard for me to call bullshit on this, but I have to. 

I'm not all the way through the detail of the patents, but in my opinion, they should never have been approved. They go against everything that is the Internet, and why APIs work. The only thing I see unique in the patent titles, abstracts, and art, is the term "microkernel". Not sure exactly what that is, but the rest of it sounds like what we are all already doing with APIs to me--correct me if I am wrong?

Luckily patents are coming back onto my radar, thanks to my lovely partner in crime doing the research for her piece, Ed-Tech Patents: Prior Art and Learning Theories. Her work, and this release from Elastic Path is encouraging me to spend some fresh time going through my patent research, and make sure that I am paying attention to this type of stuff in real-time. I started my dive last January, making it a perfect time to refresh my research in the area.

I swear, with the Oracle v Google, last years Swagger bullshittery, and now this, y'all are going to turn API into SOA, and then everyone is gonna be whining at me that I promised this API thing would work!! Luckily someone will come along with the next thing to sell you fuckers, make money, and y'all can fuck that up too. #IFuckingQuit!

See The Full Blog Post

APIs Are Establishing New And Useful Processes Faster Than Patents Can Keep Pace With

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.

Ultimately I’m left thinking what my friend, and fellow API Evangelist Mehdi Medjaoui (@medjawii) said in his very forward thinking post, that APIs are the new software patent.

See The Full Blog Post

API Patents 2005 Through 2015

I started doing research on API patents recently, and after about 5 days of processing XML files from the US Patent Office, I'm going to stop processing at the year 2004 (way back). This gives me 2005 through present day, and provides more than enough information for me to evaluate the role APIs are playing in the patent process, and inversely how patents are affecting the API space.

In 2004, the XML data files I'm processing start to change, and I'm getting errors, resulting in me having to reconfigure my script, in addition to downloading the numerous, large XML files. I think I have enough of a sampling to start building a wider awareness of what is going on with patents and APIs, I can always come back and download 1995 through 2004.

So far, I have found 16,485 patent applications that had the phrase "application programming interface" in either the title, abstract, or full description for the patent. I found 151 patents that specifically mentioned API in the patent title, and 569 that specifically said it in the abstract. Here is the breakdown by year:

I'm going to continue my API patent journey by reading the 151 patents that specifically mentioned API in the patent title, and the 569 that specifically said it in the abstract. From there, I will expand into the other patent applications and try to understand if the API is more hardware API, or more API adjacent. 

I have a lot of learning ahead, so I don't want to make to many assumptions early on, but looking at the list of companies who have filed patents, it becomes very clear to me that if you want to conduct business in the API economy, you are going to have to at least take a defensive patent stance for your APIs, or these companies will bury you in legal attacks.

There are a number of thoughts swirling around in my head around patents, but a few of them that keep floating to the top are around how damaging the antiquated patent process could be to the API economy, and around why there hasn't been much conversation in this area, as the world of APIs has been heating up over last four years.

After I read more of the patents, I'm hoping I'll better understand what companies are up to, and possibly the motivations behind the patents. Then I'll begin making my own assumptions about how positive or negative patents are to the API economy. 

All I can say now, is what a strange world to try and make sense of. In my opinion the concept of patents apply to a very physical world, and much like Creative Commons has helped evolve the world of copyright in an Internet era, we need something to bring patents into a digital world. A conversation that gets even more complicated when you start thinking about the Internet of Things.

See The Full Blog Post

Finished Processing 973 API Related Patents From 2013

I’m slowly processing XML files of patents from the US Patent Office. You can read the origin of my journey here, but as of today, I finished processing 50 files of patent applications for 2013, adding 973 API related patents to the queue. I’m still making sense of the different types of patents, and whether they are specifically for APIs, more API adjacent, or just mention API as one component in the patent definition.

I figure I’ll go back to about 1990-1995, but not 100% sure at this point. So far I’ve identified 105 patent applications from 2015, 322 from 2014, and now 973 from 2013. I’m still reading the title and abstract of each patent application as they come in, building my understanding of what has been submitted, and the possible motivations behind each application.

Here are the current numbers that I have so far.

There are 6 patents so far that mention application programming interface or API directly in the title of the patent:

  • 12953023 - Providing customized visualization of application binary interface/application programming interface-related information - Red Hat, Inc.
  • 11559545 - 3D graphics API extension for a shared exponent image format - Nvidia Corporation
  • 12832025 - Application programming interface, system, and method for collaborative online applications - Apple Inc.
  • 12974934 - Method and apparatus for reverse patching of application programming interface calls in a sandbox environment - Adobe Systems Incorporated
  • 13178356 - Application programming interface for identifying, downloading and installing applicable software updates - Microsoft Corporation
  • 12716022 - Secure expandable advertisements using an API and cross-domain communications - eBay Inc.

There are 54 patents that mention application programming interface or API directly in the abstract of the patent:

  • 14477614 - System and method for connecting, configuring and testing wireless devices and applications - Jasper Technologies, Inc.
  • 13974635 - Information processing device, information processing method, and program - Sony Corporation
  • 13564610 - System and method for detecting errors in audio data - NVIDIA Corporation
  • 13744892 - Configuring and controlling wagering game compatibility - WMS Gaming, Inc.
  • 13858506 - Method and system for providing transparent access to hardware graphic layers - QNX Software Systems Limited
  • 11110293 - Directory features in a distributed telephony system - ShoreTel, Inc.
  • 12875132 - Lighting control system and method - Lumetric Lighting, Inc.
  • 13283872 - Unified transportation payment system - LG CNS Co., Ltd.
  • 13244694 - Apparatuses, methods and systems for a distributed object renderer - Zynga Inc.
  • 13743078 - System and method for processing telephony sessions - Twilio, Inc.
  • 13793712 - Cross-promotion API - Zynga Inc.
  • 13654798 - Declarative interface for developing test cases for graphics programs - Google
  • Inc.
  • 12267828 - Method and apparatus for monitoring runtime of persistence applications - SAP AG
  • 12559750 - Graphical display of management data obtained from an extensible management server - American Megatrends, Inc.
  • 13146368 - Configuring and controlling wagering game compatibility - WMS Gaming, Inc.
  • 12957479 - User authentication system and method for encryption and decryption - Empire IP LLC
  • 12570012 - Generic user interface command architecture - Microsoft Corporation
  • 13072462 - Adaptive termination - Triune Systems, LLC
  • 12605782 - Digital broadcasting system and method of processing data in digital broadcasting system - LG Electronics Inc.
  • 13244187 - Backup systems and methods for a virtual computing environment - Vizioncore, Inc.
  • 12970873 - Shared resource discovery, configuration, and consumption for networked solutions - SAP AG
  • 12425992 - Command portal for securely communicating and executing non-standard storage subsystem commands - Siliconsystems, Inc.
  • 12535139 - Methods for determining battery statistics using a system-wide daemon - Red Hat, Inc.
  • 12940986 - Integrated repository of structured and unstructured data - Apple Inc.
  • 13354233 - Browsing or searching user interfaces and other aspects - Apple Inc.
  • 12564288 - Detecting security vulnerabilities relating to cryptographically-sensitive information carriers when testing computer software - International Business Machines Corporation
  • 12885706 - Contact picker interface - Microsoft Corporation
  • 12357979 - Computer apparatus and method for non-intrusive inspection of program behavior - Trend Micro Incorporated
  • 12512121 - Method and system for managing graphics objects in a graphics display system - Microsoft Corporation
  • 11559545 - 3D graphics API extension for a shared exponent image format - Nvidia Corporation
  • 11828957 - Apparatus, system, and method for hiding advanced XML schema properties in EMF objects - International Business Machines Corporation
  • 12829714 - Storage manager for virtual machines with virtual storage - International Business Machines Corporation
  • 13073146 - Unified onscreen advertisement system for CE devices - Sony Corporation
  • 12209267 - Method and apparatus for measuring the end-to-end performance and capacity of complex network service - AT&T Intellectual Property I, LP
  • 12832025 - Application programming interface, system, and method for collaborative online applications - Apple Inc.
  • 11633851 - Method and apparatus for persistent object tool - SAP AG
  • 12889083 - Window server event taps - Apple Inc.
  • 12974934 - Method and apparatus for reverse patching of application programming interface calls in a sandbox environment - Adobe Systems Incorporated
  • 13248633 - Ecommerce marketplace integration techniques - Microsoft Corporation
  • 11899197 - Energy distribution and marketing backoffice system and method - Ambit Holdings, L.L.C.
  • 12941026 - Extended database search - Apple Inc.
  • 12209996 - Custom search index data security - Google Inc.
  • 13481814 - Apparatus and method for circuit design - Agnisys, Inc.
  • 12536363 - Seamless user navigation between high-definition movie and video game in digital medium - Warner Bros. Entertainment Inc.
  • 12271690 - Programming APIS for an extensible avatar system - Microsoft Corporation
  • 13178356 - Application programming interface for identifying, downloading and installing applicable software updates - Microsoft Corporation
  • 12716022 - Secure expandable advertisements using an API and cross-domain communications - eBay Inc.
  • 12838128 - Method and system for improving performance of a manufacturing execution system - Siemens Aktiengesellschaft
  • 12459005 - Method and system for providing internet services - Alibaba Group Holding Limited
  • 12858814 - Interaction management - 8x8, Inc.
  • 11684351 - Administrator level access to backend stores - Microsoft Corporation
  • 13048810 - Preventing malware from abusing application data - Symantec Corporation
  • 13271978 - Interfaces for high availability systems and log shipping - Microsoft Corporation
  • 12276157 - Unified storage for configuring multiple networking technologies - Microsoft Corporation

With the other other 1231 mentioning application programming interface or API in the description of the patent. It will take time to understand the scope of role APIs play when APIs are just a metnion in the description, where patents that directly mention in title, and abstract, carry a little more weight. (at least for now)

Another interesting layer so far, were the companies behind the last 2 years of API related patent activity. Here are the top 25 from the list so far.

  • Microsoft Corporation with 118 patents
  • International Business Machines Corporation with 75 patents
  • Google Inc. with 52 patents
  • Apple Inc. with 41 patents
  • Amazon Technologies, Inc. with 26 patents
  • QUALCOMM Incorporated with 23 patents
  • SAP AG with 19 patents
  • Research In Motion Limited with 18 patents
  • Citrix Systems, Inc. with 17 patents
  • Hewlett-Packard Development Company, L.P. with 17 patents
  • BlackBerry Limited with 16 patents
  • Adobe Systems Incorporated with 16 patents
  • Bally Gaming, Inc. with 16 patents
  • Oracle International Corporation with 15 patents
  • Zynga Inc. with 15 patents
  • Cisco Technology, Inc. with 13 patents
  • Symantec Corporation with 12 patents
  • Red Hat, Inc. with 12 patents
  • AT&T Intellectual Property I, L.P. with 11 patents
  • Fujitsu Limited with 10 patents
  • EMC Corporation with 10 patents
  • Intel Corporation with 9 patents
  • CommVault Systems, Inc. with 9 patents
  • Canon Kabushiki Kaisha with 9 patents
  • Enpulz, L.L.C. with 9 patents

I’m still learning, understanding, and making sense of these API related patents I’m mining. I will work to read, and separate out the hardware related APIs, but only slightly off to the side, as I still think hardware APIs are extremely relevant with the latest IoT evolution. During the process, I’m sure I’ll come up with other buckets to put APIs into, but ultimately looking to understand the role that APIs are playing in the patent game.

I suspect that downloading the last 20+ years of patents, processing them looking for the phrases “application programming interface”, or the acronym API, is just the beginning. As I read through the patents, learn about the ideas, people, and companies behind them, I’m sure my understanding will expand greatly. I’ll check in with more data after each import of files, and discovery of any new insights, and as always, you can find my patent API research repository on Github.

See The Full Blog Post