Tuesday, May 17, 2016

Enfish Mayo Step One Inquiry Fails to Save Claims Directed to Assigning Classification Data to Digital Images From Being Deemed an Abstract Idea

Takeaway: The Federal Circuit utilized the updated Mayo analysis set forth in the recent Enfish v. Microsoft decision to affirm a lower court’s ruling that the claims at issue were directed to patent-ineligible subject matter. In part, the Federal Circuit found the claimed subject matter was directed to the abstract idea of assigning “classification data” to digital images and that the claims merely recited generic components that did not provide an “inventive concept” that would transform the otherwise patent-ineligible abstract idea into a patent-eligible application of the concept. (TLI Communications LLC, v. AV Automotive, L.L.C., 2015-1372, -1376, -1377, -1378, -1379, -1382, -1383, -1384, -1385, -1417, -1419, -1421, May 17, 2016)

TLI Communications LLC, v. AV Automotive, L.L.C.
2015-1372, -1376, -1377, -1378, -1379, -1382, -1383, -1384, -1385, -1417, -1419, -1421
Decided: May 17, 2016

In a recent precedential decision, the Federal Circuit invalidated claims reciting an invention that assigns “classification data,” such as a date or a timestamp, to digital images as being directed to an abstract idea under 35 U.S.C. § 101 even in light of the updated Mayo step one inquiry as set forth in Enfish, LLC v. Microsoft Corp., No. 2015-2044 (Fed. Cir. May 12, 2016). More specifically, the decision in Enfish clarified that the relevant inquiry at Mayo step one was “to ask whether the claims are directed to an improvement to computer functionality versus being directed an abstract idea. See Enfish slip op. at *11.

Claim 17, which is representative of the subject matter, recited:

A method for recording and administering digital images, comprising the steps of:

recording images using a digital pick up unit in a telephone unit,

storing the images recorded by the digital pick up unit in a digital form as digital images,

transmitting data including at least the digital images and classification information to a server, wherein said classification information is prescribable by a user of the telephone unit for allocation to the digital images,

receiving the data by the server,

extracting classification information which characterizes the digital images from the received data, and

storing the digital images in the server, said step of storing taking into consideration the classification information.

At Mayo step one (i.e., determining whether the claims at issue are directed to a patent-ineligible concept), the Federal Circuit found that the subject matter of claim 17 was drawn to the concept of classifying an image and storing the image based on its classification. The Federal Circuit noted that the claim required “concrete, tangible components such as 'a telephone unit' and a 'server.'“ However, the Federal Circuit went on to state that the “specification makes clear that the recited physical components merely provide a generic environment in which to carry out the abstract idea of classifying and storing digital images in an organized manner” and that the specification's emphasis that the “present invention 'relates to a method for recording, communicating and administering [a] digital image' underscores that claim 17 is directed to an abstract concept.”

As mentioned above, the Federal Circuit utilized the recent clarification to Mayo step one set forth in Enfish to examine whether the claimed subject matter was directed to an improvement in computer functionality or whether the claimed subject matter was directed to an abstract idea. In supporting its conclusion that the claims were directed to an abstract idea, the Federal Circuit found that the claims were not directed to a specific improvement to computer functionality. Instead, the Federal Circuit found that the claims were directed to usage of conventional or generic technology in a well-known environment.

Of note, the Federal Circuit focused its discussion on the appellant's specification. For instance, the Federal Circuit states that the “specification does not describe a new telephone, a new server, or a new physical combination of the two” and that the “specification fails to provide any technical details for the tangible components, but instead predominantly describes the system and methods in purely functional terms.” The decision points to the description of the “telephone unit” in the specification as having “the standard features of a telephone unit” and that “cellular telephones may be utilized for image transmission.” Additionally, the decision points to the description of the server as being described “simply in terms of performing generic functions such as storing, receiving, and extracting data.”

In concluding its Mayo step one analysis, the Federal Circuit likened the claims at issue to the claims at issue in Content Extraction v. Wells Fargo Bank, which were directed to “collecting data,” “recognizing certain data within the collected data set,” and “storing the recognized data in memory.”

