Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 38
`Entered: August 6, 2014
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SAS INSTITUTE, INC.,
`Petitioner,
`
`v.
`
`COMPLEMENTSOFT, LLC,
`Patent Owner.
`
`Case IPR2013-00226
`Patent 7,110,936 B2
`
`
`
`
`
`
`
`
`
`Before KEVIN F. TURNER, JUSTIN T. ARBES, and JENNIFER S. BISK,
`Administrative Patent Judges.
`
`BISK, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`Tel: 571-272-7822
`
`Paper 38
`Entered: August 6, 2014
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SAS INSTITUTE, INC.,
`Petitioner,
`
`v.
`
`COMPLEMENTSOFT, LLC,
`Patent Owner.
`
`Case IPR2013-00226
`Patent 7,110,936 B2
`
`
`
`
`
`
`
`
`
`Before KEVIN F. TURNER, JUSTIN T. ARBES, and JENNIFER S. BISK,
`Administrative Patent Judges.
`
`BISK, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`I. INTRODUCTION
`
`A. Background
`
`Petitioner, SAS Institute, Inc., filed a Petition (Paper 1, “Pet.”) to
`
`institute an inter partes review of claims 1-16 (“the challenged claims”) of
`
`U.S. Patent 7,110,936 B2 (Exhibit 1001, “the ’936 patent”). 35 U.S.C.
`
`§§ 311-319. Patent Owner, ComplementSoft, LLC, filed a Preliminary
`
`Response. Paper 8. On August 12, 2013, we instituted trial (Paper 9,
`
`“Dec.”), concluding that Petitioner had shown a reasonable likelihood of
`
`showing that claims 1 and 3-10 were unpatentable based on the following
`
`grounds:
`
`References 1
`
`Claims Challenged
`
`Coad, Oracle Primer, and Oracle8 Primer
`
`1
`
`Antis and Coad
`
`1, 3, 5, 6, 8, and 10
`
`Antis, Coad, and Burkwald
`
`Antis, Coad, and Eick
`
`Antis, Coad, and Building Applications
`
`4
`
`7
`
`9
`
`We have jurisdiction under 35 U.S.C. § 6(c). This final written
`
`decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`
`
`1 U.S. Patent No. 5,572,650 (Ex. 1005) (“Antis”); U.S. Patent No. 6,851,107
`(Ex. 1006) (“Coad”); U.S. Patent No. 6,356,285 (Ex. 1007) (“Burkwald”);
`U.S. Patent No. 5,937,064 (Ex. 1008) (“Eick”); Microsoft Corporation,
`BUILDING APPLICATIONS WITH MICROSOFT ACCESS 97 (1996) (Ex. 1011)
`(“Building Applications”); Rajshekhar Sunderraman, ORACLE
`PROGRAMMING: A PRIMER (1999) (Ex. 1012) (“Oracle Primer”); and
`Rajshekhar Sunderraman, ORACLE8 PROGRAMMING: A PRIMER (2000) (Ex.
`1013) (“Oracle8 Primer”).
`
`2
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`Petitioner has shown, by a preponderance of evidence, that claims 1,
`
`3, and 5-10 are unpatentable. Petitioner has not met its burden to show that
`
`claim 4 is unpatentable.
`
`Patent Owner’s motion to amend claims is denied.
`
`B. Related Proceedings
`
`Patent Owner asserted the ’936 patent against Petitioner in
`
`ComplementSoft, LLC v. SAS Institute, Inc., No. 1:12-cv-07372 (N.D. Ill.
`
`Sept. 14, 2012). See Pet. 58; Paper 6 at 2. The related case is currently
`
`stayed pending this inter partes review. Transcript of Proceedings,
`
`ComplementSoft, No. 1:12-cv-07372, ECF No. 44 (granting stay), 54
`
`(denying motion to lift stay).
`
`C. The ’936 Patent
`
`The ’936 patent describes a language independent software
`
`development tool having a graphical user interface, also referred to as an
`
`Integrated Development Environment or IDE. Ex. 1001, 1:15-19. In
`
`particular, the patent describes an IDE for exchanging, editing, debugging,
`
`visualizing, and developing software code for “data manipulation centric
`
`languages.” Id. at 1:64-2:3.
`
`The Summary of the Invention describes the IDE as including, among
`
`other features, a visualizer that generates a graphical representation of the
`
`program flow, data flow, or logic of the code. Id. at 2:34-49. In other
`
`words, the visualizer allows for displaying code in ways other than a typical
`
`text editor. A detailed description of a preferred embodiment uses a series
`
`of drawings, and corresponding text, to describe an exemplary IDE with a
`
`visualizer that can display source code using several different graphical
`
`formats. Id. at 3:24-26. For instance, Figure 9, reproduced below, depicts
`
`3
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`“a program flow for a selected file, along with arrows that indicate the flow
`
`of data within the program flow.” Id. at 3:49-51.
`
`
`
`Figure 9, above, shows visualizer 120 displaying source code. Id. Each
`
`program and data block of a code section is represented by an icon, program
`
`flow icon 126. Id. at 8:8-14. Program flow icons 126 are displayed in the
`
`order that they occur in the source code (id. at 15:56-59) and are connected
`
`by arrows that illustrate the flow of data (id. at 8:8-14).
`
`Visualizer 120 also is shown in Figure 17, reproduced below, showing
`
`“a data flow” for the selected program. Id. at 4:12-13.
`
`4
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`Figure 17, above, shows visualizer 120 displaying individual processes and
`
`data blocks, represented by program flow icons 126, in separate columns.
`
`Id. at 16:6-12. The arrows that connect program flow icons 126 indicate the
`
`
`
`direction of the data flow. Id.
`
`D. Illustrative Claim
`
`Claim 1, reproduced below, is the ’936 patent’s only independent claim:
`
`1. An integrated development environment, comprising:
`
`a document manager for retrieving source code
`programmed using one of a plurality of types of data
`manipulation languages;
`
`an editor for displaying the retrieved source code and
`providing a means for a user to edit the retrieved source code;
`
`5
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`a parser layer which detects the one of the plurality of
`types of data manipulation languages in which the retrieved
`source code is programmed and which activates rules and logic
`applicable to the detected one of the plurality of types of data
`manipulation languages; and
`
`a visualizer dynamically linked to the editor for
`displaying graphical representations of flows within the
`retrieved source code using the rules and logic applicable to the
`detected one of the plurality of types of data manipulation
`languages and activated by the parser,
`
`wherein the editor, parser layer and visualizer cooperate
`such that edits made to the source code using the editor are
`automatically reflected in the graphical representations of flows
`displayed by the visualizer and edits made to the graphical
`representations of flows in the visualizer are automatically
`reflected in the source code displayed by the editor.
`
`II. ANALYSIS
`
`A. Claim Construction
`
`For purposes of the Decision to Institute we expressly construed the
`
`terms “data manipulation language” and “graphical representation of flows.”
`
`Dec. 6-9. We construed (1) “data manipulation language” as “a
`
`programming language used to access data in a database, such as to retrieve,
`
`insert, delete, or modify data in the database,” and (2) “graphical
`
`representation of flows” as “a diagram that depicts a map of the progression
`
`(or path) through the source code.” Id.
`
`In the post-institution briefs, the parties directly disagree regarding
`
`only the construction of the term “data manipulation language.” Paper 16
`
`(“PO Resp.”) 10-11; Paper 24 (“Reply”) 1-2. In analyzing the issues in this
`
`case, however, we have determined that many of the arguments purportedly
`
`directed to the proposed obviousness grounds are more accurately arguments
`
`regarding claim construction. Thus, to properly resolve the issues presented
`
`6
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`in this proceeding, we construe several terms not addressed explicitly by
`
`either party, including “graphical representation of flows,” “program flows,”
`
`and “data flows.” We construe all terms, whether or not expressly described
`
`below, using the broadest reasonable construction in light of the ’936 patent
`
`specification. 37 C.F.R. § 42.100(b).
`
`1. Data Manipulation Language
`
`Much of this proceeding turns on the interpretation of the term “data
`
`manipulation language,” recited by every challenged claim. In the Decision
`
`to Institute, we interpreted this term as “a programming language used to
`
`access data in a database, such as to retrieve, insert, delete, or modify data in
`
`the database.” Dec. 6-8. This interpretation is consistent with dictionary
`
`definitions from the time period of the invention. See MICROSOFT
`
`COMPUTER DICTIONARY at 125 (4th ed. 1999) (“a language that is used to
`
`insert data in, update, and query a database”); Ex. 1040, 272 (THE
`
`AUTHORITATIVE DICTIONARY OF IEEE STANDARDS TERMS (7th ed. 2000))
`
`(“A language used to retrieve, insert, delete, or modify the data in a
`
`database.”).
`
`a. “retrieve”
`
`In its response brief, Patent Owner contends that the definition we
`
`adopted in the Decision to Institute is too broad. PO Resp. 10-11.
`
`Specifically, Patent Owner argues that a programming language that
`
`includes only the functionality for retrieving data would not have been
`
`considered a data manipulation language by a person of ordinary skill in the
`
`art. Id. Patent Owner’s declarant, Ivan Zatkovich, testifies that an SQL
`
`[Structured Query Language] SELECT statement—which retrieves data
`
`from a database—“does not alter the data in any way and thus does not, by
`
`7
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`itself, perform any manipulation of data.” Ex. 2001 ¶ 19. Accordingly,
`
`Patent Owner proposes that our interpretation of the term “data manipulation
`
`language” be altered to either remove the word “retrieve” or “qualify the use
`
`of the term retrieve by stating that the retrieval must be followed by some
`
`manipulation procedure.” PO Resp. 11. Petitioner disagrees, asserting that
`
`Patent Owner’s proposed change would result in too narrow an
`
`interpretation because retrieval of data does constitute data manipulation.
`
`Reply 1-2.
`
`We decline to make Patent Owner’s proposed change. First, this
`
`change does not affect the substantive analysis in this case. In other words,
`
`our decision on patentability is the same whether or not we adopt
`
`Petitioner’s proposed modification.
`
`Second, we are not persuaded by Patent Owner’s arguments that we
`
`should depart from the dictionary definitions, proffered by Petitioner’s
`
`declarant, Dr. Nick Roussopoulos (Ex. 1015 ¶ 48), and upon which we based
`
`our preliminary construction. For instance, during the oral hearing, Patent
`
`Owner conceded that retrieving data from a database is a type of
`
`manipulation.
`
`JUDGE TURNER: But if I’m obtaining a smaller set [of data
`items from a database], isn’t that manipulating or is it not? I
`understand I’m giving you a hypothetical and putting you on a spot.
`
`MR. HANFT: What I’m having trouble with is in that
`hypothetical you’re talking about retrieving data from a dataset, but
`then you’re trying to say, well, is that within the definition of a data
`manipulation language? It’s just kind of slightly apples and oranges
`because the data manipulation language has to have certain
`characteristics and be capable of certain things.
`Taking a dataset and reducing it down to a smaller set
`according to some characteristics is some type of manipulation, but a
`
`8
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`data manipulation language has to be able to do more than just
`retrieve. It’s got to do more than that.
`
`Paper 36 (“Tr.”) 38:7-18 (emphasis added). Fen Hiew, one of the named
`
`inventors of the ’936 patent, agreed with this understanding. Ex. 1045,
`
`47:15-18 (Q: “Would selection of data be a type of manipulation that’s
`
`performed by a data manipulation system?” A: “Yes”).
`
`We are not persuaded otherwise by Mr. Zatkovich’s testimony to the
`
`contrary. See Ex. 2001 ¶ 19. Mr. Zatkovich does not explain why retrieving
`
`data would not be considered manipulation of that data. Nor does he point
`
`to any objective evidence to support this conclusion. And Patent Owner
`
`does not point to persuasive language in the specification or other evidence
`
`that supports an interpretation of “data manipulation language” with the
`
`word “retrieve” removed or qualified as proposed.
`
`Thus, we decline to alter our preliminary construction of data
`
`manipulation language by removing or adding a qualification to the word
`
`“retrieve.”
`
`b. “directly”
`
`Although not couched as claim construction, Patent Owner argues that
`
`a data manipulation language must directly access data in a database. PO
`
`Resp. 33, 38-39. Patent Owner argues that because of this requirement, an
`
`object-oriented programming language cannot be a data manipulation
`
`language, even if it includes extensions, such as JDBC [Java Database
`
`Connectivity] or embedded SQL, for accessing a database. Id. In explaining
`
`this assertion, Mr. Zatkovich testifies that object-oriented programming
`
`languages facilitate the creation of programs that are a collection of
`
`interacting objects, as opposed to conventional programming languages, in
`
`9
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`which a program is a list of tasks. Ex. 2001 ¶ 22. As part of this paradigm,
`
`according to Mr. Zatkovich, the object-oriented approach typically places
`
`data in an object, where the data are not directly accessible by the rest of the
`
`program, but instead are accessed solely through methods bundled with the
`
`object. Id. ¶ 23. Mr. Zatkovich concludes that “[o]ne skilled in the art
`
`would not consider C++ and Java [which are object-oriented programming
`
`languages] to be data manipulation languages since they do not directly
`
`interact or directly perform data manipulation within databases.” Id. ¶ 24.
`
`Patent Owner adds that simply adding database functionality in the
`
`form of JDBC or embedded SQL to an object-oriented language does not
`
`convert the language into a data manipulation language. PO Resp. 38-39.
`
`Mr. Zatkovich testifies that when SQL is embedded in Java, the Java
`
`program simply passes the SQL statement to the database system—the
`
`embedded SQL statement is “processed merely as a text string to be passed
`
`to the DataBase Management System.” Ex. 2001 ¶ 47. According to Patent
`
`Owner, this shows that it is not actually Java or C++ code accessing data in a
`
`database, but instead the access is “being performed at and by the database
`
`itself.” PO Resp. 39. Thus, Patent Owner concludes that Java and C++ are
`
`not data manipulation languages, even when augmented by JDBC or
`
`embedded SQL. Id.
`
`Petitioner argues that a data manipulation language is a language that
`
`allows a program to simply access data in a database, without the
`
`requirement that the access be direct. Reply 9. According to Petitioner,
`
`Java and C++ access a database using embedded SQL and JDBC statements.
`
`Id. Petitioner relies on statements in the Oracle8 Primer to support this
`
`assertion. Id. at 9-10 (quoting Ex. 1013, 225 (“JDBC is an Application
`
`10
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`Programming Interface (API) that enables database access in Java.”), 93, 96,
`
`226). In addition, Dr. Roussopoulos testifies that “[e]mbedding SQL allows
`
`each of [the Java and C++] programming languages to access data in a
`
`database.” Ex. 1015 ¶ 114 (citing Ex. 1013, 93, 95, 103, 108, 118, 277, 280,
`
`281, 294, and 301); see also Ex. 1015 ¶¶ 49-51. Dr. Roussopoulos also
`
`states that “Oracle8 Primer discloses that the object-oriented nature of Java
`
`is no bar to having data manipulation language operations.” Id. ¶ 52
`
`(quoting Ex. 1013, 281 (showing that the “select” statement is translated into
`
`pure Java code), 301 (showing the same for inserting data in a database), 294
`
`(showing the same for creating database tables and rows)); see also Ex. 1015
`
`¶ 53 (showing the same for embedded C++).
`
`We are persuaded by the testimony of Dr. Roussopoulos that a data
`
`manipulation language does not require direct access to data in a database.
`
`To the extent that Patent Owner argues that Java and C++ never actually
`
`retrieve or manipulate data in a database because the embedded functionality
`
`does not directly access the database, we credit Petitioner’s evidence,
`
`particularly Exhibit 1013, which supports Dr. Roussopoulos’s conclusion
`
`that embedded SQL accesses and manipulates data in a database. All of
`
`Patent Owner’s evidence to the contrary hinges on the testimony of Mr.
`
`Zatkovich, which we do not find persuasive. Mr. Zatkovich’s conclusion
`
`that access to a database from a data manipulation language must be direct is
`
`unsupported. Mr. Zatkovich simply asserts this to be the case, without
`
`providing credible support. See Ex. 2001 ¶ 47.
`
`Patent Owner does not point to persuasive language in the
`
`specification or other evidence that supports an interpretation of data
`
`manipulation language restricted to direct access to a database. In fact, the
`
`11
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`’936 patent discusses, in several places, SQL and Oracle® RDBMS as
`
`examples of languages to which the invention is targeted. Ex. 1001 1:20-25;
`
`1:64-2:3; 8:22-26; 9:47-53; 10:5-7; 16:34-49; 17:17-19. And the ’936 patent
`
`does not specify that these languages would be excluded if the database
`
`access functionality is indirect. Dr. Roussopoulos agrees, stating that the
`
`’936 patent’s reference to these languages is consistent with embedding SQL
`
`in Java or C++. Ex. 1015 ¶ 54.
`
`Thus, we decline to alter the interpretation of “data manipulation
`
`language” by adding a qualification that access to the database be direct.
`
`c. Conclusion
`
`For these reasons, we adopt the interpretation of “data manipulation
`
`language” used in the Decision to Institute—“a programming language used
`
`to access data in a database, such as to retrieve, insert, delete, or modify data
`
`in the database.” We do not adopt any of the modifications to this
`
`interpretation urged by Patent Owner.
`
`2. Graphical Representation of Flows
`
`The term “graphical representation of flows” is recited by every
`
`challenged claim. In the Decision to Institute, we interpreted this term as “a
`
`diagram that depicts a map of the progression (or path) through the source
`
`code.” Dec. 8-9. Patent Owner does not explicitly challenge this
`
`interpretation, but makes several arguments that amount to a narrowing of
`
`the interpretation of the term. We address these arguments here.
`
`a. “data flows” and “program flows”
`
`In the Decision to Institute, we explained that the ’936 patent
`
`explicitly discusses two types of flow diagrams—“program flow diagrams”
`
`and “data flow diagrams.” Dec. 8-9 (citing Ex. 1001, 2:38-42). The ’936
`
`12
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`patent describes a “program flow diagram” as being “comprised of program
`
`block icons and arrows to depict the code’s program flow” and a “[d]ata
`
`flow diagram” as “comprised of icons depicting data processing steps and
`
`arrows to depict the flow of the data through the program.” Ex. 1001, 2:38-
`
`42. We were not persuaded, however, that the claim term “graphical
`
`representation of flows” is restricted to these two types of flow diagrams.
`
`Dec. 8-9.
`
`Patent Owner does not explicitly argue otherwise. Nevertheless, in its
`
`analysis, Patent Owner often limits the term to either program or data flow
`
`diagrams. These arguments are appropriate only for dependent claims 3
`
`(“wherein the graphical representations of flows depict program flows”) and
`
`4 (“wherein the graphical representations of data flows are expandable and
`
`collapsible”). Patent Owner goes further and applies the narrower
`
`interpretation to all the claims. For example, Patent Owner argues that Coad
`
`does not show “graphical representations of flows” by asserting that the
`
`“communications shown in Fig. 14 are not directly related to program or
`
`data flow” and “none of the remaining diagrams of Coad show program or
`
`data flow.” PO Resp. 31-32.
`
`Patent Owner, however, presents no persuasive explanation or
`
`evidence to support such a narrow interpretation of the claim term “graphical
`
`representations of flows.” As we pointed out in the Decision to Institute,
`
`Patent Owner has not directed us to language in the ’936 patent that limits
`
`the term to only these two examples. Nothing in Patent Owner’s response
`
`brief persuades us otherwise.
`
`13
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`b. “within the retrieved source code”
`
`Patent Owner argues that the term “graphical representations of
`
`flows” cannot properly be interpreted without taking into consideration the
`
`phrase that follows it in the claims—“within the retrieved source code.” PO
`
`Resp. 32-33. According to Patent Owner, because the source code is further
`
`defined in the claims to be a “data manipulation language,” the “claims
`
`require that the flows show source code steps actually performing data
`
`manipulation procedures.” Id. at 35. Patent Owner explains that the “intent
`
`and purpose of the invention is to permit the graphical representation of the
`
`flow within languages that manipulate data.” Id. at 36. Patent Owner also
`
`points to Figure 19 as showing that the graphical representations depict the
`
`program flow within the “actual source code that is manipulating the data.”
`
`Id.
`
`We agree with Patent Owner that the claim language clearly requires
`
`the graphical representations of flows to show flows within source code
`
`created with a data manipulation language. However, we are not persuaded
`
`that this requires the flows to show source code steps that are actually
`
`performing data manipulation. As described above, we have interpreted data
`
`manipulation language to be a programming language used to access data in
`
`a database, such as to retrieve, insert, delete, or modify data in the database.
`
`Although this interpretation requires that a data manipulation language allow
`
`a program to be written that manipulates data, the interpretation does not
`
`limit such a program to source code that manipulates data. In other words,
`
`source code written using a data manipulation language performs many
`
`types of actions, including, but not limited to, manipulating data.
`
`14
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`For example, Figure 20 of the ’936 patent shows a portion of the
`
`source code being displayed in the graphical representation. One of the
`
`function calls listed in the source code is “PRINT,” which is represented in
`
`the graphical representation as an icon. It is unclear, however, whether a
`
`print function is “actual manipulation of data.” See Tr. 65:19-23 (Q: “In the
`
`patent in figure 20(a) there is some code, and it has print data. Is that a data
`
`manipulation procedure? I don’t know if printing is manipulating.”
`
`A: “You’re not going to like my answer, which is I’m not an expert in this
`
`field, so I can’t answer that.”). And Patent Owner has not directed us to
`
`evidence that sheds light on this question.
`
`Moreover, as discussed above, Patent Owner asserts that retrieving
`
`data, as in an SQL SELECT statement, is not a manipulation of data. PO
`
`Resp. 10-11 (citing Ex. 2001 ¶ 19). Nevertheless, Patent Owner concedes
`
`that a program written with a data manipulation language may include
`
`functions used for retrieving data. See, e.g., PO Resp. 11 (“The Board’s
`
`interpretation should be modified to either remove the term ‘retrieve’ or to
`
`qualify the use of the term retrieve by stating that the retrieval must be
`
`followed by some manipulation procedure.”). Thus, it is undisputed that a
`
`program written using a data manipulation language may contain portions of
`
`code that perform actions independent from the manipulation of data. And
`
`Patent Owner does not point to persuasive language in the ’936 patent or
`
`other evidence supporting an interpretation that excludes those portions of
`
`the source code from the graphical representation. In other words, the
`
`claims require that the “received source code” is “programmed using one of
`
`a plurality of types of data manipulation languages,” but nothing in the
`
`15
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`claims requires that the “retrieved source code” contain functionality that
`
`actually manipulates data.
`
`Figure 19 does not persuade us otherwise. Patent Owner has not
`
`pointed to any indication in the ’936 patent that this figure is meant to limit
`
`the subject matter of the claims. To the contrary, the “Brief Description of
`
`Drawings” clearly identifies all the figures as depicting a preferred
`
`embodiment of the invention. Ex. 1001, 3:24-26 (“For a better
`
`understanding of the invention, reference may be had to a preferred
`
`embodiment shown in the following drawings.”). And the “Detailed
`
`Description” concludes by clarifying that the specific embodiments are not
`
`limiting. Id. at 17:62-66 (“While specific embodiments of the present
`
`invention have been described in detail, it will be appreciated by those
`
`skilled in the art that various modifications and alternatives to those details
`
`could be developed in light of the overall teachings of the disclosure.”);
`
`18:13-17 (“Accordingly, the particular arrangement disclosed is meant to be
`
`illustrative only and not limiting as to the scope of the invention which is to
`
`be given the full breadth of the appended claims and any equivalents
`
`thereof.”).
`
`Thus, we decline to alter the interpretation of “graphical
`
`representations of flows” by adding a requirement that the flows show
`
`source code steps that are actually performing data manipulation.
`
`c. Actual Pathways
`
`Petitioner states that Patent Owner improperly suggests that graphical
`
`representations of flows are limited to the actual path through source code as
`
`opposed to including all possible pathways through the code. Reply 8-9. In
`
`particular, Petitioner points to Patent Owner’s description of Coad, “[t]he
`
`16
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`concept underlying Coad is limited to depicting all potential (as opposed to
`
`actual) scenarios within an object-oriented program.” Reply 8 (citing PO
`
`Resp. 13). Patent Owner does not point to persuasive explanation or
`
`evidence supporting such a limitation. To the extent that Patent Owner is
`
`making this argument, we are not persuaded that the term should be so
`
`limited.
`
`d. Conclusion
`
`For these reasons, we adopt the interpretation of “graphical
`
`representations of flows” used for the Decision to Institute—“a diagram that
`
`depicts a map of the progression (or path) through the source code.” We do
`
`not adopt any of the modifications to this interpretation urged by Patent
`
`Owner.
`
`3. Program Flows
`
`The term “program flows” is recited in dependent claim 3. In the
`
`Decision to Institute, we did not explicitly interpret this term as part of the
`
`claim construction section. See Dec. 5-10. In the analysis portion of our
`
`decision, however, we stated that “Figure 14 [of Coad] depicts the source
`
`code program’s path of control from one step to another through the
`
`program—a program flow diagram.” Dec. 14. Neither party directly
`
`challenges this statement.
`
`Although the ’936 patent does not explicitly define “program flows,”
`
`it does define the term “program flow diagrams” as “comprised of program
`
`block icons and arrows to depict the code’s program flow.” Ex. 1001, 2:38-
`
`40. The specification then proceeds to use the terms “program flows” and
`
`“program flow diagrams” interchangeably. See, e.g., id. at 3:49-51 (“FIG. 9
`
`is an exemplary screen shot depicting a program flow for a selected file,
`
`17
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`along with arrows that indicate the flow of data within the program flow.”);
`
`16:3-5 (“By assigning meanings and attributes to tokens 144, the document
`
`view engine 200 allows the visualizer to create program flows 122 and data
`
`flows 124.”).
`
`Thus, we begin with the definition for “program flow diagrams” for
`
`our interpretation. Because it is not constructive for the definition of
`
`“program flows” to include the term “program flow,” we adopt the
`
`following slightly modified version—“a graphical representation comprised
`
`of program block icons and arrows to depict the progression of control
`
`through source code.”
`
`4. Data Flows
`
`The term “data flows” is recited by dependent claim 4. In the
`
`Decision to Institute, we did not explicitly interpret this term as part of the
`
`claim construction section. See Dec. 5-10. In the analysis portion of our
`
`decision, when discussing the data flow limitation, we stated that “[w]e are
`
`not persuaded that [the code view of Antis] is equivalent to a depiction of a
`
`map of the path of data through the executing source code.” Dec. 19.
`
`Petitioner argues that the word “executing” in that statement is improper.
`
`Reply 4.
`
`Although the ’936 patent does not explicitly define “data flows,” it
`
`does define the term “[d]ata flow diagrams” as “comprised of icons
`
`depicting data processing steps and arrows to depict the flow of the data
`
`through the program.” Ex. 1001, 2:40-42. The specification then proceeds
`
`to use the terms “data flows” and “data flow diagrams” interchangeably.
`
`See, e.g., id. at 4:12-13 (“FIG. 17 is an exemplary screen shot depicting a
`
`data flow for a selected file.”); 16:3-5 (“By assigning meanings and
`
`18
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`attributes to tokens 144, the document view engine 200 allows the visualizer
`
`to create program flows 122 and data flows 124.”).
`
`Thus, we begin with the definition for “data flows diagrams,” for our
`
`interpretation. Because it is not constructive to interpret the term “data
`
`flows” by using the phrase “flow of data,” we adopt the following slightly
`
`modified version—“a graphical representation comprised of icons depicting
`
`data processing steps and arrows to depict the movement of data through
`
`source code.”
`
`B. Overview of Coad
`
`Coad discloses a software development tool that allows a developer
`
`simultaneously to view and modify textual and graphical displays of source
`
`code regardless of the programming language in which the code is written.
`
`Ex. 1006, Abstract, 4:38-41. In the Background of the Invention, Coad
`
`describes conventional software development tools that allow the user to
`
`view Unified Modeling Language (UML)—a graphical representation or
`
`model using object-oriented design—and source code at the same time. Id.
`
`at 1:47–2:22.
`
`C. Overview of the Oracle Primers
`
`The Oracle Primers are books describing the Oracle database system.
`
`The Oracle8 Primer includes a chapter titled “Embedded SQL,” which refers
`
`to adding embedded SQL to C++, thus allowing writing application
`
`programs in C++ that “interact (read and write) with the database.” Ex.
`
`1013, 93. Another chapter, titled “Oracle JDBC” describes JDBC, “an
`
`Application Programming Interface (API) that enables database access in
`
`Java” and “consists of a set of classes and interfaces written in Java that
`
`allow the programmer to send SQL statements to a database server for
`
`19
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`execution and, in the case of an SQL query, to retrieve query results.” Ex.
`
`1013, 225.
`
`D. Alleged Obviousness over Coad and the Oracle Primers
`
`Petitioner asserts that claim 1 would have been obvious over Coad
`
`combined with Oracle Primer and Oracle8 Primer. Petitioner relies on Coad
`
`for every limitation except that Petitioner relies on the Oracle Primers for
`
`describing the use of SQL within Java and C++ and thus disclosing the data
`
`manipulation language limitation. Pet. 31-32 (citing Ex. 1015 ¶¶ 111-115).
`
`Petitioner points to Figures 11-17 of Coad as depicting aspects of the view
`
`for displaying graphical representations of flows in source code. Pet. 29-30.
`
`In the Decision to Institute, we determined that Petitioner had shown a
`
`reasonable likelihood of prevailing on this proposed ground of
`
`unpatentability. Dec. 15. In particular, we determined that Petitioner had a
`
`reasonable likelihood of prevailing on its assertions that the combination of
`
`Coad and the Oracle Primers disclosed every limitation of claim 1. Id. at 12-
`
`14. We also found reasonable Petitioner’s asserted rationale that a person of
`
`ordinary skill would have combined the teachings of Coad and the Oracle
`
`Primers in order to enhance the utility of the programming environment to
`
`include data manipulation. Id. at 14-15 (citing Pet. 25); see Ex. 1015 ¶ 115.
`
`In its response brief, Patent Owner argues that the combination of
`
`Coad and the Oracle Primers fails to disclose the limitations “graphical
`
`representations of flows within the retrieved source code” where the source
`
`code is written in a “data manipulation language.” PO Resp. 34-42. Patent
`
`Owner does not address any other limitations of claim 1 or the rationale to
`
`combine the references. Id.
`
`20
`
`
`
`IPR2013-00226
`Patent 7,110,936 B2
`
`1. Data Manipulation Language
`
`Patent Owner argues that Coad combined with the Oracle Primers
`
`does not describe a data man
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
