Teradata Corporation v. SAP SE

Opinion

TERADATA CORPORATION, et al., Case No. 18-cv-03670-WHO

Plaintiffs, CLAIM CONSTRUCTION ORDER v.

SAP SE, et al., Defendants.

There are five patents asserted in this case. All the patents relate to computer-implemented database systems. Generally, all of them are related to data storage, organization, retrieval, analysis, or removal. The ʼ179 Patent (Patent Number 7,617,179, issued November 10, 2009), is titled “System and Methodology for Cost-Based Subquery Optimization Using a Left-Deep Tree Join Enumeration Algorithm,” and teaches “query optimization” in a “relational database system.” ʼ179 Patent (Dkt No. 211-3). The claimed query optimizer identifies a plan containing “access methods” to obtain specific data from various tables. ʼ179 Patent: 2:40-3:4. The optimizer considers whether to join or combine data within different tables and potential methods to accomplish this. Id. at 3:5-24. The optimizer then selects an “optimal access plan” with favorable execution costs. Id. at 5:46-49. The ʼ421 Patent (Patent Number 9,626,421, issued April 18, 2017), is titled “ETL-Less Zero-Redundancy System and Method for Reporting OLTP Data.” ʼ421 Patent (Dkt. No. 211-9). It relates to database systems, particularly transactional and reporting database systems, and teaches a system that allows for synchronization of data stored in row format and data stored in column format. Id. at 1:15-17, 2:30-32. The ʼ437 Patent (Patent Number 7,421,437, issued September 2, 2008), is titled “System and Method for a Data Dictionary Cache in a Distributed System.” ʼ437 Patent (Dkt. No. 211-12). 1. The distributed system has three layers, a user layer, application layer, and data access layer. Id. at 1:48-55. The user layer allows for interaction between the distributed system and the user. Id. at 2:36-37. The application layer provides services to the user and accesses information from the data access layer. Id. at 1:49-52. The data access layer provides for data storage in “in one or more data dictionaries” for the distributed system. Id. at 3. The ʼ321 Patent (Patent Number 8,214,321, issued July 3, 2012), titled “Systems and Methods for Data Processing,” teaches a method and system allowing for transactional data in a “database warehouse” to be stored, grouped, and analyzed. ʼ321 Patent: 7:10-8:53 (Dkt. No. 211- 14). The ʼ516 (Patent Number 7,437,516, issued October 14, 2008), is titled “Programming Models for Eviction Policies,” and deals with memory management, specifically, for a virtual machine’s local memory which is implemented in a “cache.” ʼ516 Patent at 1 (Dkt. No. 211-17). The ʼ516 Patent teaches a method for putting objects in the cache and determining which objects to remove from in cache. Id. at 10:45-48, 13:50-55. The parties dispute nine claim terms from these five patents.1 Claim construction is a matter of law. See Markman v. Westview Instruments, Inc., 517 U.S. 370, 372 (1996); Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996). Terms contained in claims are “generally given their ordinary and customary meaning.” Vitronics, 90 F.3d at 1582. In determining the proper construction of a claim, a court begins with the intrinsic evidence of record, consisting of the claim language, the patent specification, and, if in evidence, the prosecution history. Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005); see also Vitronics, 90 F.3d at 1582. “A claim term used in multiple claims should be construed consistently . . . .” Inverness Med. Switzerland GmbH v. Princeton Biomeditech Corp., 309 F.3d 1365, 1371 (Fed. Cir. 2002). “The appropriate starting point [ ] is always with the language of the asserted claim itself.” Comark Commc’ns, Inc. v. Harris Corp., 156 F.3d 1182, 1186 (Fed. Cir. 1998). “[T]he ordinary and customary meaning of a claim term is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application.” Phillips, 415 F.3d at 1312. “There are only two exceptions to this general rule: 1) when a patentee sets out a definition and acts as his own lexicographer, or 2) when the patentee disavows the full scope of a claim term either in the specification or during prosecution.” Thorner v. Sony Computer Entm’t Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012). “Importantly, the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification.” Phillips, 415 F.3d at 1313. “Claims speak to those skilled in the art,” but “[w]hen the meaning of words in a claim is in dispute, the specification and prosecution history can provide relevant information about the scope and meaning of the claim.” Electro Med. Sys., S.A. v. Cooper Life Scis., Inc., 34 F.3d 1048, 1054 (Fed. Cir. 1994) (citations omitted). “[T]he specification is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.” Vitronics, 90 F.3d at 1582. “However, claims are not to be interpreted by adding limitations appearing only in the specification.” Id. “Thus, although the specifications may well indicate that certain embodiments are preferred, particular embodiments appearing in a specification will not be read into the claims when the claim language is broader than such embodiments.” Id. Finally, the court may consider the prosecution history of the patent, if in evidence. Markman, 52 F.3d at 980. The prosecution history may “inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be.” Phillips, 415 F.3d at 1317 (citing Vitronics, 90 F.3d at 1582-83); see also Chimie v. PPG Indus., Inc., 402 F.3d 1371, 1384 (Fed. Cir. 2005) (“The purpose of consulting the prosecution history in construing a claim is to exclude any interpretation that was disclaimed during prosecution.”) (internal quotations omitted). disputes. Vitronics, 90 F.3d at 1583. However, “it is entirely appropriate . . . for a court to consult trustworthy extrinsic evidence to ensure that the claim construction it is tending to from the patent file is not inconsistent with clearly expressed, plainly apposite, and widely held understandings in the pertinent technical field.” Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1309 (Fed. Cir. 1999). Extrinsic evidence “consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises.” Markman, 52 F.3d at 980. All extrinsic evidence should be evaluated in light of the intrinsic evidence, Phillips, 415 F.3d at 1319, and courts should not rely on extrinsic evidence in claim construction to contradict the meaning of claims discernible from examination of the claims, the written description, and the prosecution history, Pitney Bowes, 182 F.3d at 1308 (citing Vitronics, 90 F.3d at 1583). While extrinsic evidence may guide the meaning of a claim term, such evidence is less reliable than intrinsic evidence. Phillips, 415 F.3d at 1318-19. I. ʼ179 PATENT “Optimal access plan” / “Optimize” For example, as used in Claim 1 of the ʼ179 Patent:

In a database system, a method for optimizing a database query for execution by a processor, the method comprising … optimizing each query block to determine an optimal access plan for the query block based upon selecting pre-computed subquery access methods and join methods for subquery plan nodes of the query block as well as access methods, join methods, and join order for other plan nodes of the query block having favorable execution costs, wherein each query block is optimized without transformation of the subqueries using the pre-computed access methods and join methods; ’179 Patent at 38:47-48, 38:64-67-39:1-5. Patent/Term SAP’s Proposal Teradata’s Proposal “the estimated best “the access plan that Optimal access plan, considering has the lowest plan: Claims 1, 23 of estimates of execution the ʼ179 Patent execution costs, cost associated with among the it” plans considered”

Optimize[d]: Claims “find/found the “find the lowest 1, 23 of the ʼ179 estimated best plan, execution cost” Patent considering estimates of execution costs, among the plans considered” Both parties agree that the claims do not require finding the “absolute best plan,” but only a “reasonable plan,” and that the optimizer may only consider a subset of possible plans. Declaration of David Maier (“Maier Decl.,” Dkt. No. 211-1) ¶ 45; Teradata Responsive Claim Construction Brief (“TD CC,” Dkt. No. 219) at 6. In response to SAP’s position, Teradata states that it would be willing to add “among the plans considered” to its proposed definitions of “Optimal access plan” and “optimize[d].” TD CC 6. The real issue in dispute is whether “execution cost” is the only criterion used during the optimization process (Teradata’s position) or whether the patent simply requires “consideration” of the execution costs of various plans (SAP’s position). Teradata relies on its expert, Dr. Jaideep Srivastava, who notes that SAP’s own extrinsic evidence (the Ramakrishnan textbook) supports Teradata’s definition. See Declaration of Jaideep Srivastava (Dkt. No. 219-1) ¶ 24. The textbook explains that optimizing involves “[e]stimating the cost of each enumerated plan and choosing the plan with the lowest estimated cost.” See Ramakrishnan, et al. “Database Management Systems,” McGraw Hill Press (Third Ed. 2003), Dkt. No. 211-5 at 479. Teradata also points to the text of the ʼ179 Patent, which identifies “execution cost” as the only criterion, noting that the optimization process: determin[es] an optimal access plan for each query block based upon selecting access methods, join methods, and join order for plan nodes of the query optimization graph having favorable execution costs; and constructing a detailed access plan for execution of the database query based upon the optimal access plan determined for each query block. ʼ179 patent, 5:46-49 (emphasis added)); Srivastava Decl. ¶ 24. SAP disagrees with limiting the optimization criteria to only “execution costs.” SAP Claim Construction Reply Brief (SAP Reply) 1. SAP points out that the Patent specifies contends that the Patent identifies other factors to be considered, pointing to one embodiment where plan selection is based on a “property vector” that is used to “compare the current access plan with the best plan that has been previously found.” Reply Declaration of David Maier (Dkt. 222-1) ¶ 5; ʼ179 Patent 18:58-60. SAP notes that the Patent goes on to explain that “[a] main component of the property vector is the cost estimate associated with a plan node or a partial access plan” which confirms other components are considered. SAP Reply 2 (quoting ʼ179 patent at 18:60-62). Given the heavy and repeated emphasis on “costs” in the claim language and specification, cost is obviously a key if not primary factor in optimization. However, Teradata’s attempt to exclude from consideration any other non-cost factors is simply not supported. Adopted Construction – “Optimal access plan”: The estimated best plan, considering estimates of execution costs, among the plans considered. Adopted Construction – “Optimize[d]”: Find/found the estimated best plan, considering estimates of execution costs, among the plans considered. “ Query optimization graph” For example, as used in Claim 1 of the ʼ179 Patent (emphasis added):