In its Mayo step two analysis (i.e., whether the claims at issue include an “inventive concept”), the Federal Circuit found that the claims failed to recite any “elements that individually or as an ordered combination transform the abstract idea of classifying and storing digital images in an organized manner into a patent-eligible application of that idea.” Similar to its analysis set forth above with respect to Mayo step one, the Federal Circuit found that the claims at issue merely recited generic computer components “insufficient to add an inventive concept to an otherwise abstract idea” and that ”the recited physical components behave exactly as expected according to their ordinary use.”

As such, the Federal Circuit affirmed the lower court's decision that the claims at issue were directed to an abstract idea and, thus, invalid under 35 U.S.C. § 101.

My two cents: Again, this decision provides a lesson that the any specification should include as much technical detail as possible. For example, this Federal Circuit decision focused on the inadequacies of the specification (e.g., the specification described the system in purely functional terms, only describing the components in terms of performing generic functionality, etc.). Additionally, the Enfish decision notes that the specification in that case explained that the prior art database structures were inferior to the claimed invention. Thus, Applicants may consider including explanations of  why Applicant’s technology is superior to the prior art in the specification. 


  1. MaxDrei here. Karen, you write:

    "...this decision provides a lesson that the any specification should include as much technical detail as possible".

    So what's new for drafters? When (if ever) was this not the rule? And are all "details" the same or are some "details" more equal than others? My old boss, 30 years ago, used to bill in proportion to the number of pages in the drafted work product. When do "details" fall to the level of mere padding?

    Do you see any merit in the European position, that in the claims you define the invention as a combination of technical features whereas, in the specification, you describe what the invention does, in terms of what technical effects the claimed feature combination delivers. So, when visualising "detail", do you draw any Euro-style vital distinction between what are features and what are effects?

    In short, what sort of "detail" do you have in mind?

  2. Thank you for the question, MaxDrei.

    Regarding inclusion of technical details - we are starting to see quite a few decisions where the courts, PTAB, and/or examiners are focusing on mere generic functional descriptions of the components described within the specification when making these types of rejections.

    Thus, for these types of cases, one should include descriptions of how the invention improves the performance of the computer, include as many flow diagrams as possible, discuss the allocation of data within a memory structure (if possible), etc.

    Additionally, avoid using language that describes the components as "conventional" or "standard," which invites these types of rejections since it provides a road map to the argument that the components are "well-understood, conventional, and routine" that are merely performing generic functionality.

    Finally, it appears that some courts latch onto disparagement of the prior art; however, this may invite unintended consequences down the road.

  3. Thanks for that, Tyler Benson. Being from Europe, I (MaxDrei) am keen to know what is the ambit of "improving the performance of a computer". You mention improvements in allocating data within a memory structure, and I'm wondering whether that would be accepted as something that improves the computer.

    Notwithstanding any equivalence between hardware and software, it seems to me that there is a difference between improving a computer and improving a app running on the computer (by re-writing some code to eliminate a bug, for example).

    You can improve the performance of a diesel engine by using better diesel fuel. It seems to me you haven't made a better engine, just a better fuel. Now who cares whether it is the fuel or the engine because both are patentable. At least in Europe though, there might be a difference in patentability. depending whether you have improved the computer or merely de-bugged a piece of app software.

    I guess this is all still territory as yet unexplored in the courts.

    1. Unexplored or a different legal system which sees issues through another looking glass? I believe there's case law to help analyse your proffered hypo, but the US, of course, uses different terms and tools. I'd even say its more unpredictable from application to enforcement, especially now in the software arts.

  4. This comment has been removed by the author.

  5. I guess the "technical detail and context" issues are why 101 rejections, in my experience, rarely come up in the signal-processing arts (or at least comparably rare vis-a-vis other technical arts).

    Applications in this field tend to have at least a few equations showing what's going on beyond high-level schematic figures and are tied to very particular technical contexts (e.g., voice, video, image, and audio coding and associated hardware).