This website is currently dormant!

API Definitions Blog

These are the blog posts I've writen on API Evangelist that I've tagged as "definitions". Usually because they have some elements that speaks to why or how we should be defining our API operations.

This Weeks Troubling API Patent

I found myself looped into another API patent situation. I’m going to write this up as I would any other patent story, then I will go deeper because of my deeper personal connection to this one, but I wanted to make sure I called this patent what it is, and what ALL API patents are–a bad idea. Today’s patent is for an automatch process and system for software development kit for application programming interface:

Title: Automatch process and system for software development kit for application programming interface Patent# : US 20170102925 A1 Abstract: A computer system and process is provided to generate computer programming code, such as in a Software Development Kit (SDK). The SDK generated allows an application to use a given API. An API description interface of the system is operable to receive API-description code describing one or more endpoints of the API. A template interface is operable to receive one or more templates of code defining classes and/or functions in a programming language which can be selected by the selection of a set of templates. A data store is operable to use a defined data structure to store records of API description code to provide a structured stored description of the API. A code generation module is operable to combine records of API with templates of code which are arranged in sets by the language of the code they contain. The combining of records and code from templates may use pointers to a data structure which is common to corresponding templates in different sets to allow templates of selected languages to be combined with any API description stored. Original Assignee: Syed Adeel Ali, Zeeshan Bhatti, Parthasarathi Roop, APIMatic Limited

If you have been in the API space for as long as I have you know that the generation of API SDKs using an API definition is not original or new, it is something that has been going on for quite some time, with many open source solutions available on the landscape. It is something everyone does, and there are many services and tooling available out there to deliver SDKs in a variety of languages for your API. It is something that just isn’t patent worthy (if there was such a thing anymore). It shouldn’t exist, and the authors should know better, and the US Patent Office should know better, but in the current digital environment we exist in there isn’t a lot of sensibility and logic when it comes to business in general, let alone intellectual property.

I haven’t pulled any patents as part of my API patent research in some time, so this particular patent hasn’t come across my radar. I was alerted to the patent via a Tweetstorm, shared with me in Slack by Adeel (one of the authors of the patent):

In which my response was, “oh. ouch. well, gonna have to think on this one sir. I’ll let you know my response, but I’m going to guess you might not like how I feel either. I’m not pro-patent. let me simmer on it for a couple days and I’ll share my thoughts.” As I was simmering I was pulled into the conversation again by Tony Tam:

In which my response was:

I was taking my usual time, gathering my thoughts in my notebook. Taking walks. Simmering. Then I wake up Saturday morning to this Tweet:

The comment did get me to Tweet a couple times, but ultimately I’m not going to engage or deviate from my initial response to gather my thoughts and write a more thoughtful post. The machine wants me to respond emotionally, fractionally, and in ways that can be taken out of context. This is how the technology space works, and keeps you serving it’s overlords–the money folks behind.

I do have to admit, when I first responded I was going to take a much harder line against APIMATIC, but after seeing the personal attacks on Adeel, his attempts to defend himself, then this no presence Twitter account coming at me personally, bringing into question that maybe I was being paid to write articles I changed the tone of this story significantly. The conversation around this patents shows what is wrong with the business and politics of APIs, more than anything API patents have done to the community to date.

First, Adeel doesn’t understand the entire concept of what Tony meant when he said patent, any more than he grasps what Tony meant by douchbag. This isn’t a jab at Adeel. It’s truth. Adeel is a Pakistani, living in New Zealand. I’ve spent the last couple of years engaging with him in person, and virtually via hangouts, Slack, and email. I’m regularly having to explain some very western concepts to him, and often find myself think deeply about what I’m saying to make sure I am bridging things properly. Not because Adeel isn’t smart (he’s exceptionally smart), it is just because of the cultural divide that exists between him and I.

