Synopsys, Inc. v. Mentor Graphics Corporation

839 F.3d 1138, 120 U.S.P.Q. 2d (BNA) 1473, 2016 U.S. App. LEXIS 18561, 2016 WL 6068920
Court of Appeals for the Federal Circuit·Decided October 17, 2016·No. 2015-1599·Published·Cited by 162 cases

Opinion

CHEN, Circuit Judge.

Synopsys, Inc. appeals the District Court for the Northern District of California’s grant of summary judgment invalidating certain claims of U.S. Patent Nos. 5,530,841; 5,680,318; and 5,748,488 (collectively, the Gregory Patents) under 35 U.S.C. § 101. See Synopsys, Inc. v. Mentor Graphics Corp., 78 F.Supp.3d 958 (N.D. Cal. 2015) (Summary Judgment Order). Synopsys argues that, contrary to the district court’s holding, the Gregory Patents are not directed to ineligible subject matter because they relate to complex algorithms used in computer-based synthesis of logic circuits. We disagree. A review of the actual claims at issue shows that they are directed to the abstract idea of translating a functional description of a logic circuit into a hardware component description of the logic circuit. 1 This idea of reviewing a description of certain functions and turning it into a representation of the logic component that performs those functions can be—and, indeed, was—performed mentally or by pencil and paper by one of ordinary skill in the art. Moreover, the claims do not call for the involvement of a computer. They therefore cannot be characterized as an improvement in a computer as a tool. The claims add nothing to the abstract idea that rises to the level of an “inventive concept” as required by precedent. We therefore affirm the district court’s grant of summary judgment of invalidity.

BACKGROUND

I. The Gregory Patents

The Gregory Patents are continuations of since-abandoned U.S. Patent Application No. 07/632,439 and all share a common specification. 2 The patents relate generally to the logic circuit design process. The logic circuit design process has evolved significantly over time. Synopsys describes the inventions of the Gregory Patents as critical steps in this evolution.

In the early days of logic circuits, 3 a designer was required to specify his design *1140 in great detail. He would do so in the form of a schematic diagram that identified individual hardware components and the interconnections between them or via a set of Boolean logic equations that specified the precise functionality of the design. '841 patent, 1:41-44. A fabrication facility would then build the corresponding physical circuit based on the architecture presented in the detailed design.

Over time, logic circuits became more and more complex. As complexity increased, many designers began to focus on the higher-level functionality of their designs and became less concerned with the detailed schematics or Boolean logic equations necessary to implement that functionality. Id. at 1:47-49. These developments created a need for a form of computer code that a designer could use to describe a logic circuit at a functional level. This led to the advent of various functional computer languages known as hardware description languages (HDLs). Id. at 1:50-55. HDLs allowed designers to “describe only the desired operation of the logic circuit, i.e., the signals generated by the logic circuit,” rather than having to specify the actual individual components and interconnections of the logic circuit. Id. at 1:62-64; see also id. at 1:50-55 (describing HDLs as operating “at least one level of abstraction removed from a schematic diagram or a set of [B]oolean logic equations”).

The introduction of HDLs necessitated the development of computerized design tools that could translate the functional description of the logic circuit into a detailed design for fabrication. Id. at 1:64-67. Early computerized design tools, however, could only recognize, and translate simple circuit elements. Id. at 2:1-3. “For many circuit elements, such as high impedance drivers, level sensitive latches and edge sensitive flip-flops, the designer was required first to specify [ (i.e., instantiate) ] the specific circuit element and then the desired connection of that element using the HDL.” Id. at 2:3-7.

The Gregory Patents describe constructs known as “control flow graphs,” id. at 2:65-3:8, and “assignment conditions,” id. at 3:22-30, that provide a scheme to translate HDL-based functional descriptions of logic circuits into hardware component descriptions of those same circuits without requiring the designer to instantiate any individual hardware components— not even high impedance drivers, level sensitive latches, or edge sensitive flip-flops. Id. at 2:27-36. The patent specification goes through several examples for different components to illustrate how control flow graphs and assignment conditions are used to translate a functional description of a logic circuit to a hardware component description of that logic circuit.

We will explore in detail one such example, which is claimed in claim 1 of the '841 patent. 4 But, first, one must understand the general concept of binary logic as well as the constructs introduced in the Gregory Patents—namely flow control statements, directive statements, asynchronous load functions, and asynchronous data functions—what they are and how they work. We can gain this understanding through a review of the following simple example of HDL code:

IflCOND)

Q: = l;

else

Q: = o>

endif

*1141 Here, “Q” is the output of the segment of code and “COND” is a condition. The value of output Q is dictated by the line of code “If(COND),” which the specification labels as a “flow control statement.” See '841 patent, 11:20-23. This line . of code asks the question “Is condition COND true?”—i.e., does it equal l? 5 As the moniker “flow control statement” suggests, the answer to this question controls the flow of how the rest of the code runs. Id. at 11:18-20. In the above example, when condition COND is true (i.e., has the value “1”), the code flows to the immediately-following line of code, i.e., “Q: = 1.”- The specification labels this line of code as a “directive statement” for it directs that output Q be assigned the value 1. Id. at 11:1-8. In contrast, when condition COND is false (i.e., has the value “0”), the code skips the directive statement “Q: .= 1” and, flows directly to the line of code “else.” Here, we find another directive statement: “Q: = 0.” Pursuant to this directive statement, Q is assigned the value 0. The relationship between condition COND and output Q can be summarized in the following table:

[[Image here]]

Free access — add to your briefcase to read the full text and ask questions with AI

Synopsys, Inc. v. Mentor Graphics Corporation, 839 F.3d 1138, 120 U.S.P.Q. 2d (BNA) 1473, 2016 U.S. App. LEXIS 18561, 2016 WL 6068920 (Fed. Cir. 2016).

839 F.3d 1138 (Synopsys, Inc. v. Mentor Graphics Corporation) — published by Counsel Stack Legal Research, free access to 12M+ legal documents.

Related