Quality and Quantity of Specification Support in Determining Patent Eligibility
| March 19, 2021
Simio, LLC v Flexsim Software Products, Inc.
December 29, 2020
Prost, Clevenger, and Stoll
Summary:
In upholding a district court’s finding of patent ineligibility for a computer-based system for object-oriented simulation, the Federal Circuit uses a new “quality and quantity” assessment of the specification’s description of an asserted claim limitation that supposedly supports the claim being directed to an improvement in computer functionality (and not an abstract idea). Here, numerous portions of the specification emphasized an improvement for a user to build object-oriented models for simulation using graphics, without the need to do any programming. This supported the court’s finding that the character of the claim as a whole is directed to an abstract idea – of using graphics instead of programming to create object-oriented simulation models. In contrast to the numerous specification descriptions supporting the abstract idea focus of the patent, one claimed feature that Simio asserted as reflecting an improvement in computer functionality was merely described in just one instance in the specification. This “disparity in both quality and quantity” between the specification support of the abstract idea versus the specification support for the asserted claim feature does not change the claim as a whole as being directed to the abstract idea.
Procedural History:
Simio, LLC sued FlexSim Software Products, Inc. for infringing U.S. Patent No. 8,156,468 (the ‘468 patent). FlexSim moved for judgment on the pleadings under Rule 12(b)(6) for failing to state a claim upon which relief could be granted because the claims of the ‘468 patent are patent ineligible under 35 USC § 101. The district court granted that motion and dismissed the case. The Federal Circuit affirmed.
Background:
Representative claim 1 of the ‘417 patent follows:
A computer-based system for developing simulation models on a physical computing device, the system comprising:
one or more graphical processes;
one or more base objects created from the one or more graphical processes,
wherein a new object is created from a base object of the one or more base objects by a user by assigning the one or more graphical processes to the base object of the one or more base objects;
wherein the new object is implemented in a 3-tier structure comprising:
an object definition, wherein the object definition includes a behavior,
one or more object instances related to the object definition, and
one or more object realizations related to the one or more object instances;
wherein the behavior of the object definition is shared by the one or more object instances and the one or more object realizations; and
an executable process to add a new behavior directly to an object instance of the one or more object instances without changing the object definition and the added new behavior is executed only for that one instance of the object.
Computer-based simulations can be event-oriented, process-oriented, or object-oriented. Earlier object-oriented simulation platforms used programming-based tools that were “largely shunned by practitioners as too complex” according to the ‘468 patent. Use of graphics emerged in the 1980s and 1990s to simplify building simulations, via the advent of Microsoft Windows, better GUIs, and new graphically based tools. Along this graphics trend, the ‘468 patent focuses on making object-oriented simulation easier for users to build simulations using graphics, without any need to write programming code to create new objects.
Decision:
Under Alice step one’s “directed to” inquiry, the court asks “what the patent asserts to be the focus of the claimed advance over the prior art.” To answer this question, the court focuses on the claim language itself, read in light of the specification.
Here, the preamble relates the claim to “developing simulation models,” and the body of the claim recites “one or more graphical processes,” “one or more base objects created from the one or more graphical processes,” and “wherein a new object is created from a base object … by assigning the one or more graphical processes to the base object…” There is also the last limitation (the “executable-process limitation”). Although other limitations exist, Simio did not rely on them for its eligibility arguments.
The court considered these limitations in view of the specification. The ‘468 patent acknowledged that using graphical processes to simplify simulation building has been done since the 1980s and 1990s. And, the ‘468 patent specification states:
“Objects are built using the concepts of object-orientation. Unlike other object-oriented simulation systems, however, the process of building an object in the present invention is simple and completely graphical. There is no need to write programming code to create new objects.” ‘468 patent, column 8, lines 22-26 (8:22-26).
“Unlike existing object-oriented tools that require programming to implement new objects, Simio™ objects can be created with simple graphical process flows that require no programming.” 4:39-42.
“By making object building a much simpler task that can be done by non-programmers, this invention can bring an improved object-oriented modeling approach to a much broader cross-section of users.” 4:47-50.
“The present invention is designed to make it easy for beginning modelers to build their own intelligent objects … Unlike existing object-based tools, no programming is required to add new objects.” 6:50-53.
“In the present invention, a graphical modeling framework is used to support the construction of simulation models designed around basic object-oriented principles.” 8:60-62.
“In the present invention, this logic is defined graphically … In other tools, this logic is written in programming languages such as C++ or Java.” 9:67-10:3.
Taking the claim limitations, read in light of the specification, the court concludes that the key advance is simply using graphics instead of programming to create object-oriented simulations. “Simply applying the already-widespread practice of using graphics instead of programming to the environment of object-oriented simulations is no more than an abstract idea.” “And where, as here, ‘the abstract idea tracks the claim language and accurately captures what the patent asserts to be the focus of the claimed advance …, characterizing the claim as being directed to an abstract idea is appropriate.’”
Simio argued that claim 1 “improves on the functionality of prior simulation systems through the use of graphical or process modeling flowcharts with no programming code requited.” However, an improvement emphasizing “no programming code required” is an improvement for a user – not an improvement in computer functionality. An improvement in a user’s experience (not having to write programming code) while using a computer application does not transform the claims to be directed to an improvement in computer functionality.
Simio also argued that claim 1 improves a computer’s functionality “by employing a new way of customized simulation modeling with improved processing speed.” However, improved speed or efficiency here is not that of the computer, but rather that of the user’s ability to build or process simulation models faster using graphics instead of programming. In other words, the improved speed or efficiency is not that of computer functionality, but rather, a result of performing the abstract idea with well-known structure (a computer) by a user.
Simio finally argued that the last limitation, the executable-process limitation reflects an improvement to computer functionality. It is with regard to this last argument that the court introduces a new “quality and quantity” assessment of the specification. In particular, the court noted that “this limitation does not, by itself, change the claim’s ‘character as a whole’ from one directed to an abstract idea to one that’s not.” As support of this assessment of the claim’s “character as a whole,” the court cited to at least five instances of the specification emphasizing graphical simulation modeling making model building easier without any programming, in contrast to a single instance of the specification describing the executable process limitation:
Compare, e.g., ’468 patent col. 4 ll. 29–42 (noting that “the present invention makes model building dramatically easier,” as “Simio™ objects” can be created with graphics, requiring no programming), and id. at col. 4 ll. 47–50 (describing “this invention” as one that makes object-building simpler, in that it “can be done by non-programmers”), and id. at col. 6 ll. 50–53 (describing “[t]he present invention” as one requiring no programming to build objects), and id. at col. 8 ll. 23–26 (“Unlike other object-oriented simulation systems, however, the process of building an object in the present invention is simple and completely graphical. There is no need to write programming code to create new objects.”), and id. at col. 8 ll. 60–62 (“In the present invention, a graphical modeling frame-work is used to support the construction of simulation models designed around basic object-oriented principles.”), with col. 15 l. 45–col. 16 l. 6 (describing the executable-process limitation). This disparity—in both quality and quantity—between how the specification treats the abstract idea and how it treats the executable-process limitation suggests that the former remains the claim’s focus.
Even Simio’s own characterization of the executable-process limitation closely aligns with the abstract idea: (a) that the limitation reflects that “a new behavior can be added to one instance of a simulated object without the need for programming” and (b) that the limitation reflects an “executable process that applies the graphical process to the object (i.e., by applying only to the object instance not to the object definition).” Although this is more specific than the general abstract idea of applying graphics to object-oriented simulation, this merely repeats the above-noted focus of the patent on applying graphical processes to objects and without the need for programming. As such, this executable-process limitation does not shift the claim’s focus away from the abstract idea.
At Alice step two, Simio argued that the executable-process limitation provides an inventive concept. However, during oral arguments, Simio conceded that the functionality reflected in the executable-process limitation was conventional or known in object-oriented programming. In particular, implementing the executable process’s functionality through programming was conventional or known. Doing so through graphics does not confer an inventive concept. What Simio relies on is just the abstract idea itself – use of graphics in object-oriented simulation. Reliance on the abstract idea itself cannot supply the inventive concept that renders the invention “significantly more” than that abstract idea.
Even if the use of graphics instead of programming to create object-oriented simulations is new, a claim directed to a new abstract idea is still an abstract idea – lacking any meaningful application of the abstract idea sufficient to constitute an inventive concept to save the claim’s eligibility.
Takeaways:
- This case serves a good reminder of the importance of proper specification drafting to address 101 issues such as these. An “improvement” that can be deemed an abstract idea (e.g., use graphics instead of programming) will not help with patent eligibility. The focus of an “improvement” to support patent eligibility must be technological (e.g., in order to use graphics instead of programming in object-oriented simulation modeling, this new xyz procedure/data structure/component replaces the programming interface previously required…). “Technological” is not to be confused with being “technical” – which could mean just disclosing more details, albeit abstract idea type of details that will not help with patent eligibility. Here, even a “new” abstract idea does not diminish the claim still being “directed to” that abstract idea, nor rise to the level of an inventive concept. Improving user experience is not technological. Improving a user’s speed and efficiency is not technological. Improving computer functionality by increasing its processing speed and efficiency could be sufficiently technological IF the specification explains HOW. Along the lines of Enfish, perhaps new data structures to handle a new interface between graphical input and object definitions may be a technological improvement, again, IF the specification explains HOW (and if that “HOW” is claimed). In my lectures, a Problem-Solution-Link methodology for specification drafting helps to survive patent eligibility. Please contact me if you have specification drafting questions.
- This case also serves as a good reminder to avoid absolute statements such as “the present invention is …” or “the invention is… .” There is caselaw using such statements to limit claim interpretation. Here, it was used to ascertain the focus of the claims for the “directed to” inquiry of Alice step one. The more preferrable approach is the use of more general statements, such as “at least one benefit/advantage/improvement of the new xyz feature is to replace the previous programming interface with a graphical interface to streamline user input into object definitions…”
- This decision’s “quality and quantity” assessment of the specification’s focus on the executable-process limitation provides a new lesson. Whatever is the claim limitation intended to “reflect” an improvement in technology, there should be sufficient specification support for that claim limitation – in quality and quantity – for achieving that technological improvement. Stated differently, the key features of the invention must not only be recited in the claim, but also, be described in the specification to achieve the technological improvement, with an explanation as to why and how.
- This is yet another unfortunate case putting the Federal Circuit’s imprimatur on the flawed standard to find the “the focus of the claimed advance over the prior art” in Alice step one, albeit not as unfortunate as Chamberlain v Techtronic (certiorari denied) or American Axle v Neapco (still pending certiorari). In another lecture, I explain why the “claimed advance” standard is problematic and why it contravenes Supreme Court precedent. Briefly, the claimed advance standard is like the “gist” or “heart” of the invention standard of old that was nixed. In Aro Mfg. Co. v. Convertible Top Replacement Co., the Supreme Court stated that “there is no legally recognizable or protected ‘essential’ element, ‘gist’ or ‘heart’ of the invention in a combination patent.” In §§102 and 103 issues, the Federal Circuit said distilling an invention down to its “gist” or “thrust” disregards the claim “as a whole” requirement. Likewise, stripping the claim of all its known features down to its “claimed advance over the prior art” is also contradictory to the same requirement to consider the claim as a whole under section 101. Moreover, the claimed advance standard contravenes the Supreme Court’s warnings in Diamond v Diehr that “[i]t is inappropriate to dissect the claims into old and new elements and then to ignore the presence of the old elements in the analysis. … [and] [t]he ‘novelty’ of any element or steps in a process, or even of the process itself, is of no relevance in determining whether the subject matter of a claim falls within the 101 categories of possibly patentable subject matter.” Furthermore, the origins of the claimed advance standard have not been vetted. Originally, the focus was on finding a practical application of an abstract idea in the claim. This search for a practical application morphed, without proper legal support, into today’s claimed advance focus in Alice step one. Interestingly enough, since the 2019 PEG, the USPTO has not substantively revised its subject matter eligibility guidelines to incorporate any of the recent “claimed advance” Federal Circuit decisions.
Tags: 35 U.S.C. § 101 > abstract idea > patent eligibility > specification drafting