Adeel didn’t file their patent out of some competitive ambition, or stealing of open source ideas as referenced in the Tweetstorm. He did it because it is what the academic environment where APIMATIC was born encouraged it, and it is something that is associated with smart ideas by the institution. This concept isn’t unique to New Zealand, it is something that still flourishes in the United States. Where the cultural bridge was necessary, is when it comes to why patents are bad. In these academic environments, you have a good idea, you patent it. It is something that historically acceptable, and encouraged. You see this across institutions and within enterprises around the globe, with patents as a measure of individual success. Adeel and his team had a good idea, so they patented it, he didn’t think he was doing anything wrong.

Addeel isn’t being any more aggressive or vindictive than Sal or Matt were with their hypermedia patents, or Jon Moore were with their patents. It is what their VCs, companies, and parent institutions encourage them to do with their good ideas (go after them and make your mark on the world). I fault all of these individuals just as much as I fault Adeel, or even Tony for that matter, when it comes to the name of an open source product suddenly becoming a trademarked product. Ironically this conversation is going up, right after a post regarding how much I respect Tony for his work, despite me be VERY upset about Swagger not remaining attached to an open source product we all had contributed so much to, and helped spread the word about. If we are worried about the sanctity of open source, we should be defending all dimensions of intellectual property. I know, not a perfect comparison, but I imagine Tony feels similar to what I did when this happened. Which I let him know via email, but have never gone after anyone individually, or personally, sicking my dogs on him, although I’m sure it might have felt that way.

All of this makes me think deeper about the relationship between open source and APIs. What are the responsibilities of companies who wrap open source technology with an API and offer a commercial service? How does licensing, trademarks, patents, and other intellectual property concerns need to be respected? I’m guessing I could go through many of the API patents in my research and find thatmost filings that did not consider or respect open source offerings that came before them. People had a good idea. They were in an environment that encourages patents, and they filed for a patent to show their idea was worthwhile–that USPTO stamp of approval is widely recognized as a way to acknowledge your idea is worthy.

I want to make clear. I am not defending patents. I am defending Adeel. I am doing so strongly, because of the no name person who decided to chime in and question the credibility of my API storytelling. Otherwise I would have laid things out, and told Adeel he needed to learn the lesson and move on. I just saw everyone piling on Adeel like he was a bad person, and some tech bro just patenting things to get the upper hand. I have known Adeel for years, and know that is not the situation. Once I started getting piled on as well, then it switched things into personal mode for me, and now I feel the need to defend my friend, but not his actions. The tech community loves to pile on, and I deal with wave after wave of tech bros who don’t read my work and accuse me of things that people who DO read my work would NEVER acuse me of. Adeel is my friend. Adeel is an extremely intelligent, honorable, kind-hearted person, and it pissed me off when people started piling on him.

Now that you understand my personal relationship, let’s address my business relationship. I am an advisor to APIMATIC. Not because I’m paid, or there are stock options, it is because he is my friend. In August (couple of weeks ago), Adeel and his investors had offered me a 0.25% share capital in the company but there has been no paperwork, nothing signed, and no deals made as of today. Honestly, after the $318 check I got for my latest advisory role, which I spend about 60 hours of work on, and travel costs out of my own pocket, I have little interest in pushing the conversations forward to the point where things ever get formalized. It just isn’t a priority for me, and damn sure has never influenced my writing about APIMATIC, let alone a story from June of 2015, like the Tweetstorm participant accused me of, without doing any due diligence on who I am. You are always welcome to ask ANY of my partners if I take money to write positive things about their products, or guest posts, you’ll get the same answer from all of them–it is something I get asked regularly, and just don’t give a shit about doing.

API patents are a bad idea. Patent #US 20170102925 A1, for an automatch process and system for software development kit for application programming interface is a bad idea. API patents are a bad idea because people think they are a sign of being smart when they are not. API patents are a bad idea because corporations, institutions, and organizations keep telling people it is a sign of being smart, and people believe it. API patents are a bad idea because the entire US Patent system is broken, because it is an intellectual property relic of a physical age, being leveraged in a digital realm where things are meant to be interoperable and reusable. API patents are bad idea because y’all keep doing them thinking they are a good idea, when they just open you up to being a tool that allows corporations to lock up ideas, and provide a vehicle for others to use them as leverage in a court of law, and behind closed doors negotiations. Ultimately whether or not patents are bad will come down to who litigates with their patent portfolios, and the patents they acquire. The scariest part is most of this leveraging and strong-arming won’t always happen in a public court, it will happen behind closed doors in arbitration, and with venture capital negotiations.

