Responsive briefs are almost always more interesting than the initial briefs because you gain some insight into the weakness or strength of a party's arguments by the ability of the opposing party to poke holes in that argument. That is certainly the case with respect to the responsive briefs filed by the parties in this case on the subject of the JMOL motions.
You have to love it when a quote from "Through the Looking Glass" shows up in a brief. In this instance it is Google's sole response to Oracle's suggestion that "[a] reasonable jury could only find that Google did not infinge the asserted claims of the 104 patent" by quoting:
As was evident in the original briefs, Oracle is now trying to recast the definitions of two phrases that were settled in the claims construction phase of this litigation: "symbolic references" and "simulated execution." Why is this important? Because accepting the Court's definitions doesn't fit Oracle's infringement claims. Google is having none of that. (1169 [PDF; Text]) Google argues that Oracle cannot now bootstrap a numeric reference into being a symbolic reference, nor should Oracle now be permitted to assert that pattern matching is a form of simulated execution under the doctrine of equivalents.
Oracle's response is that Google is misinterpreting or misrepresenting Oracle's infringement arguments. (1170 [PDF; Text]) They support this position, in part, on Dr. Mitchell's testimony at deposition that his report contained the same typo three times in which he appeared to accept the Court's definition of symbolic references, and that the typo did not represent what he meant. One could understand a mistake made once or even possibly twice, but three times?! How convenient.
Oracle does effectively go after Google's assertion that free distribution does not escape a claim of infringement because it is neither selling nor using. This language from the Thorn case, as Oracle suggests, appears right on point:
business, a person delivered free samples to all of the patentee’s potential
Less persuasive is Oracle's argument on willfulness. Almost all the evidence that Oracle has provided arose after the suit was filed or, if of an earlier date, was so non-specific as to not support a claim. Oracle would have us believe that Google's simple awareness of Sun's patent portfolio, not a specific assertion of infringement, was enough to put Google on notice that it was infringing, and the fact that Google ignored that non-specific "warning" for years shows that Google was willful in its infringement. Google's awareness must have been so acute and perceptive as to create knowledge of a high risk of infringement early on, despite the fact that we are now dealing with a half dozen claims from two patents out of thousands held by Sun and Google has at least a prima facie argument that it does not infringe. That certainly seems like a stretch.
Of course, whether any of this ultimately matters depends, in part, on whether the jury is able to reach a unanimous decision on the questions before it. The big items left on the trial agenda: the jury's decision on patent infringement; the Court's determination of the copyrightability of API's, and possibly damages. And even with that, this case may need a return appearance on the Court's docket if the judge decides API's are protected by copyright since that will raise a new issue for a jury and the stipulation entered yesterday states that will be a new jury, not the present one.
05/17/2012 - 1169 -
RESPONSE (re 1168 Amended MOTION for Judgment as a Matter of Law ORACLE
AMERICA, INC.S RULE 50(A) MOTION AT THE CLOSE OF ALL EVIDENCE FOR PHASE
II (PATENT PHASE)--REPLACES [DKT 1167] ) filed byGoogle Inc.. (Van Nest,
Robert) (Filed on 5/17/2012) (Entered: 05/17/2012)
05/17/2012 - 1170 -
RESPONSE (re 1151 MOTION for Judgment as a Matter of Law on Counts V and
VII of Oracle's Amended Complaint ) filed byOracle America, Inc..
(Jacobs, Michael) (Filed on 5/17/2012) (Entered: 05/17/2012)
KEKER & VAN NEST LLP
ROBERT A. VAN NEST - # 84065
CHRISTA M. ANDERSON - # 184325
DANIEL PURCELL - # 191424
[email address telephone fax]
KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
ROBERT F. PERRY
BRUCE W. BABER (Pro Hac Vice)
[address telephone fax]
KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
CHERYL A. SABNIS - #224323
[email address telephone fax]
IAN C. BALLON - #141819
HEATHER MEEKER - #172148
GREENBERG TRAURIG, LLP
[address telephone fax]
Attorneys for Defendant
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
ORACLE AMERICA, INC.,
Case No. 3:10-cv-03561 WHA
GOOGLE INC.’S OPPOSITION TO
ORACLE AMERICA, INC.’S RULE 50(A)
MOTION AT THE CLOSE OF ALL
EVIDENCE FOR PHASE II
Dept.: Courtroom 8, 19th Floor
Judge: Hon. William Alsup
TABLE OF CONTENTS
|II.||A REASONABLE JURY COULD ONLY FIND THAT GOOGLE DID NOT|
INFRINGE THE ASSERTED CLAIMS OF THE 104 PATENT
|A.||Dalvik bytecode instructions only contain indexes, which are not|
“symbolic references” because they refer to numeric memory locations
|1.||Field indexes are not symbolic references||3|
|2.||The Court’s claim construction applies to data in the constant pool|
tables as well as the actual field data in an instance object
|3.||Indexes are not symbolic references because they are not resolved||8|
|B.||Dexopt does not infringe the ’104 patent||9|
|C.||The Court should reject Oracle’s post-trial attempt to re-construe the term|
|III.||A REASONABLE JURY COULD ONLY FIND THAT GOOGLE DOES NOT|
INFRINGE THE ASSERTED CLAIMS OF THE ’520 PATENT
|A.||The jury is entitled to credit Professor Parr’s testimony explaining why|
pattern matching differs from simulating execution
|B.||Simulating execution, properly understood, involves the simulation of|
actual Java virtual machine operations
|IV.||ORACLE’S PATENT INFRINGEMENT CLAIMS ARE BARRED BY|
GOOGLE’S EQUITABLE DEFENSES
|A.||Oracle’s “additional facts” are contradicted by the evidence||15|
|B.||Oracle’s patent infringement claims are barred by equitable estoppel||16|
|C.||Oracle’s patent infringement claims are barred by laches||16|
|D.||Oracle’s patent infringement claims are barred by waiver||17|
|E.||Oracle’s patent infringement claims are barred by implied license||18|
|V.||GOOGLE CHOSE NOT TO PRESENT ITS DEFENSES OF PATENT MISUSE,|
USE BY THE UNITED STATES, UNCLEAN HANDS, AND EXPRESS
LICENSE, AND THEREFORE DOES NOT OPPOSE ORACLE’S MOTION ON
TABLE OF AUTHORITIES
|A.C. Aukerman Co. v. R.L. Chaides Const. Co.|
960 F.2d 1020 (Fed. Cir. 1992)
|De Forest Radio Tel. Co. v. United States|
273 U.S. 236 (1927)
|Eon-Net LP v. Flagstar Bancorp|
653 F.3d 1314 (Fed. Cir. 2011)
|In re Katz Interactive Call Processing Patent Litigation|
712 F. Supp. 2d 1080 (C.D. Cal. 2010)
|Lucent Technologies, Inc. v. Gateway, Inc.|
580 F. Supp. 2d 1016 (S.D. Cal. 2008) aff'd in part, vacated in part, remanded,
580 F.3d 1301 (Fed. Cir. 2009)
|McCoy v. Mitsuboshi Cutlery, Inc.|
67 F.3d 917 (Fed. Cir. 1995)
|Wang Laboratories, Inc. v. Mitsubishi Electronics Am., Inc.|
103 F.3d 1571 (Fed. Cir. 1997)
The Court should deny Oracle’s motion for judgment as a matter of law. Under the
Court’s claim construction, no reasonable jury could find that Android infringes Claims 11, 27,
29, 39, 40, and 41 of U.S. Patent No. RE38,104 (the ’104 patent). The construction of “symbolic
references” does not, as Oracle suggests, limit the term “data” to “the actual field data in an
instance object.” Moreover, the terms “dynamically” and “statically” do not take on the tortured
meanings Oracle now ascribes to them in yet another attempt to modify the Court’s claim
Likewise, Oracle’s request for judgment as a matter of law that Google infringes the ’520
patent is based on no more than the view of Oracle’s counsel as to its desired claim construction
for the term “simulating execution.” Yet neither Oracle’s own expert, nor even Oracle itself in its
brief, focuses on the actual claim language at issue. Oracle is also incorrect that the disputed
claim language necessarily encompasses pattern matching. As Google explained at trial, a pattern
matcher will produce outcomes different than what results from simulating execution, and
Google’s dx tool proves the point, as it does not return identical results when it is applied to
bytecode that would be indistinguishable for purposes of simulating execution. As explained in
Google’s own motion for judgment as a matter of law, Oracle’s current theory is in essence a
belated doctrine of equivalents argument. It should be rejected.
Oracle’s motion as to Google’s equitable defenses also fails. The evidence at trial
established that Sun publicly and privately applauded Android for years. From the time of Mr.
Schwartz’s blog post in 2007 through Mr. Ellison’s efforts to form an Oracle-Google partnership
in 2010, Sun (and later Oracle) never once raised the issue of alleged patent infringement. The
fact that, during that time, Sun still desired to work with Google and hoped to convince Google to
buy a TCK license does not undermine Google’s equitable defenses because the parties never
discussed any patents, let alone a license for the patents-in-suit. To the contrary, Sun actively
encouraged Google and even built products to run on Android. During this time, Google invested
money, time, and resources in developing Android and bringing a smart phone to market. This
undisputed evidence is more than sufficient to grant judgment in Google’s favor on its affirmative
defenses of equitable estoppel, laches, waiver, and implied license.
For all of these reasons, Oracle’s motion should be denied.
II. A reasonable jury could only find that Google did not infringe the asserted claims of
the 104 patent.
TX 2564 at 5/852 (“The Java Language Specification”).
A. Dalvik bytecode instructions only contain indexes, which are not “symbolic
Oracle’s theory has morphed yet again. In his opening report, Dr. Mitchell called the
indexes in the Dalvik bytecode instructions “numeric references,” acknowledging the undisputed
fact that they identify locations in constant pool tables. Then, in his trial testimony, Dr. Mitchell
called the indexes symbolic references, claiming that those indexes are names. Now, in its
motion, Oracle argues that indexes qualify as both numeric and symbolic references. This
schizophrenic theory permeates its motion for judgment as a matter of law:
references” because they refer to numeric memory locations.
- “A field index—also called field@CCCC generally or ‘01’ in specific examples of
field indices in the trial testimony—is a reference to data to be obtained in
accordance with a corresponding numerical reference, and identifies that data by a
name other than the numeric memory location of the data.” [Oracle Mot. for
JMOL at 2.]
- “For the field index in the IGET instruction to be a symbolic reference, it is
enough that it identifies—‘specifies,’ in Mr. McFadden’s words—some data to be
obtained, by something other than the data’s location.” (Id. at 3.)
- “That indexes such as the ‘01’ in ‘52 01’ (the bytecode for IGET field@0001) may
also indicate the location of information in the dex file’s constant pool is not
relevant. The claims do not require that a reference exclusively identify data
symbolically to qualify as a symbolic reference.” ( Id. at 4.)
- “Thus, even if a field index were a numeric memory location in the Field ID table,
it would still nevertheless be a symbolic reference, because it also identifies the
As discussed below, not only should these new—and illogical—theories be rejected as a matter of
law, they highlight the fact that the indexes in Dalvik bytecode instructions are indeed numeric
rather than symbolic references. Accordingly, judgment as a matter of law should be entered in
favor of Google, not Oracle.
value of a field in an instance object—the only data that is relevant to the claims—
by a name other than its location.” ( Id. at 6.)
There is no dispute that Dalvik bytecode instructions—the instructions evaluated by both
Resolve.c and the dexopt tool—consist of an opcode and operand. [TX 737 (“Each instruction
starts with the named opcode and is optionally followed by one or more arguments.”); RT
3221:8-10, 3234:4-7 (McFadden); RT 3590:23-3591:25 (Bornstein); RT 3844:14-3855:12,
3925:4-18 (August).] Nor is there any dispute that the accused operands are indexes that take the
form “field@CCCC” and reference locations in tables. [See Oracle Mot. for JMOL at 2-3; TX
46.106; TX 735 (“There are separately enumerated and indexed constant pools for references to
strings, types, fields, and methods.”); TX 737; RT 3732:15-19, 3736:16-23, 3755:8-9, 3765:9-12
(McFadden); 3858:5-12, 3858:21-359:11, 3918:13-23, 3923:20-24, 3925:19-3926-9 (August).]
Even Dr. Mitchell agrees. [RT 3488:6-8, 3488:19-23, 3489:10-12 (Dr. Mitchell) (the “classIdx”
index in Dalvik instructions provides information “to a location in another table”); RT 3496:12-
3497:6 (the “field Idx” in Dalvik instructions is “an index to a specific location in the field
table”).] These indexes refer to locations in the constant pool tables, which are data in the .dex
file; for example, “field@0001” refers to the entry 1 in the Field IDs table. [See Oracle Mot. for
JMOL at 4.]
1. Field indexes are not symbolic references.
Oracle focuses its analysis on the IGET instruction in Dalvik bytecode. [See id. at 3.] It
argues that the IGET instruction corresponds to the “LOAD ‘y’” instruction in Figure 1B of the
’104 patent. [Id.] That is the wrong example. As Oracle notes, “[t]he IGET instruction contains
three operands—vA, vB, and field@CCCC—where the third operand field@CCCC is the field
index.” [Id. at 3 (citing TX 735 at 6; RT 3221:8-10 (McFadden)).] That index identifies an entry
in the Field ID table. As such, the IGET instruction in the Dalvik bytecode instructions actually
corresponds to the “LOAD 2” instruction depicted in Figure 1A the ’104 patent.
The instruction, LOAD 2, directs the computer to go to Slot 2 in the table, much like the IGET
instruction 52 01 instructs the computer to go to entry 01 in the Field ID table. Even Oracle
concedes this is how the IGET instruction works. [Id. at 4.] As such, the operands for IGET
instructions in Dalvik bytecode—the indexes—qualify as numeric references rather than
symbolic references. Because those indexes refer to data by a numeric memory location—entry
01 in the Field IDs table—they do not meet the Court’s construction of “symbolic references.”
In light of all the evidence presented at trial, Oracle now concedes that indexes in the
instruction stream indicate the location of information in the constant pool tables, making them
numeric references in at least that respect. “That indexes such as the ‘01’ in ‘52 01’ (the bytecode
for IGET field@0001) may also indicate the location of information in the dex file’s constant
pool is not relevant.” [See Oracle Mot. for JMOL at 4 (emphases removed).] Oracle’s new
argument that this is not relevant, however, is insincere—indeed, the whole issue is whether the
indexes qualify as symbolic or numeric references. Oracle continues, “[t]he claims do not require
that a reference exclusively identify data symbolically to qualify as a symbolic reference.” [Id.]
Along those same lines, Oracle argues that “even if a field index were a numeric memory location
in the Field ID table, it would still nevertheless be a symbolic reference, because it also identifies
the value of a field in an instance object—the only data that is relevant to the claims—by a name
other than its location.” [Id. at 6 (emphasis in original).] This is the first time that Oracle has
posited the idea of “hybrid” numeric-symbolic references, which conflicts with the patent and the
Court’s Claim Construction Order. [See Dkt. No. 137 at 20 (“The ’104 patent teaches two
different types of data references: numeric references and symbolic references.”); see also TX
4015.] And, tellingly, neither Dr. Mitchell nor any other witness testified that indexes could
simultaneously qualify as both numeric and symbolic references. In fact, Oracle cites nothing
from the record evidence in support of those new-found “dual-status” references. They are
simply an after-the-fact argument developed by Oracle’s counsel to try to salvage its case.
Oracle’s tortured re-interpretation of the Court’s claim construction provides no basis for
judgment as a matter of law. As is clear on its face, the Court’s construction distinguishes
between using names to represent data (i.e., symbolic references) and using numeric memory
2. The Court’s claim construction applies to data in the constant pool
tables as well as the actual field data in an instance object.
a reference that identifies data by a name other than the numeric memory location
of the data, and that is resolved dynamically rather than statically
[Dkt. No. 137 at 22.] Dr. Mitchell agrees. [RT 3480:12-15.] There is no limitation regarding the
type of data being referenced.
Regardless, Oracle postulates that “the ‘data’ in the Court’s construction of symbolic
reference is the actual field data ‘obtained’ by Dalvik—the value of a field in an ‘instance
object’—rather than the constant pool information in the Android dex file that is the focus of
Google’s arguments.” [Oracle Mot. for JMOL at 5 (parenthetical with claim construction
omitted); see also RT 4019:3-7 (Mitchell).] This reading is much more restrictive than what the
ordinary meaning of the word “data” implies. According to Dr. Mitchell, the “data” must be the
actual field data in the instance object, as opposed to any data in the .dex file, including the data
in the constant pool tables. [RT 4025:6-21 (Mitchell) (“So in order for that to happen, we have to
find where that actual data is in the object using this symbolic reference. . . .”).] As explained in
Google’s motion for judgment as a matter of law, to turn an index—which is a numeric reference
to a location in a table—into a symbolic reference, Dr. Mitchell must resort to improperly redefining
“symbolic reference” to mean “a reference that identifies the actual field data in the
instance object by a name other than the numeric memory location of the actual field data in the
instance object.” [Google Mot. for JMOL at 3 (emphases indicating Dr. Mitchell’s apparent
changes to Court’s construction).] This does not conform to the Court’s ruling on claim
construction, which simply distinguishes between a reference to data—any data—by a name
rather than location. [See Claim Construction Order (Dkt. No. 137) at 20-22; RT 3480:12-15
Oracle misplaces much emphasis on the fact that the figures in the ’104 patent show that
the symbolic reference refers to data that is “obtained.” [Oracle Mot. for JMOL at 5.] It further
emphasizes that the experts agree that the purpose of the LOAD instruction described in the
patent is to obtain the value from the data object. [Id.] But there are two problems with these
arguments. First, the fact that an instruction loads a particular piece of data does not mean that
the intervening data structures—in the case of Android, the constant pool tables—do not also
qualify as data. It’s all data, as explained by Dr. August on cross-examination. [3955:22-24 (“Q.
Now, just to clean up a few other things. You labeled this ‘data,’ but this is actually the constant
pool; true, sir? A. Constant pool is data.”).] The simple figures of the ’104 patent, which contain
only instructions and the ultimate data object, do not prove otherwise. Put another way, the fact
that Figures 1A, 1B, and 8 in the ’104 patent reflect entries in a “Data Object” does not mean that
other data cannot also meet the construction of “symbolic references.” Indeed, if this is the only
“data” that the claim construction refers to, then every other reference in the system must be
deemed “symbolic.” Then Oracle’s interpretation becomes a self-fulfilling prophecy: by
identifying a single piece of data as “the data” for purposes of the claim construction, Oracle’s
interpretation means that every other piece of data is a symbolic reference. This is simply not
consistent with the patent or the Claim Construction Order. [See TX 4015; Dkt. No. 137 at 20-
Second, as Dr. August explained in his testimony, the actual field data in the instance
object may itself be a reference to other data; for example, another string in the string data table.
Q. What can be in this instance object by way of data?
[RT 4002:14-16; 4003:11-17.] Thus Oracle’s characterization of the value of the actual field data
in the instance object as some form of “ultimate” or “meaningful” data in Android is a false
premise, unsupported by any evidence.
A. Well, it could be a symbolic reference. It could be a numeric
reference. Or it could be other non-reference data.
Q. Let’s talk about in Dalvik. Is the data at these entries always
non-reference data, as we talked about in your technical
A. No, it's not.
Q. How do you know that?
A. Because I write programs. And you can write programs that
contain references in instances of objects.
By claiming that data in the constant pool tables does not count, and that only the value of
the actual field data in an instance object qualifies as the data, Oracle’s motion turns the claim
construction on its head. [Oracle Mot. for JMOL at 6 (“The Field ID table and the other parts of
the dex file constant pool information are not ‘data’ within the meaning of the claims.”).] As
discussed above, Oracle’s new argument would mean that all references in the instruction stream
qualify as symbolic references, because, despite the fact that those references are indexes that
point to the location of data (in constant pool tables), they ultimately lead to the loading of other
data once the symbolic reference—the name in the string table—is determined and thereafter
resolved. This is an illogical reading of the ’104 patent, which clearly provides for an instruction
stream that contains both symbolic and numeric references as separate and distinct elements.
[See, e.g., TX 4015 at Claim 11.]
Oracle contends that field indices are resolved to pointers; therefore, they must be
symbolic references. [Oracle Mot. for JMOL at 7.] Oracle has it backwards. Field indices are
not resolved. As Mr. McFadden explained in the context of discussing Resolve.c:
3. Indexes are not symbolic references because they are not resolved.
Q. And are indexes in this process being resolved?
[RT 3650:18-3651:1.] The record confirms that indexes are numeric rather than symbolic
Q. Why do you say no?
A. Well, resolution implies something is unknown, something is
ambiguous. If you have an index, you know exactly where
you're going. You have the location.
For symbols, you don't know where you're going and you
won’t know until you have resolved the ambiguity. So it
doesn't really make sense to say that you “resolve an index.”
Indexes in Dalvik bytecode instructions always point to the numeric memory location of
data, both before and after resolution of the symbolic references in the .dex file string data. In
Resolve.c, the instruction stream does not change; the index field@CCCC is used both before and
after resolution. It is simply used to look at entries in the Resolved Fields Table and the Field ID
table. [RT 3636:13-3637:20 (McFadden).] In dexopt, although the bytecode instruction operand
is rewritten, it is simply changed from one numeric reference to another numeric reference. [RT
3746:22-3747:14 (McFadden); 3933:5-3934:19 (August).] Specifically, the index value
“field@CCCC” is replaced with another numeric memory location—the offset
“fieldoff@CCCC.” [RT 3746:22-3747:14 (McFadden); 3933:5-3934:19 (August); TX 737 at 3;
TX 46.106 (showing instruction format kFmt22c uses the data at location “field@CCCC” and
instruction format kFmt 22cs uses the data at location “field offset CCCC”); see also TX 737 at 1
(“Suggested static linking formats have an additional ‘s’ suffix, . . . ”).] This is made clear in the
dexopt documentation, which notes that dexopt is simply replacing one location with another:
“For virtual method calls, replace the method index with a vtable index” and “For instance field
get/put, replace the field index with a byte offset.” [TX 739.] In sum, either the index in the
instruction stream stays the same, as in the case of Resolve.c, or it gets rewritten by an index or
offset to another location.
True symbolic references—names in the string table—require real resolution. These types
of references do not tell the computer where to go next; they require a search, i.e., a “resolution.”
[RT 3646:1-23, 3766:18-3767:4 (McFadden); 3848:20-3849:17 (August).] In contrast, indexes
do not require any searching (or “resolving”) because they tell the computer exactly which
location in memory to access next.
THE COURT: The premise being that the certain of said instructions containing
one or more symbolic references.
[RT 3865:11-20 (August).] This is precisely the distinction recognized in the Court’s Claim
Construction Order. [Dkt. No. 137 at 21 (noting that for symbolic references “[t]he claimed
invention would use a dynamic subroutine to interpret this symbolic reference—it would have to
figure out that ‘y’ means ‘17’ or that ‘y’ means ‘the data stored in memory slot 2,’ and then get
the data called y (col. 5:13–19).”).]
And you’re saying that -- well, what is “01”? Is that, in your view, a symbolic
THE WITNESS: No. “01” is a numeric reference because it gives you an actual
numeric memory location. Right here (indicating). This is the location, 01.
There’s no resolution, no search. Nothing – nothing expensive about figuring out
what that instruction is referring to when it goes to the field ID table.
B. Dexopt does not infringe the ’104 patent.
Oracle’s request for judgment as a matter of law on infringement of claims 27 and 29
should also be denied. Oracle’s claim that the Android dexopt tool resolves symbolic references
dynamically rather than statically rests on Dr. Mitchell’s erroneous opinion that an optimization
(e.g., resolution) based on information about a runtime environment is “dynamic.” But there is a
wealth of documentary evidence and fact and expert testimony testimony that proves dexopt is a
static optimization. [RT 3730:16-22 (McFadden); RT 3940:17-20 (August); RT 3595:21-24
(Bornstein); TX 32 at 35, TX 816 at 24:05; TX 735 (defining opcodes that “are reasonable
candidates for static linking”); TX 737 (defining “statically linked” instruction formats); TX 739
(dexopt performs optimizations that “can be inferred statically”).] Meanwhile, Oracle’s reliance
on TX 1094 is specious. As is clear from the document, it was an incomplete cut-and-paste job
from TX 739 (also TX 105). And the copied reference to runtime information, as explained by
Andy McFadden, does not refer to optimization performed by dexopt. [See RT 3734:20-3735:7.]
Accordingly, no reasonable jury could conclude that dexopt infringes claims 27 and 29 of the
C. The Court should reject Oracle’s post-trial attempt to re-construe the term
Oracle seeks judgment as a matter of law on infringement of claims 27 and 29 of the ‘104
patent based on yet another request that the Court’s construction of “symbolic reference” be reconstrued.
[Dkt. 1168 at 9-11 (Section III.C).] This latest attempt to change the meaning of a
claim construction that the parties have relied on for over a year and through the close of evidence
at trial represents Oracle’s third bite. [See Dkt. 132, 1128.] Google has previously explained
why this request should be rejected as both highly prejudicial and as waived by Oracle. [See Dkt.
1134 at 1-2 (incorporated by reference herein).] In addition, there is no basis to conclude, as
Oracle has, that the term “dynamic” is given a special meaning in the ’104 patent. Indeed, the
record at trial proves just the opposite.
For example, Oracle’s expert commended the Court’s construction of “symbolic
reference,” stating that “this is a great, clear statement from the Court about what symbolic
reference means.” [RT 3302:23-3303:1 (Mitchell) (emphasis added).] Dr. Mitchell also testified
that “dynamic” resolution, as used in the Court’s construction of symbolic reference, is resolution
that is done at runtime:
Q. So resolution from -- if there were a symbolic reference that was
resolved to a numeric reference, even if that were so, you would also
need to show that that was done dynamically; correct?
[RT 3502:25-3503:7.] In light of this clear testimony from Oracle’s own expert, Oracle cannot
Q. And you said that that means done at runtime essentially, right?
A. Yes, that’s one way that it can be done dynamically.
now be heard to complain that “dynamic,” as that term is used in the context of the Court’s
definition of “symbolic reference,” is ambiguous.
Further, Oracle’s request, while couched as seeking clarification of the meaning of the
term dynamic in the context of the ’104 patent, is nothing more than another attempt to eliminate
the “dynamic” nature of the symbolic resolution disclosed and claimed by the ’104 patent. Oracle
posits that the ’104 patents requirement of dynamic resolution is satisfied when symbolic
references are “resolved to identify the memory location of the underlying data based on memory
conditions that exist at whatever time the resolution occurs.” [Dkt. 1168 at 11 (emphasis added).]
By definition, symbolic references must be resolved; thus, Oracle’s definition of dynamic would
apply to every symbolic reference, because resolution must happen at some time.
The ’104 patent is clear, however, that the claimed symbolic references are resolved
during execution—i.e., at runtime. For example, the ‘104 patent discloses that the main
interpretation routine determines if the reference is symbolic, invokes the dynamic field reference
routine that resolves the symbolic reference, and then re-executes the instruction. [TX 4015 at
5:10-23.] This passage clearly defines the dynamic nature of the ’104 patent’s symbolic
resolution. It is performed by the interpretation routine—i.e., while interpreting the instruction
containing a symbolic reference. After this runtime resolution occurs, the resolved instruction is
re-executed. Indeed, the fact that the patent describes the second pass as “reexecution” confirms
that the symbolic reference resolution occurs during execution.
Given the testimony of Oracle’s own expert and the clear import of the ’104 patent
disclosure as captured in the Court’s construction of “symbolic reference,” Oracle has provided
no basis for its belated request to redo the claim construction. More importantly, applying the
current construction, no reasonable jury could find that claims 27 and 29 are infringed by dexopt.
III. A reasonable jury could only find that Google does not infringe the asserted claims
of the ’520 patent.
Oracle asks for judgment as a matter of law of infringement based on its argument that
“simulating execution” does not require any actual operations on a Java virtual machine to be
simulated, and that the term also encompasses the distinct method (which results in different
outcomes in certain circumstances) of pattern matching. Neither of these contentions are
supportable, and Oracle’s arguments should be rejected.
A. The jury is entitled to credit Professor Parr’s testimony explaining why
To reach his opinion on non-infringement, Professor Parr not only looked at the source
code, but also performed multiple experiments to confirm his understanding. His second
experiment showed beyond any doubt that the dx tool is not simulating execution as required by
the ’520 patent. He inserted an extra piece of bytecode that put a zero into the zeroth entry in an
array—where a zero already existed at the inception of the array. Such an extraneous piece of
code, when run through a program that simulated execution of byte code instructions, would
create an efficient instruction with no problem. [RT 3810:4-13 (Parr).] However, the dx tool
failed to create a proper static array initialization instruction when it was fed that code. [RT
3809:20-3810:3 (Parr).] As Professor Parr explained, the code was set up to “punt” when it did
not find the pattern it sought. [RT3801:7-18 (Parr)]. Hence, Professor Parr concluded that the dx
tool code could not be simulating execution of the byte code. Dr. Mitchell’s so-called
“experiment,” referenced in Oracle’s JMOL brief at 14:23-15:2, in no way contradicts or even
addresses Professor Parr’s findings. Dr. Mitchell’s work consisted of running the dx tool on a
standard Java byte code pattern and confirming that it created a single instruction to initialize a
static array. [RT 3345:8-3346:1 (Mitchell).] But the fact that the byte code started in one form
and ended in another does not tell how it got there; and Dr. Mitchell admitted that, for a method
claim, it is not enough simply to show that “with the same input you’d get the same output from a
piece of code.” [RT 4054:24-4055:4 (Mitchell).] Accordingly, Dr. Mitchell’s experiment is
insufficient to show that pattern matching infringes the ’520 patent.
pattern matching differs from simulating execution
Oracle’s contention that simulated execution includes the far different process of pattern
matching because the claims “do not exclude pattern matching” is incorrect. The burden is on
Oracle to show infringement of the claims as properly construed—not on Google to prove that the
claims do not cover what the dx tool does. Oracle never requested construction of “simulating
execution” in the ’520 patent; its position was that the phrase takes its plain meaning. Yet
nothing in the plain meaning of that phrase shows that pattern matching is covered. Indeed, it is
undisputed that the ’520 patent makes no mention of pattern matching. [RT 3521:10-12
(Mitchell); TX 4011.] Oracle continues to highlight the source code comments from the class
simulator.java in an attempt to prove its case. But both experts agree that the code that identifies
the static initialization of arrays is not found in that class; it is in the separate BytecodeArray
class. [RT 3799:14-3800:7 (Parr); 3519:19-3520:3 (Mitchell); 4061:9-4062:3 (Mitchell).] And
BytecodeArray, in which Oracle concedes both the parseInstruction and parseNewarray methods
are found, Mot. at 14:17-19, is the class that identifies static initialization through pattern
matching rather than through simulated execution. [RT 3799:14-3801:18 (Parr).] Oracle cannot
show that, as a matter of law, pattern matching must be encompassed within “simulating
execution.” At most, this is a doctrine of equivalents argument that Oracle never made, and
Google (not Oracle) is entitled to judgment on it. [See Brief in Support of Google’s Motion for
Judgment as a Matter of Law on Counts V and VII of Oracle’s Amended Complaint (ECF No.
1166) at 8:21-9:25.]
B. Simulating execution, properly understood, involves the simulation of actual
At trial, Professor Parr, who has been programming in Java for nearly two decades now,
explained that “there is no meaningful definition of simulating execution of a stack machine
without manipulation of a stack. That means pushing, popping, things like that.” [RT 3794:17-
19 (Parr).] Oracle’s own expert, Dr. Mitchell, did not disagree—far from it. He agreed that “in a
Java bytecode system, instructions operate by pushing and popping and replacing values from the
top of an operand stack.” [RT 4058:3-6 (Mitchell).] Google is not attempting to read language
from the specification into the claims—it is explaining how the claim language would be
understood by those of skill in the art in light of the specification, which is to require simulating
execution of the actions set forth in the byte code instructions in order to obtain the initial values
of the static array. [TX 4011 at Fig. 3, 5:52-54.]
Java virtual machine operations.
In contrast to Professor Parr’s thoughtful explanation of what the relevant claim language
would mean to one of ordinary skill in the art, Dr. Mitchell seldom used the actual language of
“simulating execution” in his testimony, eschewing that phrase for the use of the more general
word “simulation.” [See, e.g., RT 4032 (“is properly called simulation or not”; “dx tool simulates
bytecode”; “pattern matching as a portion of simulation”; “the process is properly called
simulation”) (Mitchell).] Indeed, Oracle’s counsel repeatedly uses other words in its JMOL
motion to describe what the dx tool does. [Oracle Mot. for JMOL at 12:11-12 (“the dx tool
examines the bytecodes”); id. at 14:20 (“bytecode instructions are examined without being
executed”); id. at 15:5-7 (dx tool “examining” the byte codes) (emphases added).] Yet the claim
language of the ’520 patent is clear that what is required is not “simulating” or “examining,” but
rather “simulating execution.” TX 4011 at 9:54-57, 12:7-8. Given that Oracle itself repeatedly
describes what the dx tool does in terms other than simulating execution, a reasonable jury plainly
could find that the claim language is not satisfied by the dx tool.1
IV. Oracle’s patent infringement claims are barred by Google’s equitable defenses.
For the reasons stated in Google’s Proposed Findings of Fact and Conclusions of Law
submitted after Phase I (Dkt. 1047), Google, not Oracle, is entitled to judgment on its equitable
defenses.2 Just as it did in post-trial briefing following Phase I, Oracle’s Motion simply recites its
own gloss on disputed evidence and utterly fails to address the evidence favoring Google. Oracle
also argues that “additional facts” elicited in Phase II support its made-for-litigation story that
both Sun and Google always believed that Google needed a license for Android—a license that
Oracle now opportunistically claims in this phase was a primarily about patents, not copyrights.
1 Oracle also trots out a claim differentiation argument that was neither found in Dr. Mitchell’s
expert report, nor testified to by any witness at trial. It is therefore inappropriate to make the
argument on this record and at this point in the case. However, had Oracle attempted to make the
argument at trial, there is an simple response: Unasserted claim 3 of the ’520 patent requires that
three separate steps (allocating a stack, reading a bytecode that manipulates the stack, and
performing stack manipulation on the stack) be included within the third step (the play executing
step) of claim 1. A method that allocated a stack as part of the second step of claim 1 (“receiving
the class into a preloader”) would not infringe claim 3, as it would not have the stack allocation
step as part of the play executing step, but it would still infringe claim 1. Thus, even if claim
differentiation were an iron-clad rule (and it is not, see Eon-Net LP v. Flagstar Bancorp, 653 F.3d
1314, 1323 (Fed. Cir. 2011)), claim differentiation does not mean that claim 1 does not include
2 The jury already has found that Google proved that “Sun and/or Oracle engaged in conduct Sun
and/or Oracle knew or should have known would reasonably lead Google to believe that it would
not need a license to use the structure, sequence, and organization of the copyrighted compilable
code.” Dkt. 1089 (Answer to Special Interrogatory 4A).
[Oracle Mot. for JMOL at 16.] Oracle is wrong. Indeed, in most instances, Oracle’s gloss on the
evidence is expressly contradicted by other evidence in the record—evidence it pretends doesn’t
exist. Oracle’s motion should be denied.
A. Oracle’s “additional facts” are contradicted by the evidence
In Phase I, the evidence established that (1) Sun was well aware of Google’s plans for
Android at least as early as April 2006, (2) Sun publicly encouraged Android after it was
announced and the SDK was released in November 2007, (3) Sun never once told Google that
Android infringed Sun’s copyrights or patents, and (4) Google relied on Sun’s active
encouragement and failure to assert its rights by investing time, money, and resources into
Android. [See GFOF 37-92.] This evidence is equally relevant to Phase II, but Oracle ignores it.
Instead, Oracle tries to make hay out of “additional facts” elicited in Phase II. Oracle’s “facts”
are not facts at all; they are attorney argument, and they are contradicted by the evidence.
For example, Oracle states “[o]ne of Google’s primary goals in these negotiations was to
obtain a license to Sun’s patents.” [Oracle Mot. for JMOL at 16:25-26 (citing TX 2714, TX 22,
and TX 618).] But Andy Rubin, the head of the Android project at Google, testified that the
documents Oracle cites in support of this “fact” addressed Google’s desire to develop an open
source license with patent protection for downstream licensees, not a desire to license specific
patents from Sun. [See, e.g., RT 3190:25-3192:21.] Vineet Gupta, Sun’s lead negotiator during
the Sun-Google partnership discussions, confirmed that Sun and Google did not specifically
negotiate for a patent license, and that he never presented any Java-related patents to Google
during the negotiations. [RT 3771:21-24; TX 3542.] Nothing in the Phase II (or Phase I)
evidence supports Oracle’s position that Sun and Google were negotiating for a license to specific
Oracle also states as an “additional fact” that Tim Lindholm “was aware of the ‘104 patent
in particular.” [Oracle Mot. for JMOL at 17.] This is plainly incorrect. Mr. Lindholm testified
that he had never even read the ‘685 patent, let alone the ‘104 patent, which has entirely different
claims than the ’685 patent. [RT 3023:9-13; TX 4015.3] Nor is there any evidence that any
member of the Android team had ever seen either of the two patents-in-suit. Oracle’s vague
assertions about Google’s awareness of unidentified “Sun patents,” Mot. at 17, is irrelevant to
Google’s equitable defenses.
In short, none of the “additional facts” cited by Oracle in its Motion overcome the
overwhelming evidence in support of Google’s equitable defenses. [See GFOF at 37-92.]
B. Oracle’s patent infringement claims are barred by equitable estoppel.
For the reasons explained in Google’s Proposed Findings of Fact and Conclusions of Law,
and its Response to Oracle’s proposed findings and conclusions, Google has proven each of the
elements of its equitable estoppel defense. [Dkt. 1047 at GCOL 32-33, 1079 at 59-62; see also
A.C. Aukerman Co. v. R.L. Chaides Const. Co., 960 F.2d 1020, 1042 (Fed. Cir. 1992) (listing
elements).] Rather than address these facts, Oracle’s motion makes much of the fact that Sun
and Google discussed Android-related opportunities after Google launched Android. [Oracle
Mot. for JMOL at 20-21.] Not even Oracle’s own gloss on those discussions supports its motion
That Sun attempted to convince Google to buy a TCK license and make Android Javacompatible,
Mot. at 20-21, is irrelevant to Google’s estoppel defense. What is relevant is that Sun
never informed Google that it was violating either the ’104 or ’520 patent, until July 20, 2010,
less than three weeks before the lawsuit was filed. [RT 3181:25-3182:10 (Rubin); see also TX
1074.] Indeed, Sun and Google never even discussed a license to any specific patents, let alone
the patents-in-suit. [RT 3190:25-3192:21 (Rubin); RT 3181:25-3182:10 (Gupta).] Discussions
about a potential license unrelated to the patents-in-suit are simply irrelevant to Google’s
affirmative defense of equitable estoppels. [See Dkt. 1047 at GCOL 32-34.]
C. Oracle’s patent infringement claims are barred by laches.
For the reasons stated in Google’s Proposed Findings of Fact and Conclusions of Law,
and its Response to Oracle’s proposed findings and conclusions, Google has proven each element
3 In any event, Mr. Lindholm was not involved at any point with the design or development of the
Dalvik virtual machine specifically or even Android generally. [RT 3033:22-3035:1.]
of laches. [Dkt. 1047 at 31-32, 1079 at 64-66; see also Aukerman, 960 F.2d at 1032.]
That Sun occasionally tried to convince Google to buy a license for Android—but did not
identify or even allude to the patents-in-suit—does not excuse Oracle’s delay in filing suit. Each
of the cases Oracle cites for the proposition that negotiations are an excuse for unreasonable delay
involve negotiations focused on the specific patents at issue. See Lucent Techs., Inc. v. Gateway,
Inc., 580 F. Supp. 2d 1016, 1053 (S.D. Cal. 2008) aff'd in part, vacated in part on other grounds,
remanded, 580 F.3d 1301 (Fed. Cir. 2009) (“The evidence showed that for several years leading
up to the start of the litigation underlying this case, beginning around 1998 through 2002 and
2003, Lucent engaged in efforts to sell a license for the ’226 to computer manufacturers Gateway
and Dell.”); In re Katz Interactive Call Processing Patent Litig., 712 F. Supp. 2d 1080, 1110
(C.D. Cal. 2010) (patentee contacted alleged infringer “regarding its patent portfolio,” patentee
“asked for additional information regarding any potential infringement,” and alleged infringer
considered taking a license for the specific patent portfolio). In this case, however, the record is
clear that Sun and Google never negotiated over the patents-in-suit, or any specific patents for
that matter. [RT 3190:25-3192:21 (Rubin); RT 3181:25-3182:10 (Gupta).]
Oracle also ignores Mr. Rubin’s testimony that, during the time of Sun’s and Oracle’s
delay in filing suit, Google invested in Android by hiring engineers, creating Google applications
for Android, and spending time and money to help Google and its partners bring phones to
market. [RT 1715:2-1717:25; Dkt. 1047 at GFOF 82-86.] Oracle cites no case suggesting that
the “prejudice” requirement for laches cannot be met where the defendant invests time, money,
and resources in a still-developing product in reliance upon the plaintiff’s delay and at a time
when the defendant could have changed course had the plaintiff filed suit earlier.
D. Oracle’s patent infringement claims are barred by waiver.
For the reasons stated in Google’s Proposed Findings of Fact and Conclusions of Law,
and its Response to Oracle’s proposed findings and conclusions, Google has proven that Sun
waived its rights to enforce the ’104 and ’520 patents. [Dkt. 1047 at GCOL 35, 1079 at 56-
58.] For the reasons explained above, Oracle’s desire to sell Google a license does not contradict
the evidence establishing that Oracle waived its right to pursue legal action against Google.
E. Oracle’s patent infringement claims are barred by implied license
For the reasons stated in Google’s Proposed Findings of Fact and Conclusions of Law,
and its Response to Oracle’s proposed findings and conclusions, Google has proven that the entire
course of conduct between Sun and Google over the relevant time period created an implied
license for Google to use the ’104 and ’520 patents in Android. [Dkt. 1047 at GCOL 34-35, 1079
at 62-63.] Oracle’s attempt to limit the doctrine of implied license to a specific factual situation
unlike the situation here is unavailing.
Oracle cites two cases that address a specific situation in which an implied license can
arise. [Oracle Mot. for JMOL at 23-24 (citing Zenith Elecs. Corp. v. PDI Comm’n Sys., Inc., 522
F.3d 1348, 1360 (Fed. Cir. 2008); Jacobs v. Nintendo of Am, Inc., 370 F.3d 1097, 1100 (Fed. Cir.
2004)).] But these cases are not the only situations where an implied license can arise. Indeed,
the Federal Circuit, relying on De Forest Radio Tel. Co. v. United States, 273 U.S. 236 (1927),
has recognized there are “different categories of conduct” which can give rise to implied license:
Since De Forest, this court and others have attempted to identify and isolate
various avenues to an implied license. As a result, courts and commentators relate
that implied licenses arise by acquiescence, by conduct, by equitable estoppel
(estoppel in pais), or by legal estoppel. These labels describe not different kinds of
licenses, but rather different categories of conduct which lead to the same
conclusion: an implied license.
Wang Labs., Inc. v. Mitsubishi Elecs. Am., Inc., 103 F.3d 1571, 1580 (Fed. Cir. 1997) (internal
citations omitted) (emphases added).
Contrary to Oracle’s attempt to limit the doctrine, the general test for whether there is an
implied license is whether “the entire course of conduct between a patent or trademark owner and
an accused infringer” creates such an implied license. McCoy v. Mitsuboshi Cutlery, Inc., 67 F.3d
917, 920 (Fed. Cir. 1995). The evidence here supports a finding of implied license.
V. Google chose not to present its defenses of patent misuse, use by the United States,
unclean hands, and express license, and therefore does not oppose Oracle’s motion
on these defenses.
In Section VI of its Motion, Oracle moves for judgment as a matter of law as to Google's
Sixth (patent misuse), Eighth (use by the U.S.) and Nineteenth (unclean hands) defenses, as well
as Google's defense of express license. Although Google believes these defenses have merit,
Google chose not to present these defenses at trial. Google therefore does not oppose Section VI
of Oracle’s Motion.
For the foregoing reasons, Google requests that the Court deny Oracle’s Rule 50 Motion
at the close of all the Phase II evidence.
Dated: May 17, 2012
KEKER & VAN NEST LLP
/s/ Robert A. Van Nest
By: ROBERT A. VAN NEST
Attorneys for Defendant
MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
KENNETH A. KUWAYTI (Bar No. 145384)
MARC DAVID PETERS (Bar No. 211725)
DANIEL P. MUINO (Bar No. 209624)
[email address telephone fax]
BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[email address telephone fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[email address telephone fax]
DORIAN DALEY (Bar No. 129049)
DEBORAH K. MILLER (Bar No. 95527)
MATTHEW M. SARBORARIA (Bar No. 211600)
[email address telephone fax]
Attorneys for Plaintiff
ORACLE AMERICA, INC.
UNITED STATES DISTRICT COURT
ORACLE AMERICA, INC.
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
Case No. CV 10-03561 WHA
ORACLE AMERICA, INC.’S
OPPOSITION TO GOOGLE’S
RULE 50(A) MOTION AT THE
CLOSE OF ALL EVIDENCE FOR
PHASE II (PATENT PHASE)
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup
TABLE OF CONTENTS
|II.||A REASONABLE JURY COULD FIND THAT GOOGLE INFRINGES THE|
ASSERTED CLAIMS OF THE ’104 PATENT
|A.||Dalvik bytecode instructions contain symbolic references||1|
|1.||A field index is a symbolic reference that is contained in a Dalvik|
|2.||Google misrepresents Oracle’s infringement argument and attempts|
to narrow the meaning of the term “data”
|3.||Dr. Mitchell’s testimony provides substantial evidence of|
|B.||Android dexopt resolves symbolic references dynamically rather than|
|C.||Google infringes the asserted claims of the ’104 patent literally||9|
|III.||A REASONABLE JURY COULD FIND THAT GOOGLE INFRINGES THE|
ASSERTED CLAIMS OF THE ’520 PATENT
|IV.||GOOGLE CANNOT ESCAPE LIABILITY FOR PATENT INFRINGEMENT|
BY CLAIMING IT GIVES AWAY ANDROID FOR FREE
|V.||THE ’104 PATENT IS A VALID BROADENING REISSUE||16|
|VI.||A REASONABLE JURY COULD FIND THAT GOOGLE’S INFRINGEMENT|
TABLE OF AUTHORITIES
|Advanced Semiconductor Materials Am., Inc. v. Applied Materials, Inc.,|
1995 WL 419747 (N.D. Cal. July 10, 1995)
|Applied Biosystems, Inc. v. Cruachem, Ltd.,|
772 F. Supp. 1458 (D. Del. 1991)
|Aspex Eyewear, Inc. v. Marchon Eyewear, Inc.,|
672 F.3d 1335 (Fed. Cir. 2012)
|Black & Decker Inc. v. Robert Bosch Tool Corp.,|
2006 WL 3783006 (N.D. Ill. Dec. 22, 2006)
|City Solutions, Inc. v. Clear Channel Communications, Inc.,|
365 F.3d 835 (9th Cir. 2004)
|Depomed, Inc. v. Ivax Corp.,|
532 F. Supp. 2d 1170 (N.D. Cal. 2007)
|Gustafson, Inc. v. Intersystems Indus. Prods., Inc.,|
897 F.2d 508 (Fed. Cir. 1990)
|HollyAnne Corp. v. TFT, Inc.,|
199 F.3d 1304 (Fed Cir. 1999)
|i4i Ltd. P’ship v. Microsoft Corp.,|
598 F.3d 831 (Fed. Cir. 2010), aff’d, 131 S. Ct. 2238 (2011)
|i4i Ltd. P'ship v. Microsoft Corp.,|
670 F. Supp. 2d 568 (E.D. Tex. 2009), aff’d, 589 F.3d 1246 (Fed. Cir. 2009)
|Imonex Servs., Inc. v. W.H. Munzprufer Dietmar Trenner GMBH,|
408 F.3d 1374 (Fed. Cir. 2005)
|In re Graff,|
111 F.3d 874 (Fed. Cir. 1997)
|In re Seagate Techn., LLC,|
497 F.3d 1360 (Fed. Cir. 2007)
|18, 19, 22|
|In re Staats,|
671 F.3d 1350 (Fed. Cir. 2012)
|Kara Tech. Inc. v. Stamps.com Inc.,|
582 F.3d 1341 (Fed. Cir. 2009)
|Knorr-Bremse Systeme Fuer Nutzfahrzeuge GmbH v. Dana Corp.,|
383 F.3d 1337 (Fed. Cir. 2004) (en banc)
|Medical Solutions, Inc. v. C. Change Surgical LLC,|
541 F.3d 1136, 1141 (Fed. Cir. 2008)
|nCube Corp. v. Seachange Int’l, Inc.,|
436 F.3d 1317 (Fed. Cir. 2006)
|PalTalk Holdings, Inc. v. Microsoft Corp.,|
2009 U.S. Dist. LEXIS 131087 (E.D. Tex. Feb. 2, 2009)
|Patent Tube Corp. v. Bristol-Myers Co.,|
25 F. Supp. 776 (S.D.N.Y. 1938)
|Power Integrations, Inc. v. Fairchild Semiconductor Int'l, Inc.,|
725 F. Supp. 2d 474 (D. Del. 2010)
|Power Lift, Inc. v. Lang Tools, Inc.,|
774 F.2d 478 (Fed. Cir. 1985)
|Reeves v. Sanderson Plumbing Prods., Inc.,|
530 U.S. 133 (2000)
|Rite-Hite Corp. v. Kelley Co.,|
819 F.2d 1120 (Fed. Cir. 1987)
|Safeco Ins. Co. of Am. v. Burr,|
551 U.S. 47 (2007)
|Stryker Corp. v. Intermedics Orthopedics, Inc.,|
96 F.3d 1409 (Fed. Cir. 1996)
|Thorn EMI N. Am., Inc. v. Micron Tech., Inc.,|
821 F. Supp. 272, 275 (D. Del. 1993)
|Walker Digital, LLC v. Facebook, Inc.,|
2012 WL 1129370 (D. Del. Apr. 4, 2012)
|35 U.S.C. § 120||17|
|35 U.S.C. § 251||16|
A reasonable jury may conclude that Google infringes Claims 11, 27, 29, 39, 40, and 41 of
United States Patent No. RE38,104 (“the ’104 patent”) and Claims 1 and 20 of United States
Patent No. 6,061,520 (“the ’520 patent”). Google’s admission that it sold Android phones,
among other evidence, supports a finding that Google infringes by selling as well as by making
and using regardless of Google’s legal objection. Under existing law, the ’104 patent is a valid
broadening reissue patent. And there is sufficient evidence to support a finding that Google’s
infringement was willful.
The Court should deny Google’s motion for judgment as a matter of law.
II. A REASONABLE JURY COULD FIND THAT GOOGLE INFRINGES THE
ASSERTED CLAIMS OF THE ’104 PATENT
The record evidence provides a legally sufficient basis for a reasonable jury to find that
(1) Android’s Resolve.c infringes Claims 11, 39, 40, and 41 of the ’104 patent and (2) Android
dexopt infringes Claims 27 and 29 of the ’104 patent. There is substantial evidence that Dalvik
bytecode instructions contain symbolic references that are resolved dynamically, rather than
statically. (Because Google concedes that Resolve.c resolves symbolic references dynamically,
the question of dynamic resolution of symbolic references applies only to infringement of Claims
27 and 29 by dexopt.) Oracle’s infringement evidence proved literal infringement of the ’104
patent claims, and there is no need to consider the doctrine of equivalents.
A. Dalvik bytecode instructions contain symbolic references
The dispute over the term “symbolic reference” boils down to whether a field index in a
Dalvik bytecode instruction refers to a field in a data object by a name other than the numeric
memory location. There is sufficient evidence for a reasonable jury to find that the answer is
The parties’ trial evidence and argument focused on whether the field index in a Dalvik
bytecode instruction is a symbolic reference. There is sufficient evidence for a reasonable jury to
1. A field index is a symbolic reference that is contained in a Dalvik
find that it is. Given the testimony that Dalvik and dexopt resolve type indices, method indices,
and string indices in much the same way as field indices, a reasonable jury could conclude that
these indices are symbolic references as well. See RT 3239:17-21 (McFadden), RT 3256:8-12
(McFadden), 3310:4-3311:1 (Mitchell).
The evidence proves that the Dalvik VM uses the resolver functions of Resolve.c to
resolve a field index to a numeric memory location that is then used to obtain the value of a
specific field. RT 3308:18-3309:24 (Mitchell), 3646:24-3647:25 (McFadden). Both parties’ trial
evidence and argument focused on a Dalvik bytecode instruction called the “IGET instruction.”
The IGET instruction (together with the IPUT instruction) “performs the identified object
instance field operation with the identified field, loading or storing into the value register.” TX
735 at 6. In other words, the IGET instruction “finds the instance of the object and retrieves the
data from the specified field.” RT 3221:2-7 (McFadden); see also RT 3968:10-15 (August). The
IGET instruction contains the “IGET” opcode and three operands—vA, vB, and field@CCCC—
where the third operand, field@CCCC, is the field index. TX 735 at 6; RT 3221:8-10
Dr. Mitchell testified that the field index is a symbolic reference:
Q. What’s the relationship between the “y” in the source code program and that
RT 4023:8-16 (Mitchell).
A. “Field@01” is really the Dalvik instruction’s version of this field named “y”
(indicating). So everywhere in the program that used “y,” that the programmer
wrote “y,” the compiler and the dx tool turned that into “field 01.” So this is really
the symbolic name reference “field 01” in the bytecode program corresponding to
the programmer’s favorite name here “y,” for the “x” “y” coordinate of a point.
Q. Does the reference “01” -- so you regard “01” as a symbolic are [sic – or]
A. Symbolic reference.
Q. All right. Does the symbolic reference “01” need to be resolved to execute the
A. Right. What the programmer wrote is get the value over here to this object, add
one to it, and do something else with it.
So in order for that to happen, we have to find where that actual data is in the
object using this symbolic reference. So the symbolic reference is resolved. There
are a number of steps here. You’ve heard it three or four times, so let me save you
the trouble of going through it.
RT 4024:23-4025:21 (Mitchell).
There is a process that looks up information here and then does some kind of a
search. There was an animation of a linear search. Let’s skip all that.
But ultimately what’s found as the resolution of this symbolic reference is this
actual numerical reference, actual numeric location “48.” So when that happens,
that finishes, there is a little structure built in memory here that has a few parts.
But the important part for us is it ends up with that memory location “48” in it.
And that’s what’s used by the Dalvik Virtual Machine to then get this data value
and operate on it and continue execution of the program.
The field index is the reference that is resolved to determine a numeric reference to the
corresponding instance field object. Google’s Mr. McFadden testified that the indices are
resolved by Dalvik:
Q. The Dalvik VM stores pointers that result from resolving the indexes?
RT 3236:6-11 (McFadden). It is undisputed that the field index contained in the Dalvik bytecode
instruction is not the numeric memory location of the specific field to which it refers. RT
3614:22-3615:16 (Bornstein); 3761:14-3762:6 (McFadden); 3970:20-3971:3 (August); 3533:21-
Q. And the Dalvik VM then pulls them out of storage on subsequent Dalvik
The Android source code in evidence also shows that the field index contained in the
IGET instruction is a symbolic reference. Android’s Resolve.c has a dvmResolveInstField
function for “[r]esolv[ing] an instance field.” TX 47.6 at 8. The input to dvmResolveInstField is
a field index and the output is a pointer to the instance field object. See id.; see also RT 3309:5-
24 (Mitchell); RT 3638:8-17, 3646:24-3647:8 (McFadden). Mr. McFadden’s source code
comments explain that the Dalvik resolving functions convert an index contained in the
instruction stream into a pointer:
When a class, method, field, or string constant is referred to from Dalvik bytecode,
the reference takes the form of an integer index value. This value indexes into
an array of type_id_item, method_id_item, field_id_item, or string_id_item in the
DEX file. The first three themselves contain (directly or indirectly) indexes to
strings that the resolver uses to convert the instruction stream index into a
pointer to the appropriate object or struct.
TX 46.14 at 1 (emphases added). Mr. McFadden confirmed that this was an accurate description
of Dalvik. RT 3236:12-19 (McFadden). He also testified that if the instruction stream index
were the numeric memory location, it would already be a pointer and there would be no reason to
convert it to a pointer. RT 3234:22-3235:13 (McFadden).
A reasonable jury could find that a field index meets the Court’s construction of
“symbolic reference” exactly as the Court construed it. The undisputed fact that the field index
and other indices are contained in Dalvik bytecode instructions proves that Dalvik bytecode
instructions contain symbolic references as required by Claim 11 of the ’104 patent. The same
reasoning applies to the other asserted claims.
In its motion, Google misrepresents Oracle’s infringement argument and accuses Oracle
of redefining the Court’s claim construction. Oracle’s infringement argument is based on the
Court’s construction: that the Dalvik bytecode instructions contain field indices and other indices
that refer to data to be obtained or used, and identify that data by a name other than the numeric
memory location of the data. See, e.g., RT 3303:2-3304:20 (Mitchell); TX 4015, 7:12-13. The
evidence Oracle introduced at trial supports this argument.
2. Google misrepresents Oracle’s infringement argument and attempts to
narrow the meaning of the term “data”
Under the Court’s claim construction, a symbolic reference “identifies data.” In Android,
actual field data in an instance object is “data,” as Google’s expert testified. RT 4002:5-16
(August). The actual field data in an instance object is “data” in the Court’s claim construction,
and the field index is the symbolic reference that identifies that data.
Google is the party misapplying the Court’s claim construction. Its argument is that a
reference is exclusively limited to what it directly references. But the Court’s construction places
no limitation on a symbolic reference other than it not being the numeric memory location of data
to which it refers. A symbolic reference, by its nature, cannot be a direct reference to the data it
refers to, because it must be resolved before the data can be obtained. There is no reason that a
symbolic reference to actual field data in an instance object cannot also be the numeric memory
location of other information that is useful in the resolution process that determines the numeric
memory location of the actual field data. The infringement question is whether a field index
identifies the actual field data to be obtained by a name other than the data’s location—and it
In any case, it is clear that Google is looking at the wrong data under a proper reading of
the claim. That actual data in an Android data object is the “data” in the Court’s construction is
supported by the ’104 patent, because that is the data that is “obtained” or “thereafter used” in the
asserted claims. RT 3311:23-3312:19 (Mitchell); RT 3759:12-3760:23 (McFadden); RT
3954:12-18 (August); 3958:1-3959:4 (August); TX 4015, 7:12-13, 12:16-17, 12:30-31, 12:44-45.
Moreover, actual data in a data object is what is identified by an exemplary symbolic reference
(“y”) in the specification. TX 4015, 1:65-67 (“[A]n instruction that accesses or fetches y, such as
the Load instruction 14’ illustrated in FIG. 1, references the variable y by the symbolic name
‘y’.”); Fig. 1B (illustrating “data object” containing actual values 23 and 17). Google argues that
a field index is a numeric reference to a location in the Field ID table (ECF No. 1166 at 2-3), but
the ’104 patent does not identify anything analogous to the information in the Field ID table the
claim’s as “data” that is “obtained.”
Moreover, Oracle elicited testimony from which the jury could conclude that the contents
of the Field ID table are not “data” at all:
Q. So what this description of the overall file layout of a dex file shows is that the
Field ID table is not stored in the Data area of a dex file; true, sir?
RT 3754:13-19 (McFadden). Accordingly, a reasonable jury could reject Google’s argument as
inconsistent with the Court’s claim construction.
A. It’s not stored in the section that’s labeled “Data.”
Q. Not stored in the section labeled “Data” by TX 736, Google’s official definition
of the dex file format; true, sir?
Dr. Mitchell’s opinion, to which he testified at trial, is that the indices in Dalvik bytecode
instruction are symbolic references. RT 4023:8-16, 4024:23-4025:21 (Mitchell). Google attacks
that testimony by arguing that Dr. Mitchell had admitted in Paragraphs 269, 272, and 293 of his
opening report that indices were numerical references. ECF No. 1166 at 3.
3. Dr. Mitchell’s testimony provides substantial evidence of infringement
But Dr. Mitchell testified about sections of his opening expert report that support his
opinion that the field indices in the IGET instructions are symbolic references. RT 4062:21-
4066:19 (Mitchell) (testimony regarding Mitchell Opening Report paragraphs 250, 252, 283 and
page 38 of Volume 2). He identified particular passages that disclose and support his opinion and
establish that his opinion did not change in response to Dr. August’s report. RT 4065:16-4066:19
(Mitchell). Although Google identified three instances of the same typographical error in Dr.
Mitchell’s opening report, he testified that he corrected the problem during his deposition when
he first realized it, and the jury saw the deposition video in which he saw the error, consulted the
code reproduced in the report, and corrected the error. RT 3489:21-3490:1 (Mitchell). He
explained the errors again when cross-examined a second time. RT 3490:7-10, 3529:17-3530:5,
4038:10-4040:9 (Mitchell). Dr. Mitchell was quite clear that the mistakes in three paragraphs of
his report were just that, and nothing more:
Q. And you’re now -- you’ve now testified that was just a mistake, right?
RT 4038:4-6 (Mitchell).
The jury is entitled to believe Dr. Mitchell’s testimony. When deciding Google’s motion
for judgment as a matter of law, the Court must credit Dr. Mitchell’s testimony. City Solutions,
Inc. v. Clear Channel Communications, Inc., 365 F.3d 835, 841 (9th Cir. 2004) (“In ruling on a
motion for JMOL, ‘the court must draw all reasonable inferences in favor of the nonmoving
party, and it may not make credibility determinations or weigh the evidence.’”) (quoting Reeves v.
Sanderson Plumbing Prods., Inc., 530 U.S. 133, 150 (2000)).
Google’s argument that Dr. Mitchell “conjure[d] up a re-interpretation of the term
‘symbolic reference’” is not supported by the evidence. ECF No. 1166 at 3. Dr. Mitchell’s
testimony was that because a field index refers to “data,” in this case actual field data, a field
index is a symbolic reference under the Court’s construction and therefore the ’104 patent is
infringed. Because his testimony regarding the “data” that the field indices refer to is consistent
with the Court’s construction, the evidence elicited from Google’s own witnesses, and the
Android source code itself, there is no reason his testimony should be discredited.
Given the evidence indicating that field indices and other indices contained in the Dalvik
bytecode instructions refer to data by a name other than the numeric memory location of the data,
a reasonable juror could find that Dalvik bytecode instructions contain symbolic references, and
that the Dalvik VM and dexopt infringe the asserted claims of the ’104 patent on that basis.
B. Android dexopt resolves symbolic references dynamically rather than
Google devotes a single paragraph of its brief to trying to show that Android dexopt
resolves symbolic references statically rather than dynamically. Google ignores the contradictory
testimony of its own witnesses and expert and documents authored by its own engineers that
refute its position. No reasonable jury could find in Google’s favor on this issue (see ECF
No. 1168 at 8-9), and certainly there is more than enough evidence in the record to support a
finding against it.
Google relies on testimony from Android engineer Andy McFadden that dexopt
“perform[s] a set of static optimizations.” RT 3730:16-22. But Google ignores other McFadden
testimony establishing that dexopt is dynamic. Mr. McFadden admitted that because the
resolution process depends on the conditions actually existing on the handset, dexopt needs to
rerun when those conditions change by way of a system update. RT 3769:13-17 (McFadden); see
also RT 3255:20-25 (McFadden) (admitting need to run dexopt when performing system update
because memory layout could change). Similarly, Google relies on testimony from its expert
Dr. August that dexopt is static because it “runs and must run before the program executes.” RT
3940:17-20 (August). But when asked whether “dexopt processes the dex files when the Dalvik
Virtual machine is running,” Dr. August conceded that it does so “[s]ometimes.” RT 3988:14-
3989:23 (August). Even Mr. Bornstein admitted that dexopt processes dex files while the Dalvik
Virtual Machine is running. RT 3580:21-23 (Bornstein).
The three documents Google relies on cannot support judgment either. TX 739 is a
duplicate of TX 105, with a different exhibit number. Relying on a cropped quote, Google cites it
for the proposition that “dexopt performs optimizations that ‘can be inferred statically.’” ECF
No. 1166 at 5. But the full sentence directly refutes Google’s position. It actually states that,
“Some of these require information only available at runtime, others can be inferred statically
when certain assumptions are made.” TX 739 at 5. Oracle, of course, does not have to show that
every single dexopt optimization is performed dynamically to prove infringement. “Some” is
enough. A reasonable jury could find in Oracle’s favor—but not Google’s—on the basis of this
document alone. That is particularly true given that, when responding to a customer query about
dexopt asking, “Why do we need to do this during runtime? Couldn’t it be done in compile
time?” Android engineers quoted verbatim from this very part of TX 739 stating that it shows
“why some of these optimizations can only be performed at runtime.” Compare TX 1094 with
Similarly, TX 735 states only that some opcodes “are reasonable candidates for static
linking,” and TX 737 identifies some “statically linked” instruction formats. (TX 735, 737). But
stating that something is a “reasonable candidate” for static linking does not establish that it does
not operate dynamically. And labeling a process as “static linking” cannot change the fact that it
operates dynamically in any event.
The jury could also accept the testimony of Oracle’s expert. That testimony did not
consist of mere “conclusory statements” as Google contends. ECF No. 1166 at 5. Dr. Mitchell
testified at length, explaining in detail how dexopt operates dynamically and how claims 27 and
29 are infringed, expressly relying on and referring to the dexopt documentation, testimony from
Mr. McFadden and Mr. Bornstein, and demonstrative exhibits. RT 3322:12-3333:13, 3538:9-
3539:24, 4028:14-4029:8. By way of example only, Dr. Mitchell provided the following
There are a number of reasons why this is a dynamic process. It requires runtime
information from the runtime environment.
RT 3539:9-24 (Mitchell).
As I – the class name, for example, refers to a location of a class loaded into
memory. The position of a class in memory depends on how classes are loaded
into the specific phone or device. So there is runtime information that’s necessary
in order to do this resolution.
Q. And therefore?
A. Therefore, it’s a dynamic operation.
It’s also implemented in the Dalvik Virtual Machine, in the dexopt that uses the
same code as the—or overlapping code with the bytecode interpreter.
This isn’t done, couldn’t be done during dx tool on the developer’s platform, as I
believe Andy McFadden explained. So it’s really a dynamic runtime environment
TX 105/739 was part of the dexopt documentation Dr. Mitchell relied upon. As
Dr. Mitchell testified, this document shows “that it starts the virtual machine up, does this kind of
dynamic boot process there, loads files from the class path because, as I explained, we need to
know where they sit in memory in order to find numeric references, and then sets about verifying
and optimizing and doing other things with that bytecode. So this is the sense in which it’s
dynamic and it’s part of the runtime environment of the Android platform.” RT 3332:1-14
(Mitchell); see TX 105/739 at 2.
There is more than enough evidence in the record for a reasonable jury to find in favor of
Oracle. Google’s JMOL should be denied.
C. Google infringes the asserted claims of the ’104 patent literally
Oracle presented evidence of Google’s literal infringement of the ’104 patent and argued
that Google literally infringes the ’104 patent. There is sufficient evidence for a jury to find
literal infringement—indeed, as shown in the previous sections, the evidence is compelling. See
also ECF No. 1168. The jury was not instructed on the doctrine of equivalents, nor was it argued.
The doctrine of equivalents provides no basis for granting judgment as a matter of law of noninfringement
in this case.
III. A REASONABLE JURY COULD FIND THAT GOOGLE INFRINGES THE
ASSERTED CLAIMS OF THE ’520 PATENT
Oracle proved that Android’s dx tool literally infringes the asserted claims of the ’520
patent by simulating execution of initialization bytecodes to determine their static initialization.
As admitted by Google’s expert, the dx tool identifies the static initialization of bytecodes without
executing them. That is the definition of “simulating execution” set forth in the claims. If there
was any uncertainty about what the dx tool does, the file that commences the process is called
“Simulator.java” and explicitly states that it “simulate[s] the effects of executing bytecode.”
TX 46.16 at line 37.
Google has only two arguments to avoid liability for infringing the ’520 patent. Google
argues that it should escape liability because its expert chooses to call the simulation process in
the dx tool something else: “pattern matching.” But there is nothing in the claim language that
excludes simulation involving pattern matching from the ambit of the claims. Google’s position
is based on reading limitations into the claims regarding what “simulating execution” allegedly is
and is not. But the claims say what “simulating execution” is—identifying the static initialization
of bytecodes without executing them. TX 4011, 9:56-57. It is undisputed that the dx tool does
As Dr. Mitchell testified, the Android dx tool faces the same problem as described in the
’520 patent and solves it in the same way. When a Java program includes a static array (i.e., a set
of data items), the Java compiler will create a long list of bytecode instructions to initialize the
array. TX 4011 (’520 patent), 1:57-2:58; RT 3335:10-19 (Mitchell). This set of bytecode
instructions is larger than the array itself and takes up more memory space. Id. To reduce the
number of instructions needed for initialization, the ’520 patent invention simulates execution of
the instructions (i.e., examines them without executing them) to determine the static initialization
they perform, and replaces them with a shorter instruction to initialize the array. TX 4011 (’520
patent), 2:64-3:7, 3:66-4:17.
The Android dx tool does the same thing. It receives Java bytecode files compiled by a
Java compiler. RT 3547:5-19 (Bornstein). Files containing static arrays will have long lists of
bytecode instructions for initialization. RT 3334:16-3335:19 (Mitchell). The dx tool simulates
execution of those instructions to identify the static initialization they perform, and replaces them
with a single instruction to initiate the array. RT 3338:19-3339:19 (Mitchell). This process is
commenced in a file called “Simulator.java” within the dx tool. TX 46.16 (Simulator.java);
RT 3340:5-3341:16 (Mitchell). As the engineer comments clearly state, Simulator.java
“simulate[s] the effects of executing bytecode” to figure out what the bytecode does. TX 46.16 at
lines 37-43, 86-105. Simulator.java calls upon certain parsing methods (parseInstruction and
parseNewarray) to assist with understanding the instructions. TX 46.16 at line 99; TX 46.17 at
lines 211, 887; RT 3341:17-3344:7 (Mitchell). As a result of Simulator.java and the methods it
invokes, the bytecode instructions are examined without being executed, their static initialization
is determined, and a shorter “fast instruction” is generated to replace the long list of bytecode
instructions. Id. This matches the “simulating execution” step of the asserted claims.
Google argues that the dx tool cannot be simulating execution of bytecodes because its
process (1) involves “pattern-matching,” and (2) does not manipulate a stack. But neither of
those limitations exist in the asserted claims. Claims 1 and 20 do not say “simulating execution
of bytecodes except where it involves pattern-matching,” nor do they say “simulating execution
by manipulating a stack.”
While insisting that the dx tool does not simulate execution of bytecodes, Dr. Parr
nonetheless admitted that it performs all of the constituent recited steps of simulation. He
conceded that the dx tool works as follows (Dr. Parr’s testimony in italics):
(1) The dx tool “identif[ies] the static initialization of the array”
“A. We agree that the dx tool identifies static initialization of an array.”
(2) by examining the “byte codes of the clinit method against a memory”
Q. And you also agree that what we’re talking about when we’re doing the
function in the dx tool is: “. . . directed to the bytecodes of the clinit method
against a memory.” True, sir?
A. Yes. The static initialization of an array is done with instructions in the clinit
(3) and does so “without executing the byte codes.”
“Q. . . . you would agree with me that this is done without executing the
bytecodes in the dx tool; true, sir?
RT 3822:17-3823:13. Accordingly, the dx tool is simulating execution of bytecodes as described
in the asserted claims.
A. In this context, yes.”
Google and Dr. Parr admit, moreover, that the dx tool’s handling of initialization
bytecodes begins in the Simulator.java file. ECF No. 1166 at 7; RT 3830:12-19, 3834:8-16,
3834:25-3835:5 (Parr). The engineer comments in that file explicitly describe it as a “[c]lass
which knows how to simulate the effects of executing bytecode.” TX 46.16 at lines 37. Google
tries to evade this description by arguing that much of the process happens in another file via
certain parsing methods (parseInstruction and parseNewarray) that are called by Simulator.java.
ECF No. 1166 at 7-8. But the fact that Simulator.java calls on methods to parse instructions does
not mean it is not still simulating execution of bytecodes. Dr. Parr admitted that parsing
instructions is part of the simulation process:
Q. In order to simulate execution of a bytecode instruction, that code would make
a call to another method called parseInstruction on line 119; true, sir?
RT 3828:5-16, 3829:8-17.
Q. So in order to simulate execution of a bytecode instruction using this code, you
need to parse the instruction; true, sir?
A. I would use the term “decode,” but, yes, I understand what the developer
Q. So parsing the instruction here is part of simulation execution?
A. Parsing a single instruction, yes.
. . .
Q. And, again, to simulate execution of the bytecodes, the method makes a call to
a method calls parseInstruction that’s on Line 99; true, sir?
Q. So, again, in order to simulate execution, this case of a block of bytecode
instructions, you parse the instruction; true, sir?
A. It individually parses an instruction, yes.
Google also cites to Dr. Parr’s experiment in which he added a fake bytecode instruction
to the stream of initialization instructions to break the pattern of instructions and cause the dx tool
process to fail. ECF No. 1166 at 7. Google argues that “[a] process using simulated execution
would simulate the execution of each instruction, including the useless instruction . . .” Id. This
interpretation of “simulating execution” is not rooted in the claim language, which requires
“simulating execution of the byte codes” but not necessarily separate simulation of each and
every bytecode. In fact, the specification states that the preloader of the invention will not
simulate execution of each bytecode, but rather only certain bytecodes that are “generally used to
perform static initialization of an array.” TX 4011, 5:17-51 (“Any byte codes other than those
listed above are not recognized. . . . If a byte code is not recognized, the preloader considers it
unsuitable for optimization”). Whether the dx tool simulates each instruction separately or blocks
of them together (i.e., pattern-matching), it still simulates execution of bytecodes as recited in the
Finally, Google’s argument improperly imports “stack manipulation” into the asserted
claims. ECF No. 1166 at 7-8. As Dr. Parr admitted, the asserted claims make no mention of
stack manipulation. TX 4011, 9:47-62, 12:3-7; RT 3794:20-23. Google had two opportunities to
request construction of claim terms and did not seek to construe “simulating execution” to require
“stack manipulation.” Nor would there be any basis for limiting the claims to an exemplary
embodiment. Kara Tech. Inc. v. Stamps.com Inc., 582 F.3d 1341, 1345, 1348 (Fed. Cir. 2009)
(“The patentee is entitled to the full scope of his claims, and we will not limit him to his preferred
embodiment or import a limitation from the specification into the claims.”). Indeed, dependent
Claim 3 confirms that independent Claim 1 is not limited to stack manipulation, since Claim 3
includes “stack manipulation” as an express limitation. Aspex Eyewear, Inc. v. Marchon
Eyewear, Inc., 672 F.3d 1335, 1348 (Fed. Cir. 2012) (reversing summary judgment of
noninfringement because “the 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”). The absence of stack manipulation in the dx tool is irrelevant to infringement, as the
asserted claims do not require that feature.
Contrary to Google’s suggestion, Oracle’s position is not “an implied theory of equivalent
infringement.” ECF No. 1166 at 9. Oracle has shown that the dx tool literally infringes Claims 1
and 20 by simulating execution of bytecodes (i.e., examining the bytecodes without executing
them) to identify their static initialization, as recited in the claims. Google is not entitled to
judgment on the ’520 patent; to the contrary, Oracle is entitled to judgment as a matter of law as
set forth in its counterpart motion. ECF No. 1168 at 12-16.
IV. GOOGLE CANNOT ESCAPE LIABILITY FOR PATENT
INFRINGEMENT BY CLAIMING IT GIVES AWAY ANDROID FOR
Google next argues it cannot be held liable for patent infringement because its business
model is to make Android available for “free” and then make its money indirectly through
advertising. This is not the law, and the Court has already rejected this argument twice.
In the Parties’ Joint Proposed Jury Instructions, Google proposed that the jury be
instructed that for purposes of patent infringement a sale or offer to sell “does not include giving
something away for free.” ECF No. 539 at 98. The Court did not accept this language. Google
made the same argument at the charging conference and the Court rejected it outright, adopting
Oracle’s proposed language that “Distributing or offering a product for free constitutes a use or
That’s got to be the law. At least on the facts of this case. It would be wrong for
the jury to have the idea that Google, if it is infringing, is excused from infringing
merely because of this free thing on the Internet. We all know that Google makes
millions off of this, and this is – indirectly, maybe, but it’s the way it works. So
this should not be – this is a no-brainer. The law has to be this.
RT 3665:24-3667:7. See also ECF No. 1153 ¶ 14 (final jury instructions).
The Court’s position is well supported by the case law. But the Court does not even have
to reach this question because Google’s admissions established direct infringement independent
of this issue. Google admitted in an RFA response that it sold the Android Nexus One phone in
the United States. RT 3105:4-5 (“Google admits that it sold Nexus One devices in the United
States.”). And Google Developer Programs engineer Daniel Morrill testified that Google
developers use the Android SDK to develop applications for Android and then run these
applications on Android phones to test them. TX 1126 (Morrill Dep. Tr. at 24:3-23, 36:5-37:23,
38:09-39:07). Google admitted this in RFA responses that were entered into the record as well.
In any event, many decisions have held that giving away an infringing product for free is a
“use” or “sale” under section 271(a), particularly where it is associated with anticipated economic
gain. In Thorn EMI N. Am., Inc. v. Micron Tech., Inc., for example, the court found the plaintiff
infringed by giving away free samples of the infringing product:
Viewing ownership of a patent as ownership of the right to exclude, each delivery
of a free sample consequently impinges on the patentee’s right to exclude others
from interfering with the patentee’s monopoly on the patented product. A
patentee’s monopoly would be worthless, for example, if, in an attempt to solicit
business, a person delivered free samples to all of the patentee’s potential
customers. Mere solicitation, in contrast, does not tangibly affect the patentee’s
monopoly. In sum, because delivery of free samples of allegedly infringing
samples tangibly impinges on the patentee’s monopoly rights in a way that
ordinary solicitation does not, such delivery must be regarded as “use” of an
allegedly infringing product for the purposes of § 271(a).
821 F. Supp. 272, 275 (D. Del. 1993) (emphasis added).
The scenario Thorn foresaw is precisely what is happening here. Google has gained a
dominant market position by making its infringing Android operating system available for free.
As Oracle CFO Safra Catz noted, “It’s pretty hard to compete with free.” RT 2322:11-12 (Catz).
See also Applied Biosystems, Inc. v. Cruachem, Ltd., 772 F. Supp. 1458, 1466 (D. Del. 1991)
(mailing samples of an infringing product may constitute direct patent infringement); Patent Tube
Corp. v. Bristol-Myers Co., 25 F. Supp. 776, 777 (S.D.N.Y. 1938) (“The distribution of the
patented device only for advertising purposes and without actual monetary compensation
therefore, in my opinion, creates no exception to the general rule that use of the patented device is
forbidden. To hold so would be permitting the doing of something indirectly which is forbidden
to be done directly.”).
1 To the extent Google is implying that this issue may be relevant to indirect infringement, it is
foreclosed from doing so. The parties stipulated that “if the jury finds that Google directly
infringes any claims of either or both of the ’104 and ’520 patents, the verdict shall be treated as a
verdict in favor of Oracle with respect to both its direct and indirect infringement claims relating
to such directly infringed patent claims.” ECF No. 1139 ¶ 1.
As the Federal Circuit stated in Medical Solutions, Inc. v. C. Change Surgical LLC, a case
cited by Google, “[t]he inquiry as to what constitutes a ‘use’ of a patented item is highly casespecific.”
541 F.3d 1136, 1141 (Fed. Cir. 2008) (citation omitted). It is not surprising, then, that
all the cases Google relies upon have dramatically different facts from those at issue here,
involving jurisdictional questions and isolated instances of a demonstration or offer to donate a
product. The holding in Medical Solutions, for example, was that the demonstration of a device
at a trade show “which appears to fall short of practicing all of the elements of any one claim”
was not a sufficient basis for jurisdiction. Id. See also Advanced Semiconductor Materials Am.,
Inc. v. Applied Materials, Inc., 1995 WL 419747 (N.D. Cal. July 10, 1995) at *6 (finding triable
issue of material fact as to whether product demonstration constituted infringement); HollyAnne
Corp. v. TFT, Inc., 199 F.3d 1304, 1309 (Fed Cir. 1999) (plaintiff “conceded it was attempting to
base personal jurisdiction on one offer to donate and nothing more”).
In contrast, by distributing Android for “free,” Google is generating hundreds of millions
of dollars in revenue annually. See TX 1061 at 7. One internal Google document refers to
Android as a $10 billion opportunity. TX 431. As Google Chairman Eric Schmidt testified, “the
primary reason to have something like Android is that people will do more searches, and then
we’ll get more money as a result.” RT 1458:9-16.2 In an industry where a free distribution
business model like Google’s is hardly unique, Google’s argument would gut patent law.
The Court should deny this part of Google’s motion as well.
V. THE ’104 PATENT IS A VALID BROADENING REISSUE
As Google acknowledges, under existing law Google has no defense under 35 U.S.C.
§ 251. Two months ago, the Federal Circuit held that “after a broadening reissue application has
been filed within the two year statutory period, an applicant is ‘not barred from making further
broadening changes’ after the two year period ‘in the course of [the] prosecution of the reissue
2 In addition, Android is not given away for free—it is licensed in exchange for consideration.
Under the license selected by Google (the Apache License, Version 2.0), licensees agree to
certain conditions for further distribution and to waive Google’s liability arising out of Android,
among other obligations. See, e.g., TX 46.21 (identifying Android source code as copyrighted
and referring readers to license link at http://www.apache.org/licenses/LICENSE-2.0 for “the
specific language governing permissions and limitations under the License.”).
application.’” In re Staats, 671 F.3d 1350, 1355 (Fed. Cir. 2012) (quoting In re Graff, 111 F.3d
874, 877 (Fed. Cir. 1997)). In Staats, a patentee first filed its application in 1996, was granted a
patent in 1999, and subsequently filed three broadening reissue applications, adding broadened
claims as late as 2007, eight years after the original patent issued. The Federal Circuit reversed
the rejection of the third set of claims by the Board of Patent Appeals and Interferences.
In this case, Sun filed its original application on December 22, 1992, and U.S. Pat.
No. 5,367,685 issued on November 22, 1994. TX 4015 at (64). Sun filed a reissue application on
November 21, 1996, which matured into U.S. Pat No. RE36,204 on April 27, 1999. TX 4013 at
(22), (45). While the ’204 reissue application was pending, Sun timely filed a reissue
continuation application on March 3, 1999 in compliance with 35 U.S.C. § 120.3 See Certified
File History of ’104 Patent, TX 4018 at 4. The 1999 application matured into the ’104 patent.
TX 4015 at (22), (45). Sun filed the ’104 reissue application less than five years after the ’685
patent issued, and the claims added in the ’104 application directly related to the errors identified
in the oath accompanying the ’204 application. See Reissue Declaration, TX 4018 at 29-30;
Supplemental Reissue Declaration, TX 4018 at 1133. The claims at issue in Staats, by contrast,
were not even related to the claims in the original reissue application. 671 F.3d at 1353. Under
Federal Circuit precedent and Sections 120 and 251 of the Patent Act, the ’104 patent is a valid
patent resulting from a proper broadening reissue application.
VI. A REASONABLE JURY COULD FIND THAT GOOGLE’S
INFRINGEMENT WAS WILLFUL
The evidence at trial established, clearly and convincingly, that Google’s infringement of
the ’104 and ’502 patents was willful, and a reasonable jury could so find.
3 “An application for patent for an invention disclosed in the manner provided by section
112(a) . . . which is filed by an inventor or inventors named in the previously filed application
shall have the same effect, as to such invention, as though filed on the date of the prior
application, if filed before the patenting or abandonment of or termination of proceedings on the
first application or on an application similarly entitled to the benefit of the filing date of the first
application and if it contains or is amended to contain a specific reference to the earlier filed
application.” 35 U.S.C. § 120 (emphasis added). Thus a reissue continuation application is
treated as if it were filed on the date of its parent reissue application.
Under Federal Circuit law, willfulness is established if Oracle shows that (1) Google acted
“despite an objectively high likelihood that its actions constituted infringement of a valid patent”
and (2) that the objectively defined risk was “either known or so obvious that it should have been
known” to Google. See In re Seagate Tech., LLC, 497 F.3d 1360, 1371 (Fed. Cir. 2007) (citing
Safeco Ins. Co. of Am. v. Burr, 551 U.S. 47, 68-69 (2007)). With the exception of a single
sentence that baldly—and incorrectly—asserts that Oracle introduced no evidence sufficient to
meet the second prong (ECF No. 1166 at 17), Google devotes its entire argument to the first
Willfulness is determined based on the “totality of the circumstances,” not individual facts
in isolation. See Knorr-Bremse Systeme Fuer Nutzfahrzeuge GmbH v. Dana Corp., 383 F.3d
1337, 1342 (Fed. Cir. 2004) (en banc); see also id. at 1343 (“‘[W]illfulness’ in infringement, as in
life, is not an all-or-nothing trait, but one of degree.” (quoting Rite-Hite Corp. v. Kelley Co.,
819 F.2d 1120, 1125-26 (Fed. Cir. 1987))).
Ignoring this settled principle, Google begins with the mistaken argument that it cannot be
liable for willful infringement unless and until it received actual notice from Oracle of the specific
patents that Google infringed. ECF No. 1166 at 13 (describing “actual notice” as a “prerequisite”
to willfulness). That is not the law, and federal courts have repeatedly rejected the argument
Google makes now. For example, in Black & Decker Inc. v. Robert Bosch Tool Corp., the Court
rejected as “without merit” defendant’s argument that willfulness required knowledge of specific
patents. No. 04 C 7955, 2006 WL 3783006, at *3 (N.D. Ill. Dec. 22, 2006). “Indeed, the Federal
Circuit instructs that it is the infringer’s knowledge of patent rights that is relevant.” Id.
(emphasis in original) (citing nCube Corp. v. Seachange Int’l, Inc., 436 F.3d 1317, 1324 (Fed.
Cir. 2006) and Imonex Servs., Inc. v. W.H. Munzprufer Dietmar Trenner GMBH, 408 F.3d 1374,
1377-78 (Fed. Cir. 2005)). See also Power Integrations, Inc. v. Fairchild Semiconductor Int'l,
Inc., 725 F. Supp. 2d 474, 479-80 (D. Del. 2010) (“If Fairchild was not busy studying and
copying Power Integrations’ technology as discussed above, it was essentially ignoring it, which
in the Court's view, also rises to the level of objectively reckless behavior.”); PalTalk Holdings,
Inc. v. Microsoft Corp., No. 2:06-CV-367 (DF), 2009 U.S. Dist. LEXIS 131087, at *6-7 (E.D.
Tex. Feb. 2, 2009) (holding that constructive knowledge is sufficient to satisfy objective prong of
Seagate test; denying defendant’s motion for summary judgment on willfulness because
defendant “was aware both of the innovative characteristics of [patentee’s] technology and [its]
development of a patent portfolio”).
The two cases that Google cites do not hold otherwise. Seagate says nothing whatsoever
about requiring knowledge of specific patents, at the page cited by Google or elsewhere. See
Seagate, 497 F.3d at 1371. To the contrary, Seagate repeats the rule that willfulness requires only
that the defendant act “despite an objectively high likelihood that its actions constituted
infringement of a valid patent.” Id. In Google’s only other case, Gustafson, the Federal Circuit
reversed a finding of willfulness where the only finding from the district court related to
knowledge was that the defendant first learned of the patent when it was served with the
complaint. See Gustafson, Inc. v. Intersystems Indus. Prods., Inc., 897 F.2d 508, 511 (Fed. Cir.
The evidence of Google’s recklessness is overwhelming. Google decided at the very
beginning of Android’s development that it would rely on Java. TX 7 (Rubin email stating that
“Android is building a Java OS”); TX 23 (Swetland email stating that “we are building a java
based system: that decision is final”). More specifically, Google planned from the very beginning
to build a Java virtual machine. TX 4 (Android was working on a JVM even before Google
acquired it); TX 1 (“current scenario” in July 2005 included JVM). Although Google tried to
argue at trial that “Dalvik” is not a JVM, the evidence at trial established that in many significant
ways, it is. Because Android uses the Java language, Dalvik follows the Java virtual machine
specification with respect to class loading, linking, and initialization. RT 3223:13-3224:5
(McFadden). Dalvik also requires developers to use the Java compiler, further compelling
similarities between Dalvik and Sun’s JVMs. RT 3547:5-10 (Bornstein). Internally, as late as
August 2009, Andy Rubin and other Android team members still used the terms “Dalvik” and
“Java Virtual Machine” “interchangeably to describe [their] work at the time internally,” and, in
fact, Rubin testified that “most of the time I used the term JVM.” TX 219; RT 3179:12-22
Sun, of course, invented Java, and has thousands of Java patents. RT 1471:24-1473:4
(Schmidt); RT 549:12-14 (Screven). Those facts were well known to Google and the world. Eric
Schmidt, Google’s CEO during most of the events in question and its chairman to this day, was
the Chief Technology Officer of Sun until 1997. RT 1471:8-1472:1; 1479:2-3 (Schmidt). Not
only did Google hold an Executive Committee seat in the Java Community Process (RT 303:1-6
(Ellison))— a seat it still holds—Google in fact designated Android engineers such as Bob Lee
and Josh Bloch to represent it in the JCP. RT 1181:15-20 (Lee); RT 827:18-21 (Bloch). By
2005, Google had hired numerous Sun engineers with extensive experience—and with patents
attributed to them as inventors—related specifically to Java virtual machines. TX 5; RT 2993:1-
24, RT 2997:14-2999:12 (Lindholm). Tim Lindholm’s book, The Java Virtual Machine
Specification, contains a notice on the copyright page itself that the specification it describes is
covered by patents, and an entire chapter of the book is devoted to describing an implementation
of the predecessor to the ’104 patent. TX 25, at 6, 401; TX 4015. See Depomed, Inc. v. Ivax
Corp., 532 F. Supp. 2d 1170, 1186 (N.D. Cal. 2007) (denying summary judgment on willfulness
where “there is evidence that the ’475 patent and an agreement to license the patent to a third
party were well publicized”). Mr. Rubin testified that he had had discussions with Sun about
patents relating to the virtual machine. RT 3205:1-3 (Rubin). These facts provide objective
evidence that there was a high likelihood that Google’s Java-based Dalvik virtual machine would
infringe one or more Sun Java patents.
In addition to Google’s knowledge of Java technology, licensing, and business, the long,
continuing pattern of licensing negotiations between the two companies also supports a finding of
willfulness. See Walker Digital, LLC v. Facebook, Inc., CIV. 11-313-SLR, 2012 WL 1129370, at
*7 (D. Del. Apr. 4, 2012) (finding that allegations “Amazon had pre-suit knowledge of the
patents-in-suit due to Amazon's interactions with Walker Digital's representatives, which
occurred before the original complaint was filed” precluded motion to dismiss willfulness claim);
see also TX 565 at p. 2 (8/2/07: Vineet Gupta: “Andy cannot say he was not aware of the
licensing requirements - as he had to go thru this at Danger - and we discussed this during Project
Android Phase, and then during the Sun/Google collaboration attempt as well.”).
Google focuses on just one piece of evidence, and tries to argue that Mr. Lindholm had
forgotten the contents of the book he wrote, or had not actually read the patent that he wrote about
in so much detail. Far less exposure to the patent and patented technology has been held to
establish knowledge—even when the defendant employee with knowledge of the patent
disclaimed knowledge of the infringing work. See Stryker Corp. v. Intermedics Orthopedics, Inc.,
96 F.3d 1409, 1415-16 (Fed. Cir. 1996). But even if the jury credited Mr. Lindholm’s testimony,
Google’s argument misses the point: Mr. Lindholm, along with Eric Schmidt, Andy Rubin, Bob
Lee, Josh Bloch, and many other Google employees, was personally and directly aware that Sun,
and later Oracle, had invested years of research into developing technology for Java virtual
machines, and that technology was covered by patents, including one of the specific patents that
Google actually infringed.4
Accordingly, Mr. Rubin had no choice to admit that, with regard to Sun,
Look, like I said before, I assume they’re running a business, they’re inventing
intellectual property, they’re protecting it through the patent system. Through
GPL, I didn’t know what they were, but I knew that it was dangerous to use the
stuff without knowing exactly what it was.
TX 1128 (Rubin Dep.) at p. 14, 16:04-16.
Despite the fact that Android was building a “Java Virtual Machine,” despite knowing that
Java technology was protected by Sun patents, despite having numerous employees with the
technical ability and direct experience to assess whether Google infringed Sun’s Java patents, and
despite having the actual inventor of the ’520 patent, Frank Yellin, on its payroll, Google looked
away. Such conduct—proceeding with a “dangerous” course of action without availing oneself
4 There is no dispute that Google did have actual knowledge of the patents it infringed at least as
of July 20, 2010. RT 3100:10-20 (stipulation as to notice). Google argues that the period from
July 20 to August 13, 2010, when the lawsuit was filed, is too short to support a finding of willful
infringement. There is no such rule of law. See Walker Digital, LLC v. Facebook, Inc.,
CIV. 11-313-SLR, 2012 WL 1129370 (D. Del. Apr. 4, 2012) (refusing to dismiss claim for
willful infringement based on pre-suit knowledge where complaint alleged that plaintiff and
defendant discussed allegations of infringement just one month before the complaint was filed);
Power Lift, Inc. v. Lang Tools, Inc., 774 F.2d 478, 481-82 (Fed. Cir. 1985) (finding infringement
willful based on post-notice conduct where there were only 9 days between notice and filing of
of means to prevent harm, when those means are directly at hand—is the very definition of
Significantly, Google does not spend a single word of the willfulness section of its brief
trying to argue that it had credible defenses to infringement. Seeing the weakness of its position,
Google tries to go outside the trial record to argue that it asserted, in its Answer, what it calls
“sound legal defenses to those allegations.” ECF No. 1166 at 14. Even if that were evidence—
and it is not—the mere assertion of affirmative defenses is of no help to Google in avoiding a
willfulness finding. See i4i Ltd. P'ship v. Microsoft Corp., 670 F. Supp. 2d 568, 581-82 (E.D.
Tex. 2009) (“the number of creative defenses that Microsoft is able to muster in an infringement
action after years of litigation and substantial discovery is irrelevant to the objective prong of the
Seagate analysis”), aff’d, 589 F.3d 1246 (Fed. Cir. 2009), and aff’d, 131 S. Ct. 2238 (2011). See
also id. at 595 (“The fact that Microsoft presented several defenses at trial, including
noninfringement and invalidity, does not mean the jury’s willfulness finding lacks a sufficient
evidentiary basis.”). In any event, Google insisted that the evidence of willfulness be limited to
pre-complaint conduct, which the Court accepted. RT 3902:15-3903:17; ECF No. 1166 at 13-14
n.2. It cannot now turn around and rely on its post-complaint conduct to avoid willfulness.
All that remains of Google’s willfulness argument is the contention that it could not have
acted willfully because Jonathan Schwartz said kind things about Android in a blog post before
any of Android’s technology had been released, Larry Ellison said he was “flattered” by Android
before Oracle had even acquired Sun, and Eric Schmidt was of the “opinion” (a word that Google
excises from the quoted testimony) that “Sun management was comfortable that we had done --
that what we had done was free and clear of any intellectual property of Sun’s.” ECF No. 1166 at
15-16. This evidence of Google’s supposed state of mind would be relevant, if at all, to the
second, subjective prong of Seagate, not the objective prong. In any event, the jury plainly and
properly rejected that very argument in Phase 1 when it answered Question 4.B of the verdict
form with a unanimous “No.”
Finally, Google asserts, in a throwaway line, that Oracle “failed to introduce any evidence
sufficient to meet the requirements of the second, subjective prong.” ECF No. 1166 at 17. A bare
assertion such as this would provide no basis to award JMOL, but the statement is demonstrably
false in any event. The “objectively defined risk” of infringement described above not only was
known or should have been known to Google, the existence of that risk was established entirely
through Google documents and the testimony of Google employees.
The risk of infringement came as no surprise to Google. Google knew it was building a
Java-based solution that included a Java virtual machine. Google knew that it needed a license to
use Sun Java technology, and had no such license. TX 1 at p. 9 (7/26/2005: “Must take license
from Sun”); TX 3 at p.3 (7/29/2005: “Google needs a TCK license”); TX 7 at p.1 (10/11/2005:
“My proposal is that we take a license”) TX 12 (12/20/2005: “Either a) we’ll partner with Sun as
contemplated in our recent discussions or b) we’ll take a license”); TX 17 (2/10/2006: “critical
license”). Google knew that Sun was willing to assert its patents against Google. (TX 230, RT
3193:3-5 (Rubin) (“Sun had threatened Google before, in different areas of its business, on
patents.”). Google worried about the risk of “Java lawsuits” over patents and copyrights. TX
326, TX 406, RT 1559:20-1560:12 (Schmidt). Google decided that if it could not reach an
agreement with Sun, it would “Do Java anyway and defend our decision, perhaps making
enemies along the way.” TX 7 at p. 2. Having done just that, Google knew that Android was in
“dangerous territory” in dealing with Sun. TX 1029. On March 24, 2008, Mr. Rubin urged his
team not to demonstrate Android to any “Sun employees or lawyers.” TX 29. And on August 6,
2010, Mr. Lindholm needed little time to conclude, yet again, that Google needed to take a Java
license from Oracle for Android. TX 10. A reasonable jury could decide that Google’s conduct
For the foregoing reasons, the Court should deny Google’s motion for judgment as a
matter of law.
Dated: May 17, 2012
MORRISON & FOERSTER LLP
By: /s/ Michael A. Jacobs
Michael A. Jacobs
Attorneys for Plaintiff
ORACLE AMERICA, INC.