In a database system, a method for optimizing a database query for execution by a processor, the method comprising: receiving a database query including at least one subquery; building a query optimization graph for each query block of the database query, the query optimization graph including plan nodes representing subqueries of each query block; ’179 Patent at 38:47-53. Patent/Term SAP’s Proposal Teradata’s Proposal “an internal “a representation of a Query optimization representation of a query block in the graph: Claims 1,3, query block or form of a hypergraph 23 of the ʼ179 Patent derived table (a graph in which an block, structured as a edge can join any graph” number of vertices) that includes vertices (nodes) and edges (connections between two nodes), including hyperedges (a link more than two nodes) in which nodes can represent subplans and quantifiers; and in which each node representing subplans includes an array of access methods and an array of join methods” Both sides admit that the preferred embodiment of the ʼ179 Patent describes a “hypergraph.” Teradata relies heavily on the fact that in discussing the preferred embodiment in the “Detailed Description of a Preferred Embodiment” section, “Definition 4” defines the “query optimization graph” (QOG) as a hypergraph. ʼ179 Patent, 14:47-49. Teradata argues, therefore, that the QOG must be defined as a hypergraph, noting that there are no other types of embodiments of QOGs disclosed in the ʼ179 Patent. SAP responds by pointing out that Definition 4 is not contained in the “glossary section” (which defines terms used throughout the Patent) but only in the definitions section of the preferred embodiment, which makes it improper to define for the Patent as a whole. SAP also argues that Teradata’s definition (including the mention of edges and nodes) is improper because it would make dependent claim 3 (which covers the “method of claim 1, wherein said building step includes building a query optimization graph including subplans and quantifiers of each query bloc”) superfluous. SAP Claim Construction Brief (“SAP CC,” Dkt. No. 211) 5; ʼ179 Patent 39:11-14; Phillips v. AWH Corp., 415 F.3d 1315 (Fed. Cir. 2005) (en banc) (“[T]he presence of a dependent claim that adds a particular limitation gives rise to a presumption that the limitation in question is not present in the independent claim.”). Teradata contends that this doctrine does not apply where an explicit definition is included in the patent itself and that SAP is impermissibly attempting to broaden the scope of the QOG term. TD CC 5. Teradata, however, never directly addresses the fact that Definition 4 is used to describe the preferred embodiment and not the scope of the invention itself. SAP also argues the query optimization graph is not limited to hypergraphs by pointing to intrinsic evidence including prior art references, examiner statements, and inventor’s arguments. SAP CC 5. For instance, SAP points to two examples in the prior art cited by the examiner that depict QOGs that are not hypergraphs - a “tree structure” and a QOG that is an “internal representation of a complete SQL statement, possible composed of multiple ‘subquery blocks.’” JCCPS Exhibit 1 [Dkt. No. 2016-1] at 3 (citing language from the Young-Lai Patent). SAP contends that these types of graphs appeared in the prior art cited by the examiners, and, as a result, a POSITA would have known that a QOG was not limited to a hypergraph. I agree with SAP that Definition 4 is relevant to the preferred embodiment and not (as the glossary is) relevant to the Patent as a whole and, relatedly, that the use of a hypergraph in the preferred embodiment does not require QOGs to be hypergraphs. Adopted Construction – “Query optimization graph”: An internal representation of a query block or derived table block, structured as a graph. Query Block As used in Claim 1:

In a database system, a method for optimizing a database query for execution by a processor, the method comprising: receiving a database query including at least one subquery; building a query optimization graph for each query block of the database query, the query optimization graph including plan nodes representing subqueries of each query block. ’179 Patent at 38:47-53. Patent/Term SAP’s Proposal Teradata’s Proposal Query block “an atomic portion of “a part of a query that Claims 1, 2, 3, 23 of a query that contains multiple the ʼ179 Patent can be separately parts because the optimized” query contains [all asserted claims] derived tables, views, and/or subqueries” Both sides agree that a query block is the smallest part of a query that can be separately optimized. Teradata would consider including the word “atomic” in its definition if the parties could clarify the meaning of atomic since it does not hold a “well-known meaning for potential jurors.” TD CC 8. In response to Teradata’s concern over the word atomic, SAP proposes an alternative construction: a query block is “the smallest portion of a query that can be separately optimized.” SAP 4. The remaining dispute is whether the additional features of a query (containing the query block) identified in the Patent specification should be included in this definition. Both parties derive their definitions from the “glossary” section of the ʼ179 Patent which states, “[a] query block refers to an atomic portion or block of a query that has more than one block because the query contains derived tables views, and/or subqueries.” ʼ179 Patent: 4:43–45. The glossary definition then gives three examples of what query blocks can be. SAP argues that its construction should be adopted because it explains what a query block is. SAP CC 8. SAP omits the “has more than one block because the query contains derived tables, views, and/or subqueries” part of the glossary definition, not because it is “inaccurate” but because it is “unnecessary” and difficult for a jury to understand. Id. Teradata contends that by omitting this language, SAP is attempting to omit the “very thing [it] has named query block” and is an attempt to expand the scope of the patent. TD CC 8 (internal quotations omitted). SAP contends that Teradata’s definition, focusing on “why” something is a query block, could lead to juror confusion and could lead a juror to improperly understand that a query block encompasses any part of the query even if it is too small or too large to be optimized. SAP CC 8. SAP cites to Teradata’s expert’s admission that Teradata’s proposed definition only “explains why a query block would be created.” SAP Reply 4 (quoting Srivastava ¶ 26). After considering both sides’ arguments, in my Tentative Opinion issued prior to the June 12, 2020 Hearing, I suggested a construction of this claim term. Dkt. No. 265. Both sides agreed to my proposed construction. June 12, 2020 Transcript (Transcript) 20:18-24. Adopted Construction – “Query block”: A query block refers to the smallest portion of a query (which has more than one block) that can be separately optimized. II. ʼ421 PATENT A. “share a consistent view of said database information” For example, as used in Claim 1 of the ʼ421 Patent:

A computer system storing a computer program for processing computer system comprising… in response to a database update request, said relational database management system component updates said database information stored in said row format, said relational database management system component notifies said column-oriented data processing component of said database update request, and said column-oriented data processing component updates said database information stored in said column format, whereby said relational database management system component and said column- oriented data processing component share a consistent view of said database information ’421 Patent at 19:64-67, 20:12-23. Patent/Term SAP’s Proposal Teradata’s Proposal Share a consistent “update the row- “database information view of said format data (by the that if accessed by database relational the relational database information: Claims database management 1,19, 20 of the ’421 management system component is the Patent component) and same as if accessed update the column- by the [all asserted claims] format data (by the column-oriented data column-oriented data processing processing component” component) within the same database transaction” SAP argues that the Patent makes clear that the “column-format data and the row-format data are updated within the same database transaction.” SAP CC 10; Maier Decl. ¶ 81. Dr. Maier contends that a POSITA would have understood “share a consistent view of said database information” to have multiple meanings in the art. Maier Decl. ¶ 81. However, based on the Patent and prosecution history, a POSITA would have understood it consistent with SAP’s proposed construction, including the cabining of the process to “within the same transaction.” Id. ¶ ¶ 81-84. SAP contends that Teradata’s construction is insufficient because it could imply that the two components of data are updated in separate transaction that would be contrary to the term “share a consistent view of said database information.” SAP CC 11. Teradata asserts that SAP’s construction does not require data consistency and hides this with the phrase “within the same database transaction.” TD CC 16. Teradata’s expert, Dr. Shahram Ghandeharizadeh states that a POSITA would have understood the term to refer to the “database information, not the database transaction, as being the same.” Declaration of Shahram significant limitation that the “two components are working with the same data at all times.” TD CC 15. It argues that SAP’s use of the phrase “within the same database transaction” is an attempt to insert a specific embodiment into the claims that ignores other embodiments. TD CC 16. SAP replies that it does not improperly read “consistent” out of the claim since “share a consistent view” refers to the timing of the updates, which their definition encompasses. SAP Reply 6. It asserts that its construction addresses the timing of the updates in a way that demonstrates the row-format and column-format data are updated in the same way because they are responding to the same update request. SAP Reply 5. SAP argues that Teradata fails to do this – and itself fails to guarantee consistency – because Teradata’s construction would be satisfied if both row-format and column-format data were updated in the same way but in different requests. SAP Reply 6. I agree with SAP that there is adequate support for requiring the consistency to be achieved during the “same transaction” and adopts its proposed construction. Adopted Construction – “Share a consistent view of said database information”: Update the row-format data (by the relational database management system component) and update the column-format data (by the column-oriented data processing component) within the same database transaction. B. “wherein generating the query response accesses only one or more columns needed directly for generating the query response” As used in Claim 1 of the ʼ421 Patent:

A computer system storing a computer program for processing database information for both transacting and reporting, said computer program being executed by said computer system, the computer system comprising… in response to a query request to retrieve data, said column-oriented data processing component generates a query response based on said database information stored in said column format, wherein generating the query response accesses only one or more columns needed directly for generating the query response. ’421 Patent at 19:64-67, 20:12-23. In their briefing, the parties agreed that this claim does not need to be construed and its III. ʼ437 PATENT The parties seek construction of only one claim term from the ʼ437 Patent. “a plurality of data dictionary cache at an application level” As used in Claim 1:

A computer-implemented method comprising …referencing a plurality of data dictionary cache at an application level to obtain the data type associated with the system information…. selecting a data dictionary cache from the plurality of data dictionary cache at the application level, if the data dictionary cache includes the data type ’437 Patent at 7:65, 8:8-10, 8:17-19. Patent/Term SAP’s Proposal Teradata’s Proposal A plurality of data “multiple data “multiple data dictionary cache at dictionary caches at a dictionary caches that an application level: layer of software, are in corresponding different from a data Claims: 1, 6, 11, 15 application servers access layer, that of the ’437 Patent provides services to a existing in a layer user of data dictionary different from the information, and data access level” obtains that data dictionary information from the data access layer”

SAP added the underlined clause in response to Teradata’s argument that SAP’s definition confused the “application level” and the “data level.” TD CC 18; SAP CC Reply 8. Teradata takes no issue with that clarification. The parties still dispute whether there is a need to include “corresponding” from Teradata’s definition, and whether it would confuse a jury into thinking that correspondence between two layers is required. SAP CC 14. SAP argues that the use of “corresponding” improperly implies that a correspondence between “data dictionary caches and application servers is required.” SAP CC 15. SAP and Maier argue that a POSITA would understand that such correspondence between the servers would not be required. The next issue is the location of the data dictionary caches. Teradata asserts that it takes no position on “whether the claimed data dictionary caches must reside on one application server, or a that any such caches must be at the application level (i.e. in one or more application servers) and not the data access level.” However, SAP’s expert, Maier contends that a POSITA would not have “inferred that there was a correspondence between a cache in the application layer and an application server” which he argues is confirmed in the prosecution history. Maier Decl. ¶¶ 92-93. At the hearing, Teradata agreed that “correspondence” could be dropped from its definition, nullifying that dispute. However, it reasserted its position that its language focusing on application servers should remain in to avoid ambiguity. Transcript 46:24 - 47:6. I disagree. Teradata’s attempt to insert that additional limitation of a required connection to an “application server” into this construction is without support. Adopted Construction – “a plurality of data dictionary cache at an application level”: Multiple data dictionary caches at a layer of software, different from a data access layer, that provides services to a user of data dictionary information, and obtains that data dictionary information from the data access layer. IV. ʼ321 PATENT Initially, the parties disagree over what the qualifications for a POSITA would be for the ʼ321 patent; Teradata contends through its expert Dr. Gandeharizadeh that a “higher” level of skill (a master’s degree or a bachelor’s in computer science plus four years’ experience) is appropriate for this patent. Ghandeharizadeh Decl. ¶¶ 17-20. Both parties agree that the qualifications of a person of skill in the art should not affect the claim construction analysis for any patent. TD CC 2; SAP CC 1. A. “Mapping” / “Mapping Table” As used in claim 4:

A data processing system comprising… a mapping table for mapping a sub-set of the set of online analytical processing cubes to the at least one class of online analytical processing cubes

’321 Patent at 7:46, 8: 5-7. As used in claim 7:

The computer program product of claim 6, the online analytical Id. at 8:48-50. Patent/Term SAP’s Proposal Teradata’s Proposal Mapping: Claims 1, “creating and storing, “associating or 4, 6 of the ’321 in computer system assigning” Patent memory or secondary storage for a computer system, an association between two data elements in the computer system such that a computer can locate a data element using that association Mapping table: “a computer- “a computer- Claim 7 of the ’321 implemented data implemented data Patent structure that holds structure associations or that holds assignments, each associations or between two assignments” data elements in a computer system” The disputes on these terms are whether “mapping” must be stored and whether the mapping is limited to “between two data elements.” The underlined text in SAP’s proposal was offered in response to Teradata’s argument that storage needed to be defined. On the first issue, SAP argues that in all embodiments the mapping is stored, which makes sense because its purpose is to allow applications to access and process entities stored in tables and cubes assigned to classes, and it points to references in the Patent to mapping being “retrieved”, not created anew. ʼ321 Patent 5:45-54. Teradata replies that there is nothing in the Patent showing that there is a requirement that either the “mapping” or “mapping table” be stored “persistently” and contends that storage of mapping is simply permissive in the Patent. ʼ321 Patent 6:11-17 (noting mapping and mapping table data “may be” stored). Teradata also accuses SAP of attempting to collapse the distinction between mapping and mapping table, because the Patent explains only that “corresponding mapping may be stored as a further mapping table.” Id. As to the second issue, SAP argues that in the patent, “mapping” assigns pairs of elements and a POSITA would have understood this to be true. SAP CC 18. Teradata disagrees with any class, there is not necessarily a 1:1 relationship. TD CC 11. SAP reasserts that although more than one table can be mapped to a class, the assignment of each table to class is done in a pairwise way one table at a time and that Teradata’s expert’s statements also support this construction. SAP Reply 10-11. I agree with SAP that mapping is stored given the logical need and evidence in the specification. But I agree with Teradata that there is insufficient basis to limit that mapping to “pairwise” elements as a matter of claim construction. Adopted Construction – “Mapping”: Creating and storing, in computer system memory or secondary storage for a computer system, an association between data elements in the computer system such that a computer can locate a data element using that association. Adopted Construction – “Mapping Table”: A computer-implemented data structure that holds associations or assignments. B. “Online Analytical Processing Cube” As used in Claim 1:

A data processing method comprising… providing a set of online analytical processing cubes in a data warehouse, each online analytical processing cube specifying a layout for transactional data storage;’321 Patent at 7:12, 16-18. Patent/Term SAP’s Proposal Teradata’s Proposal Online analytical “a data structure “a data structure processing cube: (or a computer- designed to store Claims 1, 2, 4, 6, 7, 8 executable definition multidimensional of the ’321 Patent thereof) to store data, where data to be multidimensional stored in the data data, where data to be structure is provided stored in the data by online analytical structure is or will be processing.” provided by online analytical processing” The parties agree that the OLAP cube is a “a data structure designed to store multidimensional data,” referring to a physical instance of a data structure.2 In dispute is whether the construction should also include the data-structure “definition” used to create that instance. SAP argues that the “definition” term should be included because the ʼ321 Patent contains several statements indicating that OLAP cubes may be “predefined,” and therefore a POSITA would have understood OLAP cubes in context of the Patent to include both the data structure and definition. SAP CC 18; SAP Reply at 11 (“in instantiated OLAP cube is created from its definition, making the definition and instance two stages of the same cube.”). SAP’s expert agrees that a POSITA would have understood the term to reference both the data structure and the definition of the data structure. Maier Decl. ¶¶ 102-103. Teradata responds that SAP is seeking to expand the claimed term because the “existence of a definition does not necessarily mean an instance of it exists.” Ghandeharizadeh Decl. ¶ 31. The definition of an OLAP cube, according to Teradata, must be implemented in a data structure in order to embody what is claimed, and the patent cannot cover only the definition without at least one instance. SAP replies that it is not saying that the definition of a data structure and an instantiated cube are the same, but that in context of the Patent a POSITA would have understood an OLAP cube to potentially refer to either. Therefore, it amended its proposed construction, to include the underlined text. But I agree with Teradata that SAP is attempting to broaden this term without support and will adopt Teradata’s proposal. Adopted Construction – “Online Analytical Processing Cube”: A data structure designed to store multidimensional data, where data to be stored in the data structure is provided by online analytical processing. C. “[means for] invoking an online analytical processing component to fill the online analytical processing cubes with transactional data” As used in Claim 1:

A data processing method comprising …invoking an online analytical processing component to fill the online analytical processing cubes with transactional data[.]

’321 Patent at 7:12, 29-31. As used as “means-plus-function” element in Claim 4:A data processing system comprising … means for invoking an online analytical processing component to fill the online analytical processing cubes with transactional data[.]

Id. at 7:46-8:8-10. Patent/Term SAP’s Proposal Teradata’s Proposal [means for] “using software to “using an online invoking an online transfer transactional analytical processing analytical data into online component to processing analytical processing transfer transactional component to fill cubes” data into empty the online online analytical analytical processing cubes” processing cubes This claim element is This claim element is with transactional governed governed by 35 data: Claim 1, 4 of by 35 U.S.C. 112(6). U.S.C. 112(6). the ’321 Patent Structure/Material/Acts Corresponding [all asserted claims] An application program. Structure: none; indefinite