Which really brings me to the absurdity of this latest patent Tweetstorm. I’m all for showcasing that patents are a bad idea, and even shaming companies and individuals for doing them. However, I saw this one get personal a couple of times, and even took a jab at me. Y’all really shouldn’t do this shit in glass houses, because patents are just part of your intellectual property problems. The NDAs y’all are signing are a bad idea. Those deals you are making with VCs are mostly bad ideas. Y’all are just as ignorant, or maybe in denial about the deals you are making as Adeel is about the negative impacts of the US patent system. Most of these deals you make will result in your startup being wielded in more damaging ways than Adeel’s patent ever will. Yet you keep doing startups, signing deals, and attacking your competition, and people like me just investing in the community. Adeel is currently reading about patents, which I regret to say won’t provide him with the answers he is looking for. There are few books on the subject. Maybe reading something from Lawrence Lessig might get you part of the way there. The real answers you are looking for come from experience, and that is what you just received. This was an easy lesson, just wait until APIMATIC acquired by a bigco, and see your patents wielded in ways you never imagined–those will be some harder lessons.

I don’t have a problem with calling out Adeel for APIMATIC’s patent–it is what should happen. I have a problem with him being called douchbag, and the other personal attacks, and assumptions on his (and my) character that occurred within the Tweetstorm. By all means, call him out on Twitter. By all means, educate him around the damage to OSS and API community by doing patents. Don’t make these things personal, assume malicious intent, and recklessly begin questioning the character of everyone involved. Also, if you are just spending your time calling out you competitors for this behavior, because it bothers you, and you don’t call out your partners, and the companies you work for, and the services you use for their abusive use of OSS and damaging intellectual property claims, you have significantly weakened your argument, and won’t always be able to count on me to jump into the discussion and have your back. I do this shit full time, with no financial backing, corporate or institutional cover. I’m out here full time, not hiding behind a Twitter handle, holding folks accountable whenever and wherever I can. If you are doing a startup, learn from this story. Educate your institutions, companies, and investors about how API patents are damaging everything we are doing, and never will actually demonstrate you have a novel idea, it is just locking up other ideas.

In the end, everything we know as API is already patented. Look through the thousands of API patents in my research. Hell, Microsoft already has the patent on API definitions, so what does it matter if there is a patent on generating SDKs from API definitions? Also, my patent on API patents is pending, so it will all be game over then. Mwahahaha!! ;-) As Tony said, the patent system is broken. Let’s keep letting our companies, organizations, institutions, and most importantly the USPTO know that it is broken. Let’s keep calling out folks who still think API patents are a good idea (sorry Adeel), and schooling them on the why, but let’s not be dicks about it. Let’s not assume people have bad intentions. Let’s understand the history of patents and that many people are still taught that they are a sign of having good ideas and being what you do as part of regular business operations. Let’s just make sure we also lead by building a better API service or tooling, as Adeel brought up in his defense. Also, when he said this, he wasn’t making this an APIMATIC is better than Swagger Codegen (or others), he is just focused on making a better product in general. I’m sorry but he has. Y’all can focus on the merits of Swagger Codegen vs. APIMATIC, but what he’s done with the SDK docs, portal, and continuous integration, ARE great improvements. Much like the commercial service Swagger has become (ya know, the Swagger in Swagger Codegen) and evolved on top of the open source API specification and tooling Tony set into motion for ALL of us to build upon–thanks again Tony.

P.S. I wouldn’t have been so hard on Tony if I hadn’t been looped in to defend intellectual property and OSS like this. P.S.S. I wouldn’t have been so easy on Adeel, if no name McTwitter account had accused me of selling out when I don’t do that. P.S.S.S. Adeel, patents are bad because people use them in bad ways, and the US Patent Office is underfunded, understaffed, and can’t tell what is good or bad patents–this is the way bigcos want them. P.S.S.S.S. Sorry I’m such an asshole everyone, but I hope y’all are getting somewhat used to it after seven years.

