Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 1 of 79 PageID #:
`4614
`
`
`
`
`
`EXHIBIT 5
`
`
`
`
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 2 of 79 PageID #:
`4615
`
`Filed on behalf of: R2 Solutions LLC
`
`By: Carder W. Brooks
`Registration No. 75,456
`NELSON BUMGARDNER CONROY P.C.
`3131 W. 7th St., Suite 3000
`Fort Worth, TX 76107
`Telephone: (817) 806-3814
`Email: carder@nelbum.com
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`Databricks, Inc.,
`
`Petitioner
`
`v.
`
`R2 Solutions LLC,
`
`Patent Owner.
`
`________________
`
`Case IPR2024-00659
`
`U.S. Patent 8,190,610
`________________
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 3 of 79 PageID #:
`4616
`
`TABLE OF CONTENTS
`
`INTRODUCTION ........................................................................................... 1
`
`BACKGROUND ............................................................................................. 2
`
`A. Overview of the ’610 Patent ........................................................................ 2
`
`1.
`
`Introduction to MapReduce ..................................................................... 2
`
`2. Shortcomings of Prior Technologies ....................................................... 6
`
`3.
`
`Improvement to MapReduce Described by ’610 Patent. ......................... 9
`
`4. The Claimed Technology of the ’610 Patent Improves MapReduce. ...13
`
`I.
`
`II.
`
`
`
`
`
`
`
`
`
`
`
`III. LEVEL OF ORDINARY SKILL ..................................................................15
`
`IV. CLAIM CONSTRUCTION ..........................................................................15
`
`V. APPLICABLE LEGAL STANDARDS ........................................................18
`
`
`A. Obviousness ...............................................................................................19
`
`1. Claims Cannot Be Found Obvious if an Element Is Absent. ................19
`
`2. A Petition Must Provide Articulated Reasoning with Rational
`Underpinning to Combine and/or Modify References. .........................20
`
`A. Overview of Primary Reference: Pike .......................................................22
`
`
`
`
`
`
`
`
`VI. SUMMARY OF THE PRIOR ART REFERENCES ....................................22
`
`
`B. Overview of Secondary References: Chowdhuri ......................................25
`
`
`VII. THE PETITION SHOULD BE DENIED UNDER 35 U.S.C. § 325(d). ......28
`
`
`A. Substantially the Same Art and Arguments Were Previously Presented
`to the Office. ..............................................................................................29
`
`B.
`
`Petitioner Has Failed to Demonstrate that the Office Committed Material
`Error. ..........................................................................................................33
`
`
`
`
`
`Patent Owner’s Preliminary Response
`
`
`
`ii
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 4 of 79 PageID #:
`4617
`
`VIII. THE PETITION DOES NOT DEMONSTRATE THAT THE
`CHALLENGED CLAIMS ARE UNPATENTABLE. .................................35
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`A. Ground 1: Pike Does Not Teach or Suggest at Least One Limitation of
`Each Independent Claim. ...........................................................................37
`
`1. Pike Does not Disclose “Data Groups.” ................................................37
`
`2. Pike Does not Disclose Delineating “Data Groups” Prior to
`Partitioning. ............................................................................................41
`
`3. Pike Does not Disclose “Intermediate Data” that Is “Identifiable” to
`a “Data Group.” .....................................................................................45
`
`4. Pike Does not Disclose “Data Groups” with Different Schemas. .........49
`
`5. Pike Does not Disclose a Key in Common Between the (1) “Data
`Groups”/Schema of the Input Data, and (2) the Intermediate Data.......52
`
`6. Pike Does not Disclose Processing Intermediate Data According to
`its “Data Group,” or Merging the Intermediate Data Based on a Key in
`Common Between the Intermediate Data and the “Data Groups.” .......54
`
`B. Grounds 2 and 3: Combining Chowdhuri with Pike Fails to Render the
`Independent Claims Obvious. ....................................................................57
`
`1. Chowdhuri Does not Disclose “Data Groups.” .....................................57
`
`2. Chowdhuri Does not Disclose Delineating “Data Groups” Prior to
`Partitioning. ............................................................................................61
`
`3. Chowdhuri Does not Disclose “Providing Each Data Partition to a
`Selected One of a Plurality of Mapping Functions.” .............................62
`
`4. Chowdhuri Does not Disclose “Intermediate Data” that Is “Identifiable”
`to a “Data Group.” .................................................................................63
`
`5. Chowdhuri Does not Disclose “Data Groups” with Different
`Schemas. ................................................................................................66
`
`Patent Owner’s Preliminary Response
`
`
`
`iii
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 5 of 79 PageID #:
`4618
`
`6. Chowdhuri Does not Disclose a Key in Common Between the (1)
`“Data Groups”/Schema of the Input Data, and (2) the Intermediate
`Data. .......................................................................................................67
`
`7. Chowdhuri Does not Disclose Processing Intermediate Data
`According to its “Data Group,” or Merging the Intermediate Data
`Based on a Key in Common Between the Intermediate Data and the
`“Data Groups.” .......................................................................................68
`
`
`
`
`
`
`IX. CONCLUSION ..............................................................................................69
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Patent Owner’s Preliminary Response
`
`
`
`iv
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 6 of 79 PageID #:
`4619
`
`TABLE OF AUTHORITIES
`
`
`Cases
`
`Advanced Bionics, LLC v. Med-El Elektromedizinische Geräte GmbH,
` IPR2019-01469 (PTAB Feb. 13, 2020) ........................................................ passim
`
`American Airlines, Inc. et al. v. R2 Solutions LLC,
` IPR2023-00689 (PTAB Mar. 7, 2023) .................................................................35
`
`CFMT, Inc. v. YieldUp Int’l Corp.,
` 349 F.3d 1333 (Fed. Cir. 2003) ............................................................................20
`
`Garmin Int’l, Inc. v. Patent of Cuozzo Speed Techs. LLC,
` Case No. IPR2012-00001, Paper 15 (PTAB Jan. 9, 2013) ...................................20
`
`Graham v. John Deere Co.,
` 383 U.S. 1 (1966) ..................................................................................................19
`
`In re Kahn,
` 441 F.3d 977 (Fed. Cir. 2006) ..............................................................................21
`
`In re Rijckaert,
` 9 F.3d 1531 (Fed. Cir. 1993) ................................................................................20
`
`In re Royka,
` 490 F.2d 981 (C.C.P.A. 1974) ..............................................................................20
`
`InTouch Techs., Inc. v. VGo Comm’ns., Inc.,
` 751 F.3d 1327 (Fed. Cir. 2014) ............................................................................20
`
`KSR Int’l Co. v. Teleflex Inc.,
` 550 U.S. 398 (2007) ................................................................................. 20, 21, 67
`
`LG Elecs., Inc. v. Cellular Commc’ns Equip. LLC,
` Case No. IPR2016-00197, Paper 7 (PTAB April 29, 2016) ......................... 21, 68
`
`N.V. v. Abbott Labs.,
` 512 F.3d 1363 (Fed. Cir. 2008) ............................................................................21
`
`
`
`
`Patent Owner’s Preliminary Response
`
`
`
`v
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 7 of 79 PageID #:
`4620
`
`Rules, Regulations, and Statutes
`
`35 U.S.C. § 103 ........................................................................................................19
`
`35 U.S.C. § 103(a) ...................................................................................................19
`
`35 U.S.C. § 316(e) ...................................................................................................19
`
`35 U.S.C. § 325(d) ........................................................................................ 1, 28, 35
`
`37 C.F.R. § 42.108(c) ...............................................................................................19
`
`Other Authorities
`
`PTAB Consolidated Trial Practice Guide (Nov. 2019) ...........................................19
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Patent Owner’s Preliminary Response
`
`
`
`vi
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 8 of 79 PageID #:
`4621
`
`Exhibit
`
`2001
`
`
`2002
`
`
`2003
`
`
`2004
`
`
`2005
`
`
`2006
`
`
`2007
`
`
`2008
`
`
`2009
`
`PATENT OWNER’S EXHIBIT LIST
`
`Description
`
`
`[RESERVED]
`
`
`Fundamentals of MapReduce
`
`
`MapReduce Design Patterns
`
`
`[RESERVED]
`
`
`Google’s MapReduce patent – what does it mean for Hadoop?
`
`
`Information Disclosure Statement
`
`
`US6341289
`
`
`US20060117036A1
`
`
`“Hash join in MySQL 8,” available at https://dev.mysql.com/blog-
`archive/hash-join-in-mysql-8/.
`
`
`Patent Owner’s Preliminary Response
`
`
`
`vii
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 9 of 79 PageID #:
`4622
`
`I.
`
`INTRODUCTION1
`
`The Petition should be denied under 35 U.S.C. § 325(d). The Petition presents
`
`substantially the same art and arguments that were already before the USPTO during
`
`prosecution of the ’610 patent. Thus, under Advanced Bionics, it was incumbent on
`
`Petitioner to demonstrate how the USPTO erred in a way material to patentability.
`
`See Advanced Bionics, LLC v. Med-El Elektromedizinische Geräte GmbH,
`
`IPR2019-01469, Paper 6 at 7 (PTAB Feb. 13, 2020) (precedential). But the Petition
`
`is silent as to any alleged error committed by the USPTO. The Board should thus
`
`exercise its discretion under § 325(d) and deny institution.
`
`The Petition should also be denied under 35 U.S.C. § 314(a) because it fails
`
`to establish a reasonable likelihood that the Board would find any of the challenged
`
`claims unpatentable. The ’610 patent claims novel and non-obvious enhancements
`
`to MapReduce architecture that are nowhere to be found in the prior art and would
`
`not be obvious to a POSITA. Each of the Petition’s grounds have glaring holes,
`
`
`
` Databricks represented that the Petition “raises grounds of unpatentability
`
` 1
`
`identical to those already raised in IPR2024-00303.” Petition at 1. Patent Owner’s
`
`arguments here are thus identical to those found in the Preliminary Response filed
`
`in IPR2024-00303.
`
`Patent Owner’s Preliminary Response
`
`
`
`
`1
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 10 of 79 PageID #:
`4623
`
`neither of the cited references teach or suggest key limitations of the challenged
`
`claims, and the combination of the references is self-evidently inoperable.
`
`II. BACKGROUND
`
`
`A. Overview of the ’610 Patent
`
`
`
`The ’610 patent, granted to Yahoo!, claims a novel MapReduce architecture
`
`that can be applied to affect mapping and reducing across data sets comprising data
`
`of different schema. Such architecture, adapted to receive and process data from
`
`heterogenous sources, greatly expanded the applicability of MapReduce to
`
`dramatically improve big data analytics. This improvement was significant at the
`
`time of the ’610 patent (and remains significant today), enhancing the overall
`
`capabilities of computer functionality as it relates to distributed database processing.
`
`
`
`1. Introduction to MapReduce
`
`As laid out in the ’610 specification, the concept of MapReduce consists of a
`
`“‘map’ function [that] maps key-value pairs to new (intermediate) key-value pairs,”
`
`and a “‘reduce’ function [that] represents all mapped (intermediate) key-value pairs
`
`sharing the same key to a single key-value pair or a list of values.” ’610 patent at
`
`1:17-20. At its core, “MapReduce implementations enable the use of massive
`
`Patent Owner’s Preliminary Response
`
`
`
`
`2
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 11 of 79 PageID #:
`4624
`
`clusters of commodity computers to provide a simplified programming and
`
`execution model for processing large sets of data in parallel.” Id. at 9-12.
`
`In a simple example found in U.S. Patent No. 7,590,620 to Pike (“Pike,”
`
`Petitioner’s primary reference), MapReduce can be used to “count[] the number of
`
`occurrences of each distinct word in a large collection of documents.” Ex. 1002 at
`
`10:36-39. In this example, the map function “outputs a key/value pair for every word
`
`w in every document in the collection, where the key/value pair is <w, 1>.” Id. at
`
`10:40-43. It is likely that with a voluminous number of documents, each map
`
`function “will produce hundreds or thousands of records of the form <word, 1>.” Id.
`
`at 10:51-52. After the mapping phase, the reduce functions “sort the intermediate
`
`data values, merge or otherwise combine sorted intermediate data values having the
`
`Patent Owner’s Preliminary Response
`
`
`
`
`3
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 12 of 79 PageID #:
`4625
`
`same key.” Id. at 8:16-19. In this example, the effect is that “[t]he Reduce function
`
`simply adds up the count values.” Id. at 10:52-53.
`
`The below graphic illustrates the word count example discussed in Pike:
`
`
`
`Ex. 2002 at 5. In this example, the input data consists of a collection of words (Deer,
`
`Bear, River, and Car). Applying traditional MapReduce in the “Splitting” step, the
`
`input data is split to be supplied to different map processes. Next, in the “Mapping”
`
`step, each map function creates lists of key-value pairs. A key-value pair works much
`
`like a dictionary—the words are the “keys,” and the definitions are the “values.” In
`
`the example above, each mapping function generates a list of key-value pairs where
`
`the words are the “keys” and the values are “1” to indicate that each word, as a
`
`discrete item, occurs one time (e.g., “Deer, 1”). See Ex. 1002 at 10:40-43. Obviously,
`
`some of the words occur multiple times, and that is accounted for later in the process.
`
`At the “Shuffling” step, all key-value pairs having the same key are grouped together
`
`to ensure that pairs with the same key are submitted to the same reducers. At the
`
`Patent Owner’s Preliminary Response
`
`
`
`
`4
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 13 of 79 PageID #:
`4626
`
`“Reducing” step, the reducers determine how many occurrences of that particular
`
`key exist for the received data and can generate another key-value pair, accordingly.
`
`See id. at 8:16-19. Ultimately, the output in this example is a list of all of the key-
`
`value pairs from each reducer that represents the number of times the word appears
`
`in the input text (e.g., “Deer, 2” indicating that the word “Deer” appeared twice).
`
`See id. at 10:52-53; 8:16-19.
`
`MapReduce can also be used to accomplish other tasks, such as “joins” or
`
`“merges” of data or lists that already exist as key/value pairs. See id. at 9:65-66 (“The
`
`input data blocks . . . may in some embodiments be treated as key/value pairs . . .”).
`
`The below graphic illustrates such a merger:
`
`Ex. 2003 at 8.
`
`Patent Owner’s Preliminary Response
`
`
`
`
`
`
`5
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 14 of 79 PageID #:
`4627
`
`Here, the input data is already provided as a list of key-value pairs. In this
`
`example, the input data is a list of features in a graph (e.g., roads and intersections)
`
`that are numbered; the numbers are the keys and the feature types are the values. In
`
`the mapping phase, new keys are assigned that correspond to the intersection that
`
`the particular feature participates in (e.g., roads 1, 2, and 5, and intersection 3, all are
`
`involved with intersection 3). See Ex. 1002 at 7:29-43. Thus, in this example, the
`
`key generated in the mapping phase is the intersection ID, and the value is the key-
`
`value pair corresponding to the graph feature. The values are shuffled and passed to
`
`the reducers based on their common key. See id. at 8:16-19. Then, the reducers
`
`“reduce” the data to yield the output data, i.e., the reducers can consolidate all of the
`
`features pertaining to a particular common key, such that all of the features
`
`participating in intersection 3 fall with intersection 3, and all of the features
`
`participating in intersection 6 fall with intersection 6. See id.
`
`As is apparent from the above examples, MapReduce offers a way to take
`
`large, unwieldy datasets and extract quantifiable and useful
`
`information
`
`algorithmically. As discussed in the ’610 patent, however, in 2006, MapReduce had
`
`significant limitations that restricted its usefulness.
`
`2. Shortcomings of Prior Technologies
`
`The ’610 patent discloses shortcomings in the prior art and then explains, in
`
`detail, the technical way the claimed inventions resolve or overcome those
`
`Patent Owner’s Preliminary Response
`
`
`
`
`6
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 15 of 79 PageID #:
`4628
`
`shortcomings. The specification discusses
`
`that “conventional MapReduce
`
`implementations do not have facility to efficiently process data from heterogeneous
`
`sources” and that “it is impractical to perform joins over two relational tables that
`
`have different schemas.” ’610 patent at 3:9-20. “Schema” can refer to, e.g., “fields”
`
`in a particular collection of data. For example, in Figure 3 of the ’610 patent, the
`
`“All Emp” table (302) and “All Dept” table (304) have different “schema” because
`
`the “All Emp” table has the fields “DeptID” and “EmpName,” while the “All Dept”
`
`table has the fields “DeptID” and “DeptName”:
`
`
`
`Id. at FIG. 3; 3:19-20.
`
`The specification explains that traditional MapReduce cannot efficiently join
`
`the “All Emp” table (302) and “All Dept” table (304) to achieve the “All Emp and
`
`Patent Owner’s Preliminary Response
`
`
`
`
`7
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 16 of 79 PageID #:
`4629
`
`Dept” table (306). For example, the below graphic demonstrates how traditional
`
`MapReduce would process the “All Emp” and “All Dept” tables:
`
`
`
`In this example, the “key” for the mapping phase is the “DeptID” (which,
`
`mirroring the merger example in Ex. 2003, is a field that each entry shares or
`
`participates in) followed by a value of “DeptID, EmpName” or “DeptID,
`
`DeptName” (again, mirroring the merger example above). As can be seen here, even
`
`though there is a key-in-common amongst the “All Emp” and “All Dept” data sets
`
`at the input, there is no joining of the data in any usable way. Instead, the output is
`
`a collection of jumbled lists that show both employee names and department names
`
`for a single key instead of indicating, e.g., DeptID, employee name, and the
`
`associated department name. For instance, the output list for key 34 in this example
`
`contains “Clerical” (a department name) mixed with “Smith,” “Robinson,” and
`
`“Jasper” (employee names)—there is no merger of the two tables to reflect, e.g., “34,
`Patent Owner’s Preliminary Response
`8
`
`
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 17 of 79 PageID #:
`4630
`
`Smith, Clerical.” As datasets get bigger and more complex, this problem would only
`
`be compounded.
`
`
`
`3. Improvement to MapReduce Described by ’610 Patent.
`
`The ’610 patent offers an improvement over traditional MapReduce through
`
`the use of “data groups.” The specification summarizes this enhancement:
`
`In accordance with an aspect, an input data set is treated as a
`plurality of grouped sets of key/value pairs, which enhances the utility
`of
`the MapReduce programming methodology. Utilizing such
`grouping, map processing is carried out independently on two or more
`related datasets (e.g., related by each being characterized by a schema
`with a key in common). The intermediate results of the map processing
`(key/value pairs) for a particular key are processed together in a single
`reduce function by applying a different iterator to intermediate values
`for each group. Different iterators can be composed inside reduce
`functions in ways however desired.
`Thus, for example, the enhanced MapReduce programming
`methodology may be easily employed to carry out distributed relational
`database processing.
`
`’610 patent at 1:31-44.
`
`The specification goes on to explain how implementation of “data groups,”
`
`realizes these improvements:
`
`In general, partitioning the data sets into data groups enables a
`mechanism to associate (group) identifiers with data sets, map
`
`Patent Owner’s Preliminary Response
`
`
`
`
`9
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 18 of 79 PageID #:
`4631
`
`functions and iterators (useable within reduce functions to access
`intermediate data) and, also, to produce output data sets with (group)
`identifiers. It is noted that the output group identifiers may differ from
`the input/intermediate group identifiers.
`
`Id. at 3:58-64.
`
`The ’610 patent provides a helpful schematic that illustrates how the “data
`
`groups” improve MapReduce:
`
`Id. at FIG. 5 (annotated).
`
`In the above schematic, the input data in portion 502 consists of the Employee
`
`table 302 and the Department table 304 from Figure 3, which share a common key
`Patent Owner’s Preliminary Response
`10
`
`
`
`
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 19 of 79 PageID #:
`4632
`
`(i.e., DeptID). See id. at 8:15-24. Each of these “data groups” include a “mechanism
`
`for identifying data from that group”2 that is depicted as following the data through
`
`the mapping phase 504 and into the reducing phase 510 (i.e., “Emp” and “Dept”
`
`emphasized in green). As shown here, the data of each of the “data groups” are
`
`partitioned into a “plurality of data partitions” in between portions 502 and 504, and
`
`each partition is provided to a “selected one of a plurality of mapping functions” in
`
`portion 504. The mapping functions form “intermediate data” at portion 506, and the
`
`“intermediate data” is shown as being “identifiable” to its parent “data group” via
`
`the “Emp” and “Dept” mechanisms. The “intermediate data” also shares the
`
`common key (DeptID) with the two “data groups.” After sorting in portion 508,
`
`“intermediate data” corresponding to each “data group” is provided to “reduce
`
`functions within the portion 510.” Id. at 8:34-37. By “processing the intermediate
`
`data for each data group in a manner that is defined to correspond to that data group”
`
`in the reducing phase, portion 512 depicts data that is “a merging of the
`
`
`
` As discussed in more detail below, the Eastern District of Texas construed the term
`
` 2
`
`“data group” to mean “a group of data and a mechanism for identifying data from
`
`that group.” Petitioner purports to apply this construction. See Petition at 10. The
`
`Board should likewise adopt that construction.
`
`Patent Owner’s Preliminary Response
`
`
`
`
`11
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 20 of 79 PageID #:
`4633
`
`corresponding different intermediate data based on the key in common” (i.e., table
`
`306 in Figure 3).
`
`Thus, the ’610 patent provides a clear technological improvement to existing
`
`MapReduce systems via a novel MapReduce architecture where mapping and
`
`reducing functions can be applied to data from heterogeneous data sources (i.e., data
`
`sources having different schema) to accomplish the merger of heterogeneous data
`
`based on a key in common among the heterogeneous data. The specification goes so
`
`far as to provide specific examples of how a “data group”-oriented MapReduce
`
`architecture can be deployed in programming. The ’610 patent shows, for example,
`
`that a “data group” identifier can be passed as a parameter to a mapping function and
`
`thereby travel through to the resulting intermediate data, followed by a reduce
`
`function that employs the “data group” identifier to call particular programming
`
`objects (e.g., iterators) associated with specific “data groups”:
`
`
`
`
`
`Id. at 6:29-33, 39-48. Figures 3-5 illustrate a similar embodiment. In this
`
`embodiment, the “data group” identifier (annotated in red) is indicated to the
`
`Patent Owner’s Preliminary Response
`
`
`
`
`12
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 21 of 79 PageID #:
`4634
`
`mapping and/or reduce functions, such that different “data groups” can be mapped
`
`differently and/or processed in a way that corresponds to a particular “data group”:
`
`
`
`Id. at 7:45, 55, 64-65.
`
`4. The Claimed Technology of the ’610 Patent Improves
`MapReduce.
`
`The independent claims of the ’610 patent claim the improved MapReduce
`
`
`
`architecture outlined in the specification. A crucial feature is the implementation of
`
`what is referred to as a “data group.” As explained above, by utilizing “data groups,”
`
`a data set with data of different schema can be fed to a collection of mapping
`
`functions to ultimately be reduced and/or merged because the “mechanism for
`
`identifying data from that group” (which is part of the “data group”) follows the data
`
`through the mapping phase and into the reducing phase. Thus, the MapReduce
`
`architecture can use specialized processing based on the “data group” from which
`
`the data being reduced originated. These claimed features enable the MapReduce
`
`architecture in the reducing phase to accomplish the merger of intermediate data
`
`hailing from different data groups.
`
`For example, Claim 1 describes that “data groups,” each with a different
`
`schema, are partitioned, and the resulting partitions are provided to “a selected one
`Patent Owner’s Preliminary Response
`13
`
`
`
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 22 of 79 PageID #:
`4635
`
`of a plurality of mapping functions” such that “the data of the first data group is
`
`mapped differently than the data of the second data group.” Ex. 1026 at 1. This
`
`requires that the architecture differentiates between “data groups” at the mapping
`
`phase to obtain “intermediate data” on a per-“data group” basis, which avoids
`
`jumbling of data having different schemas into the same map and thus eliminating
`
`the usefulness of the reducing phase. After partitions of each of the “data groups”
`
`are provided to selected mapping functions, the claim describes that the mapping
`
`functions output “intermediate data” for a particular “data group” and that the
`
`“different schema [of the data groups] and corresponding different intermediate data
`
`have a key in common.” Id. This “key in common” requirement is necessary,
`
`because it ultimately serves as the key on which the data of the “data groups” is
`
`merged in the reducing phase.
`
`Claim 1 further requires that the “intermediate data” be “identifiable” to its
`
`parent “data group” (i.e., via the “mechanism for identifying data from that [data]
`
`group”). Id. As revealed later in the claim, the MapReduce architecture “process[es]
`
`the intermediate data for each data group in a manner that is defined to correspond
`
`to that data group, so as to result in a merging of the corresponding different
`
`intermediate data based on the key in common.” Id. In other words, the reduce
`
`functions recognize that received “intermediate data” stems from particular “data
`
`groups,” and can therefore employ processing that corresponds to each “data group”
`
`Patent Owner’s Preliminary Response
`
`
`
`
`14
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 23 of 79 PageID #:
`4636
`
`to accomplish a combined reducing phase that merges the data (each with a different
`
`schema) together. The specification provides helpful context regarding this step,
`
`disclosing that, in one embodiment, the reducing phase can employ “data group”-
`
`specific iterators to accomplish merger, and this is only possible because of the
`
`improved MapReduce architecture’s implementation of “data groups.” See, e.g.,
`
`’610 patent at 6:35-7:23. Without “intermediate data” that is identifiable to a
`
`particular “data group,” Claim 1’s MapReduce architecture would not be able to
`
`distinguish one type of “intermediate data” from another, which would (in one
`
`example) lead to the useless amalgamation of data discussed in Section II.A.2 above.
`
`Hence, the claimed features describe a MapReduce architecture that accounts
`
`for different “data group” schema to accomplish a reduction and merger of data
`
`having different schema. As explained in the specification, such task was ineffective
`
`using traditional MapReduce architectures. Id. at 3:9-20
`
`III. LEVEL OF ORDINARY SKILL
`
`
`For the limited purpose of this Preliminary Response, Patent Owner does not
`
`contest Petitioner’s definition of a person of ordinary skill in the art, but it reserves
`
`the right to do so in the event that trial is instituted.
`
`
`
`IV. CLAIM CONSTRUCTION
`
`
`Patent Owner’s Preliminary Response
`
`
`
`
`15
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 24 of 79 PageID #:
`4637
`
`The Eastern District of Texas has twice construed terms of the ’610 patent,
`
`ordering the following constructions (see Ex. 1007 at 13-31; Ex. 1008 at 8-19):
`
`Term/Phrase
`
`Agreed Construction
`
`“a plurality of mapping functions
`that are each user-configurable”
`
`“two or more mapping functions that are each
`configurable by a user”
`
`“data group”
`
`“a group of data and a mechanism for
`identifying data from that group”
`
`“a method of processing data of a
`data set over a distributed system,
`wherein the data set comprises a
`plurality of data groups,
`the
`method comprising”
`
`Limiting preamble in Claim 1
`
`“identifiable
`group”
`
`to
`
`[that/the] data
`
`plain meaning
`
`“independently output a plurality
`of lists of values”
`
`plain meaning
`
`Patent Owner’s Preliminary Response
`
`
`
`
`16
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 25 of 79 PageID #:
`4638
`
`“the data of the first data group is
`mapped differently than the data of
`the second data group”
`
`plain meaning
`
`“data set”
`
`plain meaning
`
`“data partition”
`
`plain meaning
`
`plain meaning
`
`“including processing the
`intermediate data for each data
`group in a manner that is defined
`to correspond to that data group,
`so as to result in a merging of the
`corresponding different
`intermediate data based on the key
`in common”
`
`“the at least one output data group
`is a plurality of output data groups”
`
`plain meaning
`
`
`
`R2 and Databricks have not yet engaged in claim construction proceedings in
`
`their dispute in the Eastern District of Texas.
`
`For the purposes of this Preliminary Response, Patent Owner submits that the
`
`Patent Owner’s Preliminary Response
`
`
`
`
`17
`
`

`

`Case 4:23-cv-01147-ALM Document 62-13 Filed 11/12/24 Page 26 of 79 PageID #:
`4639
`
`Board should adopt and apply the Eastern District of Texas’s construction of “data
`
`group” as “a group of data and a mechanism for identifying data from that group.”
`
`Petitioner itself purports to apply this construction.3 See Petition at 10. And this
`
`construction of “data groups” is proper in light of the patent itself. As explained by
`
`the court, the specification discloses that partitioning data “into data groups enables
`
`a mechanism to associate (group) identifiers” with the data (’610 patent at 3:58-59),
`
`and thus, “the word ‘group’ inherently implies some mechanism to identify the
`
`group. . . . Finding otherwise would potentially leave the scope of ‘data group’
`
`amorphous, and some construction of the disputed claim language will assist” in
`
`understanding the claims. Ex. 1007 at 24-25 (internal citations omitted). The Board
`
`should accordingly construe “data group” to mean “a group of data and a mechanism
`
`for identifying data from that group.”
`
`
`V. APPLICABLE LEGAL STANDARDS
`
`
`The Board may only grant a petition for inter partes review where “the
`
`information presented in the petition … sho