The parties disagree about the meaning of the term when invoked as a step as depicted in Claim 1 and regarding the use of the term as a “means-plus-function” element as depicted in Claim 4. Regarding the use of the term as a “means-plus-function” element, the parties argue whether the specification adequately describes a corresponding structure for performing the function. 1. “Invoking Step” First, the parties disagree whether the OLAP cubes must be empty when “transfer[ing] transactional data into” them. SAP argues that there is nothing in the claims nor the specification requiring that the OLAP cubes must be empty. Rather, the language implies only that they “may be” empty. SAP CC 20. Teradata responds that the statement that the OLAP cubes “may be empty” is the only evidence cited by SAP, and that this supports its position that the cubes must initially always be empty. TD CC 13. Teradata also asserts that the claims and specifications “invoking” step occurs the cube has not been filled. Id. SAP replies that nothing in the claims requires the steps to be performed in order, and there is nothing in the claims that require the OLAP cubes to be empty when provided. I agree with SAP. Teradata’s proposed construction inserting “empty” is not supported. Adopted Construction – “Invoking an online analytical processing component to fill the online analytical processing cubes with transactional data”: Using software to transfer transactional data into online analytical processing cubes. 2. “Means-Plus-Function” Turning to the question of whether there is an adequately disclosed structure to perform the claimed means, SAP argues that the specification discloses that the “invoking” function is used with an application program, which is a sufficiently disclosed structure. SAP CC 19. SAP lists several examples of application programs that a POSITA would have known could invoke OLAP functionality. Id. at 19-20. It relies on Zeroclick, LLC v. Apple Inc., where the Federal Circuit found that the claims were not invalid for indefiniteness under § 112 ¶ 6. 891 F.3d 1003, 1008 (Fed. Cir. 2018) (finding that in the patent “program” and “user interface code” were not used as “generic terms” but “as specific references to conventional graphical user interface programs or code, existing in prior art at the time of the inventions.”). Teradata argues that a generic application program is not enough to satisfy the structure requirements under the Federal Circuit case law. It relies, instead, on Aristocrat Techs. Australia PTY Ltd. v. Int’l Game Tech., where the Federal Circuit affirmed the district court’s ruling that providing a “general purpose microprocessor” was not a sufficient disclosure of structure under 112 ¶ 6 as the patent holder did not “disclose particular structure in the specification … to avoid pure functional claiming.” 521 F.3d 1328, 1333 (Fed. Cir. 2008). Teradata argues since the claim does not explain how the software works, it does not satisfy § 112 ¶ 6. SAP replies that here the particular structure is an application program, which is not a prohibited simple reference to “general-purpose computer processor” or just “appropriate programming.” It contends that Zeroclick itself demonstrated that a computer program can be an Circuit opinion that clarified that Aristocrat’s holding requires a “specific algorithm” only when the asserted structure is a reference to a “general-purpose computer or microprocessor”, which is not what this Patent discloses. Nevro Corp. v. Boston Sci. Corp., 2020 WL 1802794 *1, *5 (Fed. Cir. April 9, 2020). At the hearing, both sides admitted that the determination of whether there is a sufficiently disclosed structure for this means does not need to be determined on claim construction. Both agreed that this determination could be deferred until summary judgment when this and other means-plus-function claims will be addressed. Transcript at 39:6-12 (Teradata); 43:3-7 (SAP). I will therefore address all of Teradata’s means-plus-function challenges at that time. V. ʼ516 PATENT The parties dispute three related phrases from the ʼ516 Patent: “eviction policy plug-in” / “storage policy plug-in” / “plug-in” As used in Claim 1 of the ʼ516 Patent:

A method, comprising …configuring respective first and second cache portions by plugging said first and second eviction policy plug- ins into a cache management software program and plugging respective first and second storage plug-ins into said cache management software program; ’516 Patent at 19:25, 43-47. Patent/Term SAP’s Proposal Teradata’s Proposal Plug-in: Claims 1, 9, “piece of software or “a discrete body of 17 of the ’516 Patent code that provides a code that is separate [all asserted claims] requisite from a main program functionality” and can be added to and removed from the main program without

modification to the main program, such that the discrete body of code adds functionalities to the main program when added to it” Eviction “the actual piece of “plug-in for policy plug-in: software or code that performing a sorting Claims 1, 9, 17 of the dictates the removal method and ’516 Patent of an object from an eviction timing Storage policy “the actual piece of “plug-in for plug-in (or software or code that performing cache storage plugin): executes the “get” storage treatment of Claims 1, 9, 17 of the and “put” operations stored data.” ’516 Patent for objects stored in cache” SAP argues that Teradata’s construction would include limitations that are not supported by intrinsic evidence. These limitations would require the plug-ins to be:

1) a discrete body of code; 2) separate from a main program; 3) able to be added to and removed from the main program without modification to the main program; and 4) add functionalities. SAP Reply 13. Teradata contends that these limitations are well-supported by the general understanding of the “known term of art” of a “plug-in” and that because SAP did not act as its own lexicographer and did not otherwise define “plug-in” to be something other than what was generally understood at the time, its construction should be adopted. Declaration of Dr. Daniel Menascé (Dkt. No. 219- 5) ¶¶ 24-25 (“eviction policy plug-in” and “storage policy plug-in” contain a known term of art, “plug-in,” a POSITA would have understood what these terms mean in context of the known term). In turn, Teradata argues that the definition of “plug-in” cannot be separated from the definition of “eviction policy plug-in” or “storage policy plug-in.” TD CC 21. SAP responds that eviction policy plug-ins and storage policy plug-ins were not used in this Patent consistent with existing terms of the art and SAP’s definitions should be adopted because they are taken from the specification. SAP CC 23; ʼ516 Patent, at 7:8–11 (explaining an embodiment of the eviction policy plug-in); ʼ516 Patent, at 7:1–4 (explaining an embodiment of the storage policy plug-in); Maier Decl. ¶¶ 106-08. SAP argues that Teradata improperly ignores the intrinsic evidence and construes “plug-in” in isolation, which is improper because “plug-in” even has several different terms of the art which could lead to jury confusion. SAP CC 23. SAP admits that a “plug-in” is a common term of art but it argues the term has no “single well-accepted meaning” and that Teradata’s extrinsic evidence supports this by showing “inconsistent meanings of ‘plug-in.’” SAP Reply 15. Unlike other examples of plug-in and as required by Teradata’s patent’s functionality. SAP CC 23; Maier Decl. ¶ 110 (stating “[a] POSITA would have recognized that the ‘eviction policy plug-in’ and ‘storage plug-in’ performed specific functions that were required for the operation of the cache manager of the ʼ516 patent”). Finally, SAP contends that Teradata’s proposal adds limitations that are not supported by either the cited intrinsic or extrinsic evidence: namely, “none of the cited evidence indicates that a ‘plug-in’ must be ‘a discrete body of code,’ or requires that a ‘plug-in’ ‘can be added to and removed from the main program without modification to the main program.’” SAP CC 24. Teradata replies that the claim language shows that a plug-in must be “plug[ed] into a main program.” TD CC 24 (internal quotations omitted). Further, the specification shows “that a plug- in in a library is a discrete body of code that is plugged into a cache manager… without modifying the rest of the main program”). ʼ517 Patent, Figures 4, 16. SAP agrees with Teradata that the claims use of “plugging” shows that the plug-in is added to the “cache management software,” but figures in the ʼ516 patent show the “eviction policy plug-in and the storage plug-in within the cache manager … indicating that the two plug-ins are neither discrete nor separate.” See Figures 4- 8 (showing the plug-ins within the cache management software). In my Tentative Order, I proposed the following definition of plug-in: a “piece of software or code that can be added to and removed from the main program without modification to the main program to provide a requisite functionality.” Dkt. No. 265 at 4. I also tentatively adopted SAP’s proposed definitions for eviction and storage policy plug-ins. Id. As the hearing, Teradata was happy with the Court’s construction of plug-in, but questioned how it would fit into the policies. Transcript at 30:10-13. SAP agreed with part of the suggested definition but took issue with “removed,” as removal of the plug-in is not required or supported by the claim language or specification. Transcript at 28:21-25. SAP also argues that the “without modification” language needs clarification so that it is clear that the addition of the plug-in would be done “without modification to the other functionality of the main program.” Transcript at 29:12-16. I adopt SAP’s proposed revision of my proposed language. My construction does not foreclose Teradata’s argument that the plug-in must be a “discrete” modular set of code and that functionality. Those arguments can be raised on summary judgment. Adopted Construction – “Plug-in”: A piece of software or code that can be added to the main program without modification to the other functionality of the main program.” Adopted Construction – “Eviction policy plug-in”: The plug-in that dictates the removal of an object from cache. Adopted Construction – “Storage policy plug-in (or storage plugin)”: The plug-in that executes the “get” and “put” operations for objects stored in cache. For the foregoing reasons the disputes terms are construed as follows: “Optimal access plan”: The estimated best plan, considering estimates of execution costs, among the plans considered. “Optimize[d]”: Find/found the estimated best plan, considering estimates of execution costs, among the plans considered. “Query optimization graph”: An internal representation of a query block or derived table block, structured as a graph. “Query block”: A query block refers to the smallest portion of a query (which has more than one block) that can be separately optimized. “Share a consistent view of said database information”: Update the row-format data (by the relational database management system component) and update the column-format data (by the column-oriented data processing component) within the same database transaction. “A plurality of data dictionary cache at an application level”: Multiple data dictionary caches at a layer of software, different from a data access layer, that provides services to a user of data dictionary information, and obtains that data dictionary information from the data access layer. “Mapping”: Creating and storing, in computer system memory or secondary storage for a computer system, an association between data elements in the computer system such 1 “Mapping Table”: A computer-implemented data structure that holds associations 2 or assignments. 3 “Online Analytical Processing Cube”: A data structure designed to store 4 multidimensional data, where data to be stored in the data structure is provided by online 5 analytical processing. 6 “Invoking an online analytical processing component to fill the online analytical 7 processing cubes with transactional data”: Using software to transfer transactional data 8 into online analytical processing cubes. 9 “Plug-in”: A piece of software or code that can be added to the main program 10 without modification to the other functionality of the main program.” 11 “Eviction policy plug-in”: The plug-in that dictates the removal of an object from 12 cache. 13 “Storage policy plug-in (or storage plugin)”: The plug-in that executes the “get” and 14 “put” operations for objects stored in cache. IT IS SO ORDERED. A 16 Dated: July 15, 2020

S 18 liam H. Orrick 19 United States District Judge 20 21 22 23 24 25 26 27 28