**Disclosure: **I am an advisor to APIMATIC (very proud of it)!

The Patent Application Information Retrieval Bulk Data API

I stumbled across the Patent Application Information Retrieval Bulk Data API from the US Patent Office the other day. It provides a much more usable approach to getting at patent information than what I am using at the moment. Right now I am downloading XML files and searching for the occurrence of a handful of keywords. If I want to make a change I have to fire up a new AWS instance, change the code, and reprocess the downloaded files. The Patent Application Information Retrieval Bulk Data API gives me a much more efficient interface to work with.

The Patent Application Information Retrieval Bulk Data API contains the bibliographic, published document and patent term extension data tabs in Public PAIR from 1981 to present, with some additional data dating back to 1931. It has leveraged COTS semantics, maintains an open architecture, and the query syntax follows the standard Apache Solr search syntax, with API responses following the Solr formats. Providing for a much more powerful interface for querying patent data, which goes back further back in time then what I’ve been doing currently. I’m really interested in doing an API patent search for the 1990s, or maybe even earlier.

The Patent Application Information Retrieval Bulk Data API is a well designed API, with an attractive API portal and documentation, driven with an OpenAPI. The USPTO provide access to the patent data in the way that I think all government agencies should be doing it. You can use the API, or get at a JSON or XML download of the data. The API is “part of the US Patent and Trademark Office’s (USPTO) commitment to fostering a culture of open government as described by the 2013 Executive Order to make open and machine-readable data the new default for government information.” Which is pretty cool in my book, something we desperately are needing to become a reality across all federal agencies in 2017.

Patent Number 9325732: Computer Security Threat Sharing

The main reason that I tend to rail against API specific patents is that much of what I see being locks up reflects the parts and pieces that are making the web work. I see things like hypermedia, and other concepts that are inherently about sharing, collaboration, and reuse–something that should never be patented. This concept applies to other patents I’m seeing, but rather than being about the web, it is about trust, and sharing of information. Things that shouldn’t be locked up, and exist within realms where the concept of patents actually hurt the web and APIs.

Today’s patent is out of Amazon, who are prolific patenters of web and API concepts. This one though is about the sharing of security threat sharing. Outlining something that should be commonplace on the web.

Title - Computer security threat sharing
Number - 09325732
Owner - Amazon Technologies, Inc.
Abstract - A computer security threat sharing technology is described. A computer security threat is recognized at an organization. A partner network graph is queried for security nodes connected to a first security node representing the organization. The first security node is connected to at least a second security node representing a trusted security partner of the organization. The second security node is associated with identification information. The computer security threat recognized by the organization is communicated to the trusted security partner using the identification information associated with the second security node.

I’m sorry. I just do not see this as unique, original, or remotely a concept that should be patentable. Similar to a previous patent on trust, I just don’t think that sharing of security information needs to be locked up. The USPTO should recognize this. I feel like this type of patent shows how broken the patent process is, and how distorted company’s views on what is a patentable idea. Honestly, these types of patents feel lazy to me, and lack any creativity, skills, or sensible view of how the web works.

I feel like I should start rating these patents with some sort of Rotten Tomato score, and start giving companies some sort of patent ranking for their portfolio. Something that encompasses the scope, lack of creativity, originality, and damaging effects of the patent. This reminds me that I need to finish my work pulling court cases from the Court Listener API, and index them for any companies, and their patent portfolios. Ultimately this is where the real damage to APIs and the web will play out, similar to the Oracle vs. Google API copyright affair, but I will keep sharing stories of these ridiculous patents, and maybe even start ranking them all by how much they stink.

Patent Web Of Trust Management In A Distributed System

404: Not Found

Patent #US 20170153932: Adapting Legacy Endpoints To Modern APIs

I made my API patent inventory a little more explorable this week, allowing me to more easily discover new and interesting patents that will affect the world of APIs, which I can include in my research. An interesting patent from eBay quickly floated up to the top as a questionable idea for a patent.

Adapting legacy endpoints to modern APIs:

Example methods and systems are directed to adapting legacy endpoints to modern application protocol interfaces (APIs). A legacy endpoint may provide a powerful and complex API. A modern application may desire access to the legacy endpoint. One or more layers may be added between the modern application and the legacy endpoint. Each layer may provide a different API. These layers of APIs may transform the interface from a powerful and complex interface to a more limited but simpler and easier to use interface. In some example embodiments, a proxy layer, an adapter layer, a facade layer, and a service layer may be used.

Pub Date: 2016/27/06 Number: 09576314 Owner: eBay Inc. Location: San Jose, US Details: Visit USPTO

Adapting legacy endpoints to modern APIs is a fundamental aspect of doing APIs in the first place. It is something that is useful and completely obvious. This is one of those patents that makes me question the competency of folks reviewing patents at the USPTO. If you at all are acquainted with the concept of web APIs, you know that this is something that is already done, and not worthy of the non-obvious aspect of being a patent.

APIs have no place in patents. I think this patent pretty clearly shows the system is broken, and the reasons why many companies are filing patents have reached an unhealthy level, as well as how broken the USPTO is. If they are approving a patent for adapting legacy endpoints to modern APIs in 2016 and 2017, they are pretty out of touch with the digital world that is unfolding around us.

I Published 60K Patents To Github As Part Of My API Patent Research

I’ve been migrating from my own homebrew CMS system over the last couple of weeks, ditching it for a variety of existing services, balancing my operations across a diverse set of platforms I’ve identified as useful. I’m using Github and Jekyll to manage my content system, storing thinks like blog, news, notes, and patents there. Github repos are well suited for storing this type data for free (if it is public), and Jekyll is well suited for helping me manage small to large repositories of content I need to use across my platform.

This last week I migrated 60K patents I had filtered out of all the XML dumps of patents I downloaded, between the years of 2005 and 2016. I filtered out any patent with API or application programming interface in the title, abstract, or body of the patent. Once done importing, I clean up the body a little bit and publish each one as a Jekyll post within a Github repo. I had to break them down by year, as Github started getting wonky after 10K file, but the Jekyll structure works well for managing up to 10K patents. Once committed, I find the Jekyll post and data structure pretty easy to navigate and use for some API storytelling.

I like having the full listing of title and abstract available to search in a single public HTML page. I have also started publishing keyword filters for each area of my research. It is taking me a while to build the index for each JSON API, but it is allowing me to quickly get at cached searches for machine learning, API management, and other patents that affect the areas of the API lifecycle I’m keeping a close eye on. I will keep adding filters and enhancing the ones that I have, but ultimately it takes me reading a large number of patents and then actually tagging each one, that will help me build a useful API patent catalog.

I feel that these relevant patents help tell an important story about each layer of the API lifecycle. Patents add another dimension to the story of what is going on when it comes to API design, deployment, management, discovery, and other areas that are growing in 2017, and in coming years. The products, services, and tooling I track on from organizations included in my API lifecycle research paint a significant part of the picture, but I feel that patents pull back the curtain just a little bit more when it comes to what companies are thinking. I will keep processing new files from the USPTO every couple of weeks, evolving my filters, and tagging patents for better recall in my API patent storytelling.

Patent US9639404: API Matchmaking Using Feature Models

Here is another patent in my series of API related patents. I’d file this in the category as the other similar one from IBM–Patent US 8954988: Automated Assessment of Terms of Service in an API Marketplace. It is a good idea. I just don’t feel it is a good patent idea.

Title: API matchmaking using feature models Number: 09454409 Owner: International Business Machines Corporation Abstract: Software that uses machine logic based algorithms to help determine and/or prioritize an application programming interface’s (API) desirability to a user based on how closely the API’s terms of service (ToS) meet the users’ ToS preferences. The software performs the following steps: (i) receiving a set of API ToS feature information that includes identifying information for at least one API and respectively associated ToS features for each identified API; (ii) receiving ToS preference information that relates to ToS related preferences for a user; and (iii) evaluating a strength of a match between each respective API identified in the API ToS feature information set and the ToS preference information to yield a match value for each API identified in the API ToS feature information set. The ToS features include at least a first ToS field. At least one API includes multiple, alternative values in its first ToS field.

