For nearly a decade now, Google and Oracle have been litigating (filed Aug. 13, 2010) over the applicability of copyright to application programming interfaces (API). Over that time period, APIs have only become more widespread and essential to the content delivery network of the internet. Intellectual property attorneys are currently awaiting the Supreme Court decision on Google v. Oracle, as it will be one of the most significant software IP decisions of the internet age. In the patent world, however, the Federal Circuit has decided three cases in the past two years that turned on the interpretation of APIs and relevant prior art. These appeals are from USPTO PTAB decisions on IPRs from the time period when the claim construction standard before the Board was broadest reasonable interpretation (BRI). Therefore, the Federal Circuit’s reasoning is also applicable to Ex Parte appeals before the Board that use the same standard.
An API is a rather amorphous term that adds little clarity to the word “interface” which it purportedly describes. The Merriam-Webster dictionary defines API as “a set of rules that allows programmers to develop software for a particular operating system without having to be completely familiar with that operating system.” In other words, an API is one level of abstraction away from an operating system — and a rather minimalist abstraction at that. Thus, for embedded operating systems, the nature of the interface is essentially firmware; while for a database system the API may be a set of interpreted script functions. Likewise, the common usage of the word by IT professionals has further expanded the meaning of the term beyond operating system abstractions to all interface abstractions for any database, protocol, or virtual system. Therefore, the popular usage of the term has tended toward meaning simply “software interface”.
Furthermore, another issue that the Federal Circuit wrestles within these cases is the specificity of the term API in light of the specification. Because API can simply mean interface, a broad reading of the term can bring in volumes of prior art. On the other hand, every API is understood to be constrained by the systems it connects and relevant only to certain operating systems or other software structures. Therefore, during claim construction of an API that relates only to certain software packages as described in the specification, it may be unreasonable to broadly construe that term to simply mean “interface” in light of the specification.
The first case is IXI IP, LLC v. Samsung Electronics Co., Ltd. (Fed. Cir. Sept. 10, 2018), which relates to an appeal from an inter partes review (IPR) of US Patent 7,039,033. The Final Written Decision of that IPR concluded that “[t]he present invention establishes three new interfaces or Application Programming Interfaces (APIs) between the slave device placing the call and the master mobile phone…. This interface enables any of the Bluetooth devices on the Piconet to behave as a slave device toward the mobile phone which is the master.” The Federal Circuit affirmed the Board’s Final Written Decision
While representative claim 1 in this case does not recite an API, it does recite “a software component to access information” and a “service repository software component [that] identif[ies] a service provided by the second wireless device”, which the Board and the Federal Circuit each interpreted as an API for application of the prior art. In particular, the primary reference’s JINI Look-Up-Service API was mapped to the second limitation. Another point of contention in this case was the hosted location of the API, which may be a common point of contention for APIs. Though one figure showed a laptop hosting the API, the disclosure stated that the cellphone delivered the API objects setting up the interface. Just as primary/secondary devices may be interchangeable on a network, the hosting device of an API or controller of the gateway may also be interchangeable. Therefore, for specification drafting it is important to include all possibilities, and for claims, the broadest interpretations are obtained by not tying an API to any of the specific devices in the claim (to prevent design around by hosting the API on the other end of the paired system).
The second case is Twilio Inc. v. Telesign Corp. (Fed. Cir. June 10, 2020), which relates to an appeal from an inter partes review of US Patent 8,755,376 and US Patent 8,837,465. The representative claim 1 of the ‘376 patent uses the term API seven times and the remaining limitations describe how the APIs communicate. Twilio, the patent owner, alleged that the Board misconstrued the final portion of the claim, specifically “API resource” and the “responding” step:
exposing the plurality of API resources through a representational state transfer (REST) API that comprises:
receiving a REST API request that specifies an API resource URI, and responding to the API request according to the request and the specified resource URI.
The Board construed an API resource as a resource available through an API. Twilio, however, argued for a narrower construction that was limited to how the API resource was used in the primary step of the claim: “operating a telephony network and internet connected system cooperatively with a plurality of application programming Interface (API) resources”, of which the abovequoted step was a sub-step. The Board and the Federal Circuit, however, found that the structure of the claim was not enough to limit the API to a definition narrower than the broadest reasonable interpretation for an API. Thus, the one-to-one interface of the prior art could teach the one-to-many API of claim 1 of the ‘376 patent because the API was not expressly limited in the claim to the system being operated.
Likewise, claim 1 of the ‘465 patent was found obvious over the same prior art despite not using the term API at all. Instead, claim 1 of the ‘465 patent framed the system connections as “an application layer protocol request to an application resource specified by the URI” and a subsequent response. The arguments for these claims by Twilio were even weaker since all that was claimed was essentially initiating a connection, mapping the connection, exchanging request/response, and following the response instructions without any specific hierarchy. In both patents, the Federal Circuit construed the API broadly despite other context in the claim itself suggesting that an API is not a specific interface or connection unless explicitly stated to be so.
Practitioners should note that in order to limit the interpretation of “API” to connection-types recited previously in the claim, the language of the claim must tie the API to the systems being interfaced directly (e.g. operating X via an API resource) and refer all subsequent API resources to that API resource (e.g. the API resource). In other words, te Federal Circuit suggests that the API of claim 1 of the ‘376 patent could have been construed as limited to the system’s API resource of the operating step if the claim drafter had properly used antecedent basis to tie the different API resource elements together.
The third case is Fitbit, Inc. v. Valencell, Inc. (Fed. Cir. July 8, 2020), which deals with the patentability of certain dependent claims of an IPR of US Patent 8,923,941. This decision, unlike the previous two, is precedential. The main issues in this case were related to joinder of parties before PTAB and the PTAB’s discretion in correcting obvious clerical errors in the patent that are conceded by both sides. To address the discretion question, however, the court needed to spend several pages on the claim construction of an API as used in claim 3 of the patent (found NOT unpatentable). The Board and Federal Circuit construed “application-specific interface (API)” to mean “an interface which enables a particular application to utilize data obtained from hardware, such as the at least one motion sensor and the at least one PPG [photoplethysmography] sensor.” This construction is far narrower than in the prior case of Twilio v. Telesign. Fitbit argued for an interpretation closer to that of Twilio, stating: “application-specific interface (API) . . . include[s] at least an application interface that specifies how some software components should interact with each other.” The contextual wording of claim 3 of the ‘941 patent does not seem to explicitly require this narrow interpretation:
The method of claim 1, wherein the serial data output is parsed out such that an application-specific interface (API) can utilize the physiological information and motion-related information for an application.
The Board and the Federal Circuit, however, interpreted the broadest reasonable interpretation of the application specific interface to be narrower than application programming interface, reasoning that an “‘application-specific interface (API)’ is directed to a ‘particular application,’ rather than broadly to different applications.” This precedential construction of the term “application specific interface” as the specific use or application of the disclosed connection or interface may allow for more direct and minimalist claiming of the system specific API. The trade off is that the construction of the term may also be narrow later when infringement is being alleged. Indeed, the Board seems to have interpreted the API feature of claim 3 much like a means-plus-function feature by bringing in the entire system being connected as a part of the “application specific” interpretation. Claim construction in litigation would not further broaden this interpretation but may even further narrow it under the Phillips standard. Thus, practitioners that continue to use “application specific interface” intending the broader sense in which some IT professional use it may be surprised that their claim is construed much more narrowly in litigation.
Practitioners need to choose between (1) explicitly specifying the application programming interface and its necessary system elements and (2) specifying interface as “application specific” and leaving the interpretation of required systems to the courts. The simple “application specific interface” phrasing of the latter choice may be useful for cleaner claims where a narrow scope is not an issue. For example in dependent claims, where narrower scope is advantageous, the interpretation of “application specific interface” as limited to the specific use of the interface may not be an issue. In most other cases, the practitioner will want to recite an “application programming interface” or a “software interface” for a broad, predictable scope that can be explicitly narrowed by adding surrounding structure to the interface. This prevents the overly narrow construction that resulted from the recitation of “application specific interface” in Fitbit and provides a construction closer to that in Twilio.