Honestly, I don’t have a problem with a company turning something like this into a feature, and even charging for it. I just wish IBM would help us solve the problem of making terms of service machine readable, so something like this is even possible. Could you imagine what would be possible if everybody’s terms of service were machine readable, and could be programmatically evaluated? We’d all be better off, and matchmaking services like this would become a viable service.

I just wish more of the energy I see go into these patent would be spent actually doing things in the API space. Providing low cost, innovative API services that businesses can use, instead of locking up ideas, filing them away with the government, so that they can be used at a later date in litigation and backdoor dealings.

The Six Dimensions Of API Patents I Dwell On

Each story I publish about API patents will usually get a comment, Tweet, LinkedIn, or other comments letting me know that the owner of the patent is only doing it in a defensive pattern. I fully grasp that this is the predominant stance when it comes to defending a patent portfolio, but I prefer seeing six dimensions to this discussion–looking beyond this single position.

When thinking about why a patent exists I see it in six dimensions:

  • Idea - That someone has an idea, thinks it is theirs and feels that this should exist as a patent.
  • Patent- That some have the resources to craft the patent application, and file it with the patent office.
  • Filing - That the patent authority thinks an idea is patent-worthy, and something that should be approved.
  • Litigation - When someone wields a patent as part of litigation, either in an offensive, or defensive stance.
  • Public Deals - When patent shows up as part of an acquisition, partnership, and wielded publicly as part of some deal.
  • Backroom Deals - When patents are leveraged as part of backroom deals when negotiating with companies and investors, and sizing up the value on the table.

We only have insight into the middle four dimensions. We really don’t have any view into the individual reasons behind a patent, and we do not get access to how they are wielded and leveraged behind closed doors. I think that defending yourself as part of any court case makes sense, but I’m discussing API patents to help shine a light and understand what is happening within the other dimensions.

Overall I find that the existence of patents to speak volumes about a company’s motivations. The way they showcase or do not showcase their API portfolio contributes to this conversation in important ways. Sadly we will never get a full picture of the individual and backroom aspects of how API patents are used. However, I’m confident I can extract enough meaning from the existence of a patent, the information within the application, and any litigation that has occurred to paint a pretty clear picture of the motivations behind having a patent on your API(s).

Patents As A Measure Of Individual Success

I read a lot of patents as part of my work as the API Evangelist, and I tend to stalk and tune into the social media accounts of some of the authors. I have noticed that some of them work at large companies, and are counting each patent they file and are announcing each one like it is a badge of honor. I’m fascinated by this. Each company’s approach to showcasing or downplaying their patent portfolio tells a lot about the company, something that I feel trickles down to each individual author.

The theater of showcasing the number of patents is fascinating to me. I’m not saying it’s a bad thing, just something I think is worthy of more discussion in the modern age. I don’t showcase the number of patents I have filed because 1) I don’t have any patents 2) I cannot afford to file any patents 3) I don’t showcase my ideas, I showcase things I do and the stories I tell. Ok, maybe a patent is a story right? A story about what is possible, that you’ve paid a fee to file with the government, and convinced them that the story is true? I’m just trying to get at the thinking behind this theater production, and why some folks feel that it is a badge of honor.

The biggest differentiator here for me is that I cannot afford to file patents. It is a rich man’s game. Is this why people showcase? To declare they are part of the elite? Even if I could afford to file one patent, I definitely cannot afford to file many patents, and I cannot ever afford to litigate and defend a patent in a court of law. Making patents completely useless to me, even if I wanted to legally define my stories and ideas like this. Another thing that I notice is that there are no individuals filing patents, it is always an individual filing on behalf of a large company who has the money to file, and to litigate on behalf of the patent portfolio, which for me diminishes the individual merit of showcasing–look ma, I got a new patent (for my company)!!

A patent feels like one of those carrots that get dangled in front of individuals to get them to perform while on the hamster wheel. You get told in high school and college by your mentors that the number of patents you have is a badge of honor. However, you never get told that it is your organization that owns the portfolio, and made aware of the closed door dealings or litigation that will occur around your patent portfolio. IDK, it could be that I’m naive and uneducated about the wider world of patents, and how revenue is generated from patent portfolios–it won’t be the first time I’ve spouted off about something I don’t get, nor will it be the last. I write to understand.

Ultimately I think patents are a rich person game, and how a significant amount of ideas are locked up and made part of larger flows of power, or rendered a non-threat. It isn’t a game I’m part of because I don’t operate at that level, which is why it is foreign to me. I’ve never heard someone tell me that they respect someone for their patent portfolio, or that they were an author on a patent. I think patents are one of those legacy stories that used to have meaning and purpose in the industrial world, and long ago became the game of rich folks, while also becoming pretty distorted in the translation from the physical to the digital. It is a game people still showcase as a badge of honor because of mythical stories they have heard those in power tell–they have little to do with your own success or the value of your ideas.

For me, I measure my success based on the stories I tell about my ideas, and the stories others retell about my ideas. I also measure my success based upon the number of my ideas that become real, and are part of everyday practice in an industry, even if I do not receive royalty checks, or able to litigate and make deals based upon my idea portfolio…but, this is just me. I’m an oddball like that.

Patent US 8954988: Automated Assessment of Terms of Service in an API Marketplace

I’m reading a lot of API patents lately trying to understand the variety of approaches these “innovative” patent authors are using to help define the API space. Many of the API patents I have historically objected to tend to patent the technical detail that make the web work or significantly contributes to the integration benefits that an API delivers. Today’s patent does all of this but is focused on patenting the legal details that are needed to make this whole API thing work at scale.

Title: Automated assessment of terms of service in an API marketplace Number: 08954988 Owner: International Business Machines Corporation Abstract: An embodiment of the invention comprising a method is associated with an API marketplace, wherein one or more API providers can each supply an API of a specified type, and each provider has a set of ToS for its API of the specified type. The method includes, responsive to an API consumer having a need for an API of the specified type, obtaining the ToS of each of the API providers. The method further includes implementing an automated process to determine differences between the ToS of a given API provider, and a ToS required by the API consumer. The ToS differences determined for respective API providers are used to decide whether to select a particular one of the API providers to supply an API of the specified type to the API consumer.

Don’t get me wrong. I think this is an innovative idea. I just don’t think it is something that should be patented. It should be an open standard, with a wealth of open (and proprietary) tooling developed to enable it to be a reality. If you are patenting the thing we need to make the legal partnership details in API marketplace, and ideally on the open web across API implementations more streamlined, you are just slowing meaningful API adoption and integration–it isn’t something you are going to get rich doing.

Imagine if every technical, business and legal detail of the web was patented early on–it wouldn’t exist as it does today. We do need an automated way to assess the terms of service that govern API consumption. We need this now, but we need it to be an open standard that anyone can implement as part of any API marketplace or single API implementation. This is similar to what we are trying to accomplish with API Commons, trying to make the licensing portion of platform operations machine readable and digestible at integration, as well as at runtime.

I just wish the innovation and resources that went into this patent had gone into an open standard for helping define terms of services so that there could be any innovation when it comes to automating the assessment of API terms of service. It feels like this patent author is just counting on the fact that the API space will eventually mature and reach a point where automating the assessment of terms of service is possible, and then cash in on the fact that they hold a patent on this valuable aspect of the API economy.

Patent US 8997069: API Descriptions

There are so many API patents out there, I’m going to have to start posting one a day just to keep up. Lucky for you I begin to get really depressed by all the API patents I lose interest in reading them and begin to work harder looking for positive examples of API in the world, but until then here is today’s depressing as fuck API patent.

Title: API descriptions Number: US 8997069 Owner: Microsoft Technology Licensing, LLC Abstract: API description techniques are described for consumption by dynamically-typed languages. In one or more implementations, machine-readable data is parsed to locate descriptions of one or more application programming interfaces (APIs). The descriptions of the one or more application programming interfaces are projected into an alternate form that is different than a form of the machine-readable data.

I don’t mean to be a complete dick here, but why would you think this is a good idea? I get that companies want their employees to develop a patent portfolio, but this one is patenting an essential ingredient that makes APIs work. If you enforce this patent it will be worthless because this whole API thing won’t work, and if you don’t enforce it, it will be worthless because it does nothing–money well spent on the filing fee.

I just need to file my patent on patenting APIs and end all of this nonsense. I know y’all think I’m crazy for my beliefs that APIs shouldn’t be patented, but every time I dive into my patent research I can’t help but think y’all are the crazy ones, and I’m actually sane. I just do not understand how this patent is going to help anyone and represents any of the value that APIs and even a patent can bring to the table.

Patent US9462011: Determining trustworthiness of API requests

I’m always fascinated by the patents that get filed related to APIs. Most just have an API that is part of the equation, but some of the patents are directly for an API process. It’s no secret that I’m a patent skeptic. I’m not anti-patent, I just think the process is broken when it comes to the digital world, and specifically when it comes to APIs and interoperability. Here is one of those API patents that show just how broken things are:

Title: Determining trustworthiness of API requests based on source computer applications’ responses to attack messages Number: US9462011 Owner: CA, Inc.

Abstract: A method includes receiving an application programming interface (API) request from a source computer application that is directed to a destination computer application. An attack response message that is configured to trigger operation of a defined action by the source computer application is sent to the source computer application. Deliverability of the API request to the destination computer application is controlled based on whether the attack response message triggered operation of the defined action. Related operations by API request risk assessment systems are disclosed.

I get that you might want to patent some of the secret sauce behind this process, but when it comes to APIs, and API security I’m thinking we need to keep thinks open, reusable, and interoperable. Obviously, this is just my not so the business savvy view of the world, but from my tech savvy view of how we secure APIs, patented process help nobody.

When it comes to API security you gain an advantage by providing actual solutions and doing it better than anyone else. Then you do not need to defend anything, everyone will be standing in line to buy your services because securing your APIs is critical to doing business in 2017.

A Perception Of Patent And Copyright Overlapping When It Comes To APIs

I just read an interesting piece by Dennis Crouch over at on Patentlyo asking, “Are Copyright and Patent Overlapping or Mutually Exclusive in Protecting Software Innovations?” The article is challenging the most recent decision in the ongoing Oracle v Google copyright case using a study on “The Patent-Copyright Laws Overlap Study”, prepared at the behest of the House Subcommittee on Intellectual Property and the Administration of Justice in May of 1991.

Among the most significant of the Study’s software findings is that there is “no overlap in subject matter: copyright protects the authorship in a set of statements that bring about a certain result in the operation of a computer, and patents cover novel and nonobvious computer processes.” Letter from Ralph Oman and Harry F. Manbeck to the Hon. William J. Hughes, July 17, 1991 (transmitting the Study to the then Chair of the House Subcommittee).

I’m interested in this level of discussion because it helps me see the many layers of how patent and copyright law applies, or does not apply in the digital world, and specifically to APIs. Personally, I do not feel that copyright or patents apply to the API definition layer of API operations. Maybe patents can apply to the software processes behind, and maybe copyright could be applied to some more complex, creative software orchestrations using APIs, but really this layer acts like a menu to what is possible, something akin to a restaurant menu, which I have argued in the past.

At a time in the growth of the API industry where we should be standardizing, sharing, and ensuring our API definitions are interoperable, we are going backward and further locking up these definitions, and keeping them in our proprietary safe. Instead of locking them up we need to be having more conversation like this about further defining the licensing layers of API operations, separating the backend code, data, schema, API definitions, front-end, and rules that surround them. I can get behind keeping some of the code, processes, and rules behind API operations secret, but the interface itself needs to remain open–I mean, you are asking other people to integrate this layer into their applications.

I am still understanding the patent implications in the world of APIs, and it is helpful to have lawyers out there to help me better understand all the moving parts. As we prepare for the next round of the Oracle v Google API copyright case, it helps me to pull back and understand the overlap of copyright with patents using earlier legal precedents like in the Patent-Copyright Laws Overlap Study from 1991.

If you have a story you think I should telling about I recommend you write up the thought on your own blog and share a link with me, or feel free to submit a Github issue on this research project's repository, or use of the other channels available on the contact page.