Our first report from the courtroom is here, and it seems real life has thrown a little tack in the road. One of the jurors had car trouble, so after the judge and the lawyers finished their early morning discussions and called for the jury, no jury. So, they waited. When the difficulty couldn't be resolved to get her to the court, she was removed from the jury by the judge. This is juror #2, according to the tweeting journalists. And then the closing statements began. The discussion before all that is a bit disturbing. Google apparently complained about Oracle's ambush tactics, and the judge laughed it off. It isn't so funny if you are Google. And not all judges find such tactics amusing, either. If you recall, SCO, represented by Boies Schiller, who now represent Oracle, were sanctioned by the court for trying to use
ambush tactics in SCO v. IBM. Actually, they were sanctioned twice. They kept changing what their case was about, presenting new allegations at the last minute.
Jump To Comments
[Update 1, Update 2, Update 3
Update 4, Update 5, Update 6
Update 7, Update 8]
The first Groklaw report:
Tue May 15 07:27:41 PDT 2012
Judge: Good morning.
Google: We have filed a couple of motions last night, asking for
direction and guidance on phase 3. Copyright damages are minimal
for nine lines of code and a few test files. It's clear now that
Oracle's strategy is to bring in our CEO and ask questions about
millions of dollars--
Judge: Those are all good issues, but we'll have time after the
jury deliberates.
Anything else that relates to what we've got to do this morning?
Google: I don't think so, Your Honor.
Judge: [to Oracle] Everything in the court set up the way you want?
You have all the equipment you need?
Oracle: [something about how all they need is the easel]
Judge: We here at the court had a debate on whether to spend federal
tax dollars on fancy equipment in the courtroom, and I was of
the opinion that we were spending too much, and anything we bought
would probably be obsolete in a few years and the lawyers wouldn't
want to use it anyway.
I rest my case. [laughter]
Oracle: This setup looks great.
Judge: I have been working hard on the order dealing with
copyrightability, and I don't think I'll have that in the
next week for sure. But in the mean time, I'm willing to
have an oral argument on it if it's what you want. Give
me your views on when you'd like further oral argument.
Google: As you know, we've filed several briefs on this. We can
talk about it more if you want, but I think we've covered
everything already.
Oracle: Same from our side.
...
[A little discussion about whether anyone wants to complain
about anything that's going to be presented in the closing
arguments, and Van Nest mentions something about an ambush.]
Judge: Ambush. Tried and true method. [smiles]
Some of you are old enough to remember the 1980s, and the S&L
crisis. Anyway, Joe [someone] had a trial, against some of the
accounting firms, and in his closing argument he played a clip
from a movie of the Titanic going down. [laughter] I think
that jury remembers to this day that closing argument.
[At this point we're ready for the jury, but they don't show
up, and after 15 minutes or so someone asks the clerk (?).
Apparently one of the jurors had car problems and got stuck on
the bridge; she's now waiting for Caltrain, so it'll be a while.]
Tue May 15 08:02:39 PDT 2012
While we wait for the next report, I'll tell you about Apple v. Psystar. We have a final ending. Remember when Psystar lost its appeal against Apple and vowed to take its case to the US Supreme Court? Well, the court today refused to hear the case, and so the appeals court ruling stands. This report from CNET's Josh Lowensohn:
The U.S. Supreme Court today denied Psystar's request to review a lower court decision that keeps it from selling computers that run Apple's OS X but that are not made by Apple.
The decision not to hear the case (PDF) upholds a ruling made by the U.S. Court of Appeals for the Ninth Circuit last September that Psystar's Mac clones violate Apple's copyrights....
Following a rejection of Psystar's appeal to that decision in September, the company's lawyers vowed to take it up to the Supreme Court. "This is far from over," K.A.D. Camara of Houston law firm Camara & Sibley, LLP told Computerworld in an interview. The company kept to its word, and filed for a review from the Supreme Court on December 27, 2011. And what is the moral of this story? That just because somebody's lawyer tells the media something big is going to happen, and there are headlines all over the place, it doesn't make it so.
Extrapolate. I'll tell you a secret. Lawyers talking to the media are talking on behalf of their client. Some of them sometimes say things they know are more braggadocio than reality. Our own Judge Alsup was the judge presiding over the Psystar case at the District Court level, so it is his ruling that was upheld by the appeals court. So what does it mean? It means Psystar can't ever sell Apple software on non-Apple hardware. They are permanently enjoined. It can't sell, manufacture, import, offer to the public, provide or otherwise traffic in any technology, product, service, device, component "or part thereof that is primarily designed or produced for the purpose of circumventing a technological measure", so this really is The End of Psystar's adventure.
Getting back to Oracle's adventure, I see Feldegast's more inclusive collection of people tweeting about the trial includes a patent agent, Simon Linder, who has a blog where he explains what's happening in the trial from his perspective. I don't know if he also will turn out to have a connection to Oracle or not, but there's no evidence of it, and I found his description of the trial on the days he attended informative and not obviously biased, although not precisely accurate in every detail (the trial began with Oracle asking for $6 billion, not $1 billion, for example). I expect a patent agent to be at least a little enamored of patents, but his work experience makes him better qualified than most to explain the patent claims, which he does.
Update:
And here's our second report from the courtroom, Oracle's closing statement:
Tue May 15 08:13:45 PDT 2012
[Update from the missing juror: apparently her car's leaking
antifreeze. She's headed back home right now, and she'll try
to find another car she can borrow. The clerk asked if she
could just take the train, but it sounds like she doesn't want
to because it's raining. There's general laughter and lack of
sympathy from the courtroom, and a bit of discussion on whether
we'll have to proceed without her.]
[PJ: May I just say, as a woman, I can totally relate?]
[Several minutes later, she calls again to say she's not going
to make it. The lawyers confer for a bit to decide what to do.]
Tue May 15 08:23:25 PDT 2012
[Judge returns]
Judge: The second juror has informed us that she's
not coming.
We have three options. If you want, we can send a US Marshal out
to arrest her and bring her back. [laughter] The second option
is we can dismiss her and go on. The third option is we can all
come back tomorrow.
I won't tell you what my opinion is-- well, actually, I will tell
you. I think we should dismiss her.
Google/Oracle: Sounds good.
[The judge sternly warns all the lawyers and press not to talk to
the dismissed juror. She's still obligated to keep all the jury
discussions she's heard confidential.]
[Jury enters]
Judge: May I make a suggestion that the four of you there scoot down
one chair, unless you think that will disorient you. [laughter]
[Similarly, warns the jury that juror #2 is no longer part
of the jury, and they're not to talk to her if they see her.]
Judge: So, we've lost 45 minutes on account of this, but I think we're
still okay for time.
[Judge reads the jury instructions.]
Oracle's Closing Statement, by Michael A. Jacobs:
Oracle: Thank you. It's easy to say "thank you", but I hope you've seen
evidence that both sides and Judge Alsup have tried to streamline
the case and make things easy for you.
Java bytecode! We've talked about Java bytecode in this trial;
even Java *programmers* don't learn about Java bytecode. We've
really dug deep, and I think you'll conclude at the end of this
that Google infringed, and it infringed willfully.
Three questions: does Google infringe the '104 patent? Does Google
infringe the '520 patent? And was Google's infringement willful?
On infringement, that in turn boils down to a set of focused
questions: does Android meet the claims? It's not based on things
like is Android open, or was Java dedicated to the public on some
day. It's just the claim language.
This process is now more focused than phase 1. There we had the
question of infringement, and Google's affirmative defense, which
you were split on. Here it's simpler: there is no affirmative
defense. Google has no excuse for what it's done.
There is no license. You know that from phase 1, and it's also
relevant to phase 2. Fair use is irrelevant. Open source is
irrelevant. Just the claims: does Google infringe these patents?
One thing you might say is, "Android's so big! It's 15 million
lines! How could it infringe?" That's a Google argument, something
you might hear from them. But it's not a defense if the product
includes additional functionality not included in the patent claims.
For infringement purposes, what's important is the ways in which
Android is relevant. The reason these patents are infringed is
that Google started out by adopting the basic Java architecture.
We talked about some of this before.
[Shows slide showing how source code goes through the compiler to
get to a device, either using the JVM or Dalvik.]
Google specifically tells developers to go to Sun, now Oracle,
and download the Java compiler. After that it's different; they
use dex, but they're still using Java.
...
We're not claiming all virtual machines. The question of prior
art isn't relevant. It doesn't matter that symbolic and numeric
references have been known for many decades. The claim is replacing
symbolic references with numeric ones. For example, "Courtroom 8",
that's a symbolic reference. Once you look it up, then you know
where it is, and you don't have to look it up again.
That brings us to the '104 patent. The inventor was James Gosling,
the father of Java. The original application was filed in 1992.
You might think, "Android, that's pretty modern! How could a patent
that was first described in 1992 be relevant to Android, which is
undoubtedly a modern cellphone platform?" The answer is that they
confronted the exact same problems that Java encountered on desktops.
You've heard about the cycles of the computing industry; they run
into the same issues on phones that they ran into on desktops.
With respect to resolve.c in the Java interpreter, the only issue
is whether the symbolic references qualify as symbolic references
because they're contained in the instruction stream. This 01 is
a symbolic reference, because it's contained in the instruction
stream. The next issue is whether the resolution of this reference
is a dynamic one, and it is.
We'll start with what's undisputed: Android resolves symbolic
references. You saw this in the source code, in the comments.
This converts symbolic references into pointers, which is exactly
what we have in the patent. This isn't disputed. Google admits
that Android resolves symbolic references. Google's documentation
says "the reference takes the form of an integer index value",
and they convert it to a memory address, which is almost exactly
what we have in the patent.
[PJ: Note the word "almost".]
Again, Google has to acknowledge that symbolic references are
converted to numeric references. The real question is whether
the instructions contain one or more symbolic references.
Let's talk about the definition of symbolic references. It's a
reference that identifies a location by name, instead of by
address. Now, there's some confusion about "name". This field
index is a number, can that be a symbolic reference? Numbers
can be symbolic references all the time: social security numbers,
the numbers on a uniform, [one more example I didn't catch].
All of these are symbolic references. They don't tell you how
to find the thing, you have to actually go look it up to find
its location.
Finally, Dr. August admitted that a number can be a name, and
can be a symbolic reference for the purpose of this analysis.
[His actual answer was "In general, yes."]
[PJ: And now you know what all that quibbling and repeated questions
to him by Oracle was all about -- to be able to say what Jacobs just said. Hopefully the jury recalls what Dr. August said.]
Now, what's the data that this is talking about? Is it talking
about the data in the constant pool, which is what Google wants
to focus on, or the actual data in the instruction? The answer
is in the claim language: it says "obtaining data in accordance
to said numerical references".
We proved this with Dr. August: he confirmed that the data we're
obtaining is the data in what the patent calls the data object,
which ultimately we labelled the "instance object" in the dex
representation. So what we're talking about is retrieving the
actual value of the data, which of course is what the programmer
wanted.
It's starting to become clear with Mr. McFadden's testimony.
This was the magic moment -- I almost had a Perry Mason moment.
Mr. McFadden acknowledged that the role of the iget instruction
is to obtain actual field data from an object.
The next step in the chain is the realization that Google wasn't
presenting a complete depiction of what's going on. This slide
doesn't depict the actual field value; it doesn't depict the
actual data object from which the data is being retrieved.
What Google showed you was some intermediate steps on the way
to retrieving the value. They told you to go to Courtroom 8,
and they showed you going to the directory to figure out where
it is, but you still have to look it up in the directory.
Mr. McFadden admitted that the actual field data was not shown
on the slide.
Dr. August acknowledged that to properly understand the iget
instruction, we have to represent the data object. [quotes
McFadden's testimony] So Google had presented a slide focused
on some intermediate steps that left out the most important
step of the process. What is iget's mission? It's to get data
from something that Google left off.
There's a clue lurking in here to show you which side can meet
its burden under the instructions. The fact that Google left
off this data object, and we had to add it on, is maybe a tip
that they wanted to hide something, and if you see it, the
infringement is clear.
The role of iget, and the role of the 01 contained in the
instructions, is to get data from the data object, and that's
why the 01 is a symbolic reference, because it doesn't point
directly to the location of that data.
There were errors in Professor Mitchell's report. You saw in the
video how it was pointed out to him, and he admitted that it
was a mistake. He didn't quarrel with it, or try to justify
it. In other portions of his report, he accurately stated his
opinion that the indices, such as this 01, were symbolic references.
It was an honest mistake.
90% of Google's examination of Dr. Mitchell was about the error
in his report. That tells you that they don't have any argument
against the rest of his report; it's unassailable. The fact
that Google was not able to elicit testimony from Dr. Mitchell
that contradicts it reinforces that we're right.
Dr. August was resisting the obvious technical fact that 01
doesn't refer to some random location; it's a very particular
location.
Look at the definition here: a symbolic reference is one that
has to be resolved. Dr. August said that 01 is not the numerical
memory location of the actual field data in the instance object:
"there's no arrow that directly connects 01 to the data object".
Mr. McFadden confirms that the resolver converts the instruction
stream index into a numeric memory location, a numeric reference
to the actual data. He admits that the 01 is not the numeric
memory address of the actual data, since if it were, there would
be no reason to convert it to a pointer.
All the witnesses agree on how this works. There was no
technical disagreement about the operation of this code.
At the end of the day, this poster from Dr. Mitchell and the
one from Dr. August are for all intents identical. The problem
was just this chart, which obscured the true meaning of 01.
It's not a memory location; it's like "Courtroom 8", a symbolic
reference which has to be resolved. And Dalvik does.
Google conceded that the resolution was dynamic. The only
issue is dexopt. Lots of witnesses referred to what dexopt
does as resolving symbolic references. Everyone seems to
understand what that is and agree that dexopt resolves symbolic
references into numerical references. Because that resolution
process depends on the conditions actually existing on the
handset, when dexopt runs, it's dynamic.
[PJ: Sigh. You will see when Google speaks that this isn't at
all correct, from Google's perspective or from any of our
techies' here at Groklaw.]
[Quotes an exchange he had with one of the witnesses, I think
it was Mr. Bornstein:]
Q: "If I mean by dynamic, depending on conditions of the handset
which can change from time to time, then this would be dynamic,
right?"
A: "Okay."
[Wow.]
Now, Mr. Bornstein did call this static linking. But it is
dynamic -- the fact that you label the sky green doesn't mean
it isn't blue. Bornstein wrote, "when a dex file arrives on
a device, it will have symbolic references, but afterwards it
might just be a simple integer vtable offset".
[PJ: In short, Bornstein did not agree with Oracle that it is
dynamic.]
What's really going on here is Dr. August is applying a special
meaning of "dynamic". Google would argue that it requires doing
these steps at runtime. But nothing in the court's construction
says dynamic means runtime; it simply means dynamic. We apply
what we all know dynamic means: changing, dynamic, active. Does
dexopt resolve symbolic references that way? Well, when you get
new system software on your device, dexopt has to rerun. That's
all you need to know to know that it's dynamic.
[PJ: So Oracle is using the terms in a way that doesn't match what
programmers mean when they say dynamic or static. If that is the
only way for Oracle to win, they deserve to lose.]
Dexopt processes the references while the Dalvik virtual machine
is running. There's lots of stuff going on. There's information
on the device that Android needs to run dexopt. That's what dynamic
means: getting information about the real device that the software's
on and incorporating that into the resolution process.
[PJ: That isn't at all the definition of dynamic. Not even close.]
Now, does the dx tool simulate execution? Trust what it says
in the source code. There's only one answer -- they're doing
this outside the ligitation context, so they're telling
technical truths. And Simulator.java is the main file here,
and it says it's going to simulate bytecode. It says almost
exactly what it says in the claim language.
[PJ: Again, even with his personalized definitions, he felt the
need to use the word "almost" once again. That ought to be fatal.]
Even Dr. Parr had to admit that the word "stack" appears nowhere
in the asserted claims. Now, there are other claims, which are
not asserted here, which do mention stacks. Google's arguing
against claims that we're not even asserting. All we need to
show is that they're simulating execution. Google says this is
pattern recognition, not simulating execution.
Say I'm at the grocery store, and I need to figure out the path
through the store to pick up all the things I need. [I didn't
catch the rest of this analogy, but it concluded by claiming that
pattern recognition is a kind of simulation.]
Dr. Mitchell says simulation can include pattern matching.
Simulation parsing, simulation pattern matching, it's all of
a piece. If you examine the code closely, you'll see that
the class Simulator calls parseNewarray as part of its process,
but it's still simulating. The developers knew what they were
doing when they labelled this "simulation".
Have we proven that it's more likely than not that the scales
tip ever so slightly in Oracle's favor on the '520 favor? We
have.
[PJ: Well, not to me. Not to anybody here at Groklaw, actually.]
You've made it through the technical part of this presentation.
Google's argument is really weak; Dr. Mitchell's argument shows
that the claims are met.
Now for willfulness. The standard here is a little higher --
it's not "beyond a reasonable doubt", but it's "clear and
convincing evidence", which is midway.
[PJ: Midway between what and what? It surely means more than 50-50. Our reporter emailed me to clarify: Midway between the "preponderance of the evidence" standard used
earlier for the infringement questions and the "beyond a reasonable
doubt" standard that the jurors have seen on TV.]
We need to decide whether Google was reckless here, given all
that they knew or should have known about Sun's IP rights and
patents.
Patents are right there in the Constitution. Patent protection
is a vital part of an idea-driven economy. You can tell by the
resources devoted to this trial how important this case is, and
how important these patents are. You heard how important Java
is, and these patents protect that. Oracle has dramatically
expanded its investment in Java, nearly doubling the number of
programmers. How do we protect that? Patent protection.
[PJ: I would just like to remind everyone that when Sun owned
the patents, its CEO publicly stated that it viewed patent
aggression as a sign of failure.]
Now, did Google, knowing that they were copying aspects of Java,
copying parts of Java into Android, were they recklessly ignoring
these protections?
Recklessness is something like driving the wrong way down a
one-way street. You don't need to know which car you're going
to hit; you're still driving recklessly.
Everybody else has a license. You've heard about all the
different forms of license. They're not just for copyrights,
etc.; they also license patent rights. So Google's stepping
into a world where everyone else has a license.
[PJ: Which is why, speaking of damages, it's so ridiculous to me to claim that when Sun and
Google were negotiating about a joint project, the patents
would have been worth hundreds of thousands or millions. All
Google had to do was use Java, pass the test for compatibility,
and they got the patents as a freebie.]
They adopted Java platform components and concepts in Android.
They could have gone in a completely different direction, but
they didn't. The Java compiler is part of the Android development
package. The Android SDK says to go to the Oracle site and
download the compiler. Now, we're not arguing that that act
alone represents infringement of our IP. But Google didn't set
out to develop something independent, where the risk of patent
infringement is more or less random. They set out to develop
something based on Java.
[PJ: However, they designed their own compiler, using different
technology altogether.]
Mr. Rubin said they referred to Dalvik as a Java Virtual Machine,
even as late as 2009. Even when they changed the instruction set,
it was so similar to Java that they referred to it as a Java VM.
What was Google's motive? They needed to overcome the same
performance problems that the Java developers faced ten years
earlier. Brian Swetland: "If the device is not fast and stable
we FAIL". Everything on mobile needs to be more efficient and
more exact. Speed matters -- milliseconds matter to users.
[PJ: Like Google needs the Java compiler to write its own, or
anybody's code, for that matter, or their patents.]
They implemented the features in this patent because it makes
the device run faster. This is what Mr. Bornstein said (TX-816).
That's why we do reference resolution. He's describing, almost
word-for-word, the claim language. They do it to make the device
run fast.
[PJ: There's that fatal word again, "almost". Almost isn't
good enough to prove a patent claim.]
There was a lot of data about benchmark testing, whether it's
accurate or fair. Dr. August acknowledged that the benchmarks
Oracle used to test the '104 patent were standard benchmarks,
and he even acknowledged that Google uses them too. And of course
he'd done no performance testing of its own.
Google's own tests said what they do. [Quotes a Google email
saying they convert constant pool indices in instance field get/put
and virtual method calls to byte offsets and vtable indices,
respectively. Later in the same email, it mentions a 20% speedup.]
Why did they do this? 750k daily activations of Android phones.
This was the motive. This was the motive to avoid looking at
whether Sun's patents might be infringed. Google did everything
they could do to avoid finding out the specifics of these patents.
They employed the key inventors: Tim Lindholm and Frank Yellin.
[Something about a book they coauthored, which mentions the
content of the patent?]
Andy Rubin: "They're inventing IP, they're protecting it through
the patent system. Through GPL, I didn't know what they were, but
I knew it was dangerous to [didn't catch the rest]".
[More Andy Rubin quotes, showing he knew Sun had Java-related
patents.]
Clean-room development isn't relevant to patents. Mr. Rubin had
to acknowledge this: a clean-room approach doesn't protect against
patent infringement.
Andy Rubin never asked Tim Lindholm to conduct any investigation
to see whether Android infringed any of those Sun patents.
[PJ: The law doesn't require that. Mr. Jacobs neglected to
mention that. Blech.]
Mr. Rubin never asked anyone on his team to do a review of Sun
patents. Their defense is "we didn't know"; it's a head-in-the-sand
approach.
Google had choices. They could have taken one of the licenses
that Sun offered, which would have included grants of the patent
rights. Google's argument is that they were talking about licensing
Sun's code, but they didn't do that. They could have taken the
specification license. The specification says the virtual machine
is protected by patents. They could have taken the GPL version of
Java. That would have granted them patent rights. [!] There was
some concern there by Mr. Rubin that maybe Sun would say patents
weren't included. But that wasn't why they rejected the GPL; it's
because the GPL is viral, and the carriers wouldn't accept that.
That's not the issue here, though. He had a GPL option, and he
didn't take it. [PJ: When Google began to develop Android, there
was no GPL Java. That came later, so this is silly as an argument.]
Scott McNealy: "'Open' does not mean throw it over the wall in
a public domain, right-equivalent-to-ownership perspective."
"Open" doesn't mean without restrictions. It's another way of
making software available under a license that grants rights and
imposes obligations.
Judge: You have an hour and fifteen minutes total, but I just wanted
to let you know you've used an hour and five minutes.
Oracle: Thank you.
Did Google try to cover up its infringement? There were messages
internally to the team about not showing Android to Sun employees
or lawyers, TX-29. [Cites a bunch of emails where Android people
discuss licensing Java.]
[Shows emails from April 29th, 2009, where Sun says they need a
license and Google says they should only respond if Sun chases them.]
On July 20th, 2010, Oracle told Google they were infringing the
'104 and '520 patents. Right after that meeting, Rubin did not
instruct the team to make changes. They looked at their choices,
and Lindholm told the senior executives that their only choice
was to negotiate a license.
[PJ: I'm sorry but this is a gross misrepresentation of the evidence.
Lindholm is an engineer, not a lawyer or an executive. He was asked
to look into what else they could switch to, now that Android was
already out in the public's hands. That's not the same as the hundreds of choices that Google testified they could have used in the beginning, had they known Oracle would buy Sun and start to alter the horizon. And Google has testified that they believe they don't infringe these patents. That could explain why they made no changes. Duh.]
[Jury leaves on break]
Judge: Any issues for the court?
Google: I don't believe so. How much time do you have left for Oracle?
Judge: Six minutes.
[recess]
Tue May 15 09:46:58 PDT 2012
This was not Oracle's finest hour and five minutes.
Update 2: Here's Google's rebuttal: Tue May 15 10:02:23 PDT 2012
Google's Closing Statement, by Robert Van Nest:
Google: On behalf of everyone at Google, we'd like to thank you for
your services as jurors.
I have to take indirect responsibiltiy for juror #2 not
being here. Just this morning, I said to the team, "It's
unprecedented to be here, on a five-week trial, and no one's
been late!" [laughter] I should have knocked on wood.
The features in Android that are accused are fundamentally
different than the '104 and '520 patents.
They were designed
from scratch by Google engineers, built to work on a smartphone,
and without any reference to the Sun patents. No one was aware
of any of those patents when Dalvik was built. As a result of
the differences between the features and the patents, Oracle
fails to meet its strict burden to prove patent infringement.
Judge Alsup has told us over and over that this case is not about
Java versus Android. We're dealing with two specific patents with
some very specific requirements that have to be met. I'm not sure
why anyone's talking about Java; Java's free, anyone can use Java;
it's not even mentioned in the patent.
In order to prove infringement, Oracle has to show that every
single element in the claims they're asserting are found in Android.
There are really only three points.
First: the '104 patent requires that symbolic references be used
in the instructions. Android never uses symbolic references in
instructions. It uses numeric references: indexes to locations
in memory. There are no symbolic references in the instructions
in Android.
Second, the '104 patent has a second strict requirement: if you're
going to resolve a symbolic reference to a numeric reference, it has
to be done dynamically, not statically. Dexopt, as you saw, is a
static operation. It runs when you install an application on your
phone, not when you run the application.
Finally, the '520 patent requires simulated execution. Pattern
matching isn't the same thing as simulated execution. [...]
We shouldn't be surprised that Android is different. There's not
a shred of evidence that Google had access to these patents. Now
you've seen evidence that before July of 2010, even Oracle hadn't
mentioned these patents to Google. The whole time Google was
developing the software, and publishing it on a website, there's
no evidence of any awareness of these patents.
Oracle didn't bring in a single Sun engineer or witness to talk
about why these patents were invented or what they do. Their
entire case rested on Dr. Mitchell, and his testimony is simply
not reliable. Not because he made mistakes, but because he
changed his opinion on the most fundamental issue of the case.
His opinion was that Android used numeric references, and after
he saw Dr. August's report he changed his opinion.
Why? Because they are numeric references! They're not symbolic
references, as required by the patent.
I'm going to walk through, patent by patent, feature by feature,
and show that the only verdict that's supported by the evidence
is a verdict of non-infringement.
Google made fundamentally different design choices for Android.
We don't need to talk about licenses, or Java; it's all about
infringement.
Dalvik doesn't infringe the '104 patent, because it always uses
numeric references. And when dexopt resolves the references
outside of instructions, it does it statically, not dynamically.
Google developed Android independently. There's no evidence
that they knew anything about the patents. You're talking about
a footnote in a book ten years ago? Come on.
Let's start with the '104 patent.
I'll say right now: question 1 on the verdict form is the most
important question in phase 2.
The instruction set in the accused device must use symbolic
references, in the instructions. It refers to "said instructions
containing symbolic references". Dr. Mitchell conceded it; if
you asked him last week, he'd agree.
I don't know why they're talking about the Java compiler. Anyone
can use the Java compiler -- there's IBM's compiler, there's the
GNU compiler, there are lots of them. I don't even know why they
brought it up.
Dr. Mitchell conceded that if you don't use symbolic references
in the instruction, you don't infringe.
[Quotes the claim construction definition of a symbolic reference.]
Remember "the White House"? That's a name. "y", that's a name.
"fun", that's a name. But "1600 Pennsylvania Avenue"? That's an
address.
The '104 didn't invent symbolic references, or numeric references,
or resolving them. It's a very specific patent, focused on a
specific type of resolution. It requires that the symbolic references
be contained in the instructions.
[Points out the instruction "LOAD 'y'" in the example in the
patent, and talks about how "y" is an actual name that has to
be resolved.]
But 2 isn't a name, and it doesn't have to be resolved. It tells
you exactly where the data is. You don't have to search. And
that's why Android uses numeric references: they're faster.
Dr. Mitchell admits that the Court's claim construction distinguishes
between using names to represent data and using numeric memory
locations. It's not about the ultimate data item you eventually
want to retrieve -- it's the reference in the instruction.
[Quotes Mr. Bornstein's testimony, where he says dex files do
contain symbolic references, but they're not in instructions.]
They've been waving around lots of stuff saying "look, they have
symbolic references". That's not relevant. The question is whether
they're in the instructions.
And the reason they're not in the instructions is that Dr. Bornstein
wanted the instructions to have a fixed width. If you use names,
you have all sorts of different lengths, so it doesn't work if you
want something really efficient.
TX-737. These are the Dalvik VM instruction formats, written in
2007. There's no question about it: in page 3, you can see what's
being used in the instruction is an index. There's an operand A,
and an operand B, and an operand CCCC -- what's that? It's a
location. It specifies that the data is found at location CCCC
in the table.
[Shows several examples of Dalvik instructions, and points out
how they always contain numerical indices, not names.]
Why does it say thing@CCCC? It's because it's at a particular
location, location CCCC. Why else would you use "at"?
Mr. McFadden said there are a few different types of indexes:
some are type indexes, some are field indexes. But they're all
memory locations. You've heard that a symbolic reference has
to be resolved. These don't have to be resolved; they tell you
exactly where to go. [Quotes Mr. McFadden's testimony: "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."]
Everyone can see the Android code, it's open source.
Now, are we saying a number can't be a name? No, we've never
said that. But these numbers are locations: they give you the
exact position in the table. [Works through the same example
of instruction -> field ID -> string ID -> string data we saw
earlier.]
The only thing dexopt ever uses is indexes into memory locations.
[Hides the latter part of the example, leaving only the instruction
and the field ID table.] Now, why did I hide the rest there?
Because it's not relevant. That stuff is all data. All we care
about is what's in the instruction. Now, if you wanted, you could
add in all that extra data, and even more, like the object itself.
But none of that is relevant here.
TX-47.2, line 621: these all have the form "op vA, vB, field@CCCC".
Why is it @CCCC? Because that tells you where it is. You don't
have to look it up, its location is right there. This wasn't
written for trial, this was written back in 2008.
The optimizer replaces method indexes with vtable indexes;
it replaces field indexes with byte offsets. The instructions
only use indexes, because it's more efficient that way.
[Quotes Dr. August: "I've looked at every single implementation
of the instructions, and I can say with certainty that there is
not a symbolic reference in any of the instructions. You'll
never see an 'x' or a 'y' [...]".]
[Shows something from Dr. Mitchell's report, where he had
identified classIdx as the infringing element.] But he admits
that classIdx is an index, which tells you where to find the
data. [Quotes Dr. Mitchell's testimony.]
[Points out several places in Dr. Mitchell's report that refer
to classIdx, methodIdx, etc. as "numeric references".] That's
why he changed his opinion after he saw Dr. August's testimony:
he realized he was dead in the water, since the symbolic references
weren't in the instruction.
[Points out more places in Dr. Mitchell's report that refer to
the first-level references in the instructions as numeric
references.] I wouldn't criticize someone for making a *single*
mistake.
Dr. Mitchell wants to rewrite the claim construction to replace
"data" with "the actual field data in the instance object".
The reference in the instruction only points to the field ID table;
he's admitted that, and everyone agrees with it. Now he wants
to say he was talking about the data in the instance object
instead.
Dexopt, like resolve.c, only uses indexes in the instructions.
But there's a second reason dexopt doesn't infringe: because
when dexopt resolves those references (outside of the instructions),
it does it statically.
By the way, they're the ones who want to claim "dynamic" means
runtime; that's what Dr. Mitchell said. He concedes that if this
function is performed statically, then dexopt doesn't infringe.
[Refers to his example of downloading an Amazon app to compare
prices.] No advertising here, I'm just going to refer to it.
[laughter]
So, what happens when we download this app and install it? You
get a dex file, and dexopt runs to optimize it. Then it's done.
You might use the app a week later, or a month later, or you
might never use it. Hey, it was a free app. This is all done
at install time; it's a *static* process.
Dexopt doesn't run when you *run* the program. Dexopt has already
finished its work. It's not a dynamic process, in any meaning of
the term. [Quotes Dr. August saying dexopt runs and must run before
the program executes, so it's static.]
Here's a quote Oracle showed you earlier, out of context. This
is something their lawyers did:
[Shows slide: "when a .dex file arrives on a device it will have
symbolic references ..."]
Let me show you the words that were right before that, in the
original document:
[Text fades in, immediately before: "As an example of static
linking,".]
That's what they didn't want to show you.
Here's a book: "Bytecode for the Dalvik VM". There's a thriller.
[laughter] You'll have this in the jury room, you can look at it.
...
There is overwhelming evidence on question 1 that the Android
features don't come close to infringing the '104. [Shows a slide
with Dr. Mitchell on the left, as the evidence of infringement,
and Dr. August, Mr. Bornstein, Mr. McFadden, a big pile of trial
exhibits, and Dr. Mitchell's slides on the right as evidence of
non-infringement.] Even Dr. Mitchell's expert report takes the
position that indexes are all numeric references. That equals
non-infringement.
That's why I say the evidence supports only one verdict on question 1.
Since there are no symbolic references in the instructions, and since
dexopt is not a dynamic optimizer, Oracle fails to meet their burden
of proof.
If there's no infringement, you don't need any other excuse.
I don't know why they're talking about fair use, open source,
or whatever. If there's no infringement, there's no infringement!
Let's talk about the '520. The parties both spent less time on
this. It involves a very insignificant feature. It deals with
only one thing: you've heard about these arrays, which are lists
of numbers, they have to be organized so they don't slow the whole
system down. Something, the dx tool in this case, has to initialize
the array.
This patent is focused on, and limited to, a very specific form
of this initialization. It requires simulating execution of the
byte codes of the clinit method [he spells it out, as "c-l-i-n-i-t"].
Dr. Parr says there's no meaningful definition of simulating
execution of a stack machine without manipulation of a stack.
The examples in the patent confirm this.
Oracle: Objection. You're reading the specification into the claim.
Google: I haven't said a word about that. I called it an example,
it's an example in the patent.
Judge: Most patents have examples. The law is quite clear that a
patent doesn't just cover the examples, it's what's stated in the
claims themselves. With that understood, you can talk about the
examples, but the jury must remember that the patent claims are
not limited to the examples.
Google: Now, you'll notice that there's no reference in the patent
to the phrase "pattern matching". What does appear is "simulated
execution". In this example of simulating execution, it creates
a stack, pushes onto the stack, etc., and Dr. Mitchell confirmed
that.
Now, that isn't what goes on in Android, since it's conceded
that Android's dx tool uses pattern matching. Since Android
uses pattern matching, that's how they identify the data in the
array.
[Shows the parseNewarray comments, saying it tries to match the
pattern of the array initialization idiom.]
[Describes Dr. Parr's experiment where he made the pattern-matching
fail by altering the pattern.]
Simulated execution doesn't care
what the pattern looks like, since it just simulates whatever's
there. If you're simulating execution, which is what the patent
requires, this will work just fine. But if this is pattern matching,
he said, this won't work. Remember the word he used in the source
code, "punt"? That's what happens, it fails. And that's what
happened. That was unrebutted. There was no response from Dr.
Mitchell, except for handwaving about the Simulator class.
We talked about simulation in the dx tool. Now, it uses simulation
a lot. It uses simulation everywhere except where it counts: for
array initialization. For that, it calls into a different class.
It's different code, in a different file. The one place in the dx
tool where simulation does not occur is finding the initial values
of an array. The patent *requires* simulated execution; Android uses
pattern matching. The patent doesn't mention pattern matching at
all, not even once.
So, what's the score? The evidence strongly favors non-infringement.
The only testimony from Oracle was Dr. Mitchell. On the other side,
you have Dr. Parr's testimony, Dr. Bornstein's testimony, etc.
They've failed to prove that the dx tool meets every step required
in the '520.
Now, that's where I think your deliberations will end, because if
you answer question 1 "no", and question 2 "no", then you don't
even go on to question 3. But like I said in phase 1, as Google's
lawyer, I can't leave any stone unturned, so I'll talk about willful
infringement a bit just in case you get there.
Nothing about Android was secret: everyone knew it was using the
Java language, Java APIs. The source code was public, published
for the world. What was Sun's reaction? You remember that. The
rocket. Their reaction wasn't "Oh, what terrible infringement",
it was "Wow, you've strapped a rocket to Java".
You now know this blog was the official statement of Sun! [Quotes
something showing it was official; I didn't see it but I couldn't tell if it was the SEC
filing or the blog post saying Welcome to the Java community.]
Remember the demonstration that Klein did, at Java [something] '08,
showing Java FX running on Android? Why would Sun be doing that
if they thought it infringed? Sun and Google were working together
on this for years. It was on July 20th, 2010, that they first gave
notice of these patents to Google, and they filed the lawsuit three
weeks later.
Oracle said we had our heads in the sand. Why would we go search
out patents when Sun, the patent holder itself, is telling us
"Welcome to the community"?
...
[Something about how the references to "patent protection" were
protection for the OEMs who ship Android.]
[Plays video from Rubin deposition.]
Q: Was there a common understanding that it was not a good idea to
look at Sun's patents?
A: I don't think it's a good idea to look at any one company's
patents, it's a waste of time. Engineers aren't lawyers, it's
complicated. I don't recommend that my engineers waste time with
that.
Q: But was there a common understanding that it was not a good
idea to look at patents during the development of Android?
A: If there was, it wasn't an ostrich-style "don't look at it
so we don't know", it was that we didn't have the time to look
at all the patents.
[end of video]
When I sit down, I won't get a chance to stand up again. I'm
sure I missed something, I'm sure I forgot something along the
way, and I'm sure Mr. Jacobs will point those out. But what I
want you to remember is that Google made fundamentally different
design decisions for Android, and that means three things:
Android uses numeric references in its instructions, not
symbolic references. Dexopt runs statically, at install time.
And the dx tool uses pattern matching, not simulated execution.
The next point is undisputed: Android was developed independently,
and no one on the design team ever saw Sun's patents. Android
does not use Sun's technology.
All right, good luck with your deliberations. Thank you, Your
Honor.
[rests]
Judge: Any issues for the court?
Google: Not here, Your Honor.
Judge: [to Jacobs] Now remember, six minutes.
Oracle: I've got a clock.
Tue May 15 11:13:20 PDT 2012
Update 3: And now we have Oracle's six-minute rebuttal:
Tue May 15 11:31:31 PDT 2012
Oracle Rebuttal, Closing, by Michael Jacobs:
Oracle: They're still not telling you the whole story. The whole
argument turns on this being data. Both experts agreed that
it was properly labelled as a constant pool. And Mr. McFadden
specifically acknowledged that the field ID table is not stored
in the data area of the dex file. "Answer: it's not stored in
the section labelled 'data'."
The question here is the difference between meaningful data
and non-meaningful data. A non-infringement argument that relies
on non-meaningful data makes no sense.
They had more witnesses. They had more documents. We called
Mr. McFadden! We called him in our case, because we knew he
would tell us how the code works. We called Mr. Bornstein, he
was a bit more evasive [...] Trust the documents. They
prove our case.
Let's take a quick look again at TX-1029. This is an exchange
I reported on briefly in my initial comments; look at what Tim
Lindholm is saying to Dan Bornstein. "Actually, having said that
I wonder whether this is too close to dangerous territory."
It is true that Oracle brought specific patents to Google's
attention in July 2010. But that's not the same thing as saying
Google had no access to them. We know Tim Lindholm wrote about
one of those patents in his textbook. [Quotes the textbook,
chapter 9, which says "This technique is covered by patent
5,367,685."]
Access? Google organizes the world's information! Of course
they had access to the patents.
Thank you again for your attention.
Judge: The judge invites any members of the public who would like
to leave before the reading of the jury instructions to do so
now; otherwise you have to stay to the bitter end. I don't want
anyone getting distracted with all the people getting up and
moving around.
[Judge reads the jury instructions. When reading the bit about
willful infringement, he accidentally swaps "Google" and "Oracle";
Van Nest points it out, and he rereads it.]
Judge: Any issues for the court?
Google: Oracle has asked us to make our CEO and [someone else] available
to testify about these nine lines of code, and--
Judge: What is the point?
[A brief exchange, which I missed]
Judge: First we need to get all the exhibits into the jury room,
and it's now almost noon... at 1:30 could we reconvene to hear
this motion?
But listen, it doesn't matter that they want to get your top
people back here, unless you have a legitimate legal reason
for postponing it, which I will of course hear. But the fact
that Mr. Big is being subpoenaed, well, this is a big case.
What I'm more worried about is how they're hoping to get
anything other than statutory damages for nine lines of code.
Google: The fact is that these witnesses don't have anything to
say about those nine lines of code. But we'll talk about it
later.
Judge: All right. We'll take a break now, and we'll reconvene at
1:30.
Tue May 15 12:01:29 PDT 2012
Our reporter will be staying for the afternoon motion hearing and just in case the jury reaches a verdict today, so stop on back by. And you can find the jury instructions being read in Mark's article, along with the rest of the most recent filings.Update 4: And now Rachel King has tweeted that the jury is going home for the day. So no verdict today. They'll meet again in the morning. Caleb Garling tweets that during the motion hearing, the judge told Oracle's David Boies that the infringer's profits is a ridiculous argument:
Alsup tells Boies Oracle's only doing damages because they haven't won anything else and they're in a fix. "This is a fishing expedition."...
Alsup says he's been writing code since this trial started. He's written rangeCheck code a "100 times". Incredulous Oracle claiming damages.... Yes, the judge has been learning to code in Java during this trial! And Rachel King has more tweets:
Alsup to Boies: You're one of the best lawyers in America. How could you even make that argument?...
Alsup just shut down Boies on Google using rangeCheck to speed up Android release, saying anyone could do it....
Boies recognizes if he loses infringer's profits and then everything else, Oracle gets ZERO $$ And the judge will think it over and rule on the issue. But not today. Rachel King again:
The #OraclevGoogle press corps agrees: This trial is a mess. Well, that depends. If you are Google, things are going great. If you thought, maybe because of paid Oracle spokesfolk that Oracle had a strong case and was sure to win billions because Google was doomed, maybe you need to think about who you listen to and believe instead of concluding that things are a mess.
Maybe such reflection will help the headline writer for this
article in The Verge. The headline doesn't much match the bulk of the article's content, with its decidedly anti-Google tilt. Meanwhile the article states that Mr. Van Nest had the better closing statement. That should have been the headline, which instead is, "Oracle: Google had its head in the sand with alleged patent infringement". Read the article, and you'll see most of it is about Google's effectiveness, even saying that in Oracle's rebuttal, the lawyer seemed defensive, even desperate. If I were Google, I'd be wondering what the explanation is for all the negativity in the media.
If Google didn't infringe, it doesn't matter if it researched patents, by the way. Just so you know. Like I said, lawyers say things on behalf of their clients. It doesn't make them so.
Update 5: Our final report of the day, including the motion hearing on infringer's profits, with Oracle arguing in essence that it shouldn't end up with nothing:
Tue May 15 13:31:00 PDT 2012
Judge: Back to work. There's a motion.
Google: Thanks for making time.
The issue for phase 3 is what Your Honor has said over and over:
this is not Android vs. Java, it's more particular than that.
Android wasn't found to infringe Java. What was found to infringe
was the two TimSort files, containing nine lines of code, and the
eight test files.
It was Oracle who asked for the files to be defined in that way,
because they didn't want the material to be defined as the entire
Java platform and risk a de minimis verdict. But now they're trying
to turn that around for damages.
Mackie vs. Rieser, 2002, 9th circuit: The infringing material was
one photo incorporated into a collage promoting a symphony. The
brochure wasn't sold, it was given away to promote the symphony.
What we have here is very similar: Google gives away Android, but
they use it to promote ad sales and application sales. And here
we have a much smaller portion of infringing content (nine lines
vs. 15 million). They can't tie any amount of revenue to the
specific files that were infringed, which are the works for the
purpose of this case.
Oracle: [Boies] Let me begin with one legal point, one factual point,
and one point about what we're claiming.
First, what we're claiming: I constantly hear about how we're
claiming billions or hundreds of millions of dollars for nine
lines of code. We're not claiming billions of dollars. But we're
claiming it's not zero, and we claim that they have the burden of
proof. We're not claiming that we're entitled to all, most, or
even a large percentage of all the profits for Google.
The legal point: there's no case, none, in which there's been
proven a product that was containing copyright infringing material,
that was distributed, revenue generated, by the defendant, where
it was held that the burden was still on the plaintiff to go
forward. That's the clear intent of 504(b). In Mackie, the
defendant was not selling the infringing product. [something
about Polar Bear]
Here, Android includes copyright infringing material. The
Bucklew case, 7th circuit, says the purpose of infringer's
profits is to make infringement worthless. You don't do that
by saying that if something is small, there are no damages.
It's not a question of how large the damages are. It's whether
we should be precluded as a matter of law from seeking infringer's
profits because the amount of infringing material is small.
Third fact: it's not clear to me that the right comparison
is nine lines vs. 15 million, since 10 million of that is the
Linux kernel. But still, nine lines is a small percentage.
The test files are much more substantial, but they're not
included at least in the current version of Android.
But both of those benefited Google. It accelerated the time
in which Android could be finished. The timing of Android
was critical; we've demonstrated that to a limited extent
already, and we'll demonstrate more in phase 3. They wanted
it faster, faster, faster. This copying allowed them to use
fewer resources and accelerate that. Suppose they accelerated
it two days. They're making $3 million a day now, activating
700k or 800k phones. [something about how Google estimates
they make $8 to $10 per activation] If you just get one or two
days' acceleration, that's $6 million or $7 million, and it's
not something that's untethered from the value that's created.
What they want is to say that if something is small, you don't
get any infringer's profits. We think that's contrary to the
statute and to the policy that makes infringement worthless.
Yes, someone else could have written that code, but how long
would it have taken?
Judge: You're required to make an election. Are you now saying
you elect to try for 504 damages and profits and not statutory
damages?
Oracle: Yes, Your Honor.
Judge: And you recognize that if you lose--
Oracle: I recognize that if I lose this, zero.
Judge: And if you lose this case, think about the costs alone,
you lose everything. And I expect that the amount of taxes
and costs in this case, there will be a lot of them.
Oracle: [something about tactical decisions] We think, as a matter
of principle, that we're entitled to infringer's profits.
We've thought about the fact that if we lose this, and lose
the other, we're in a position of not having won anything.
We thought about taking statutory damages for one and infringer's
profits for the other. But we think, as a matter of principle,
that we didn't want to send a message that if you take something
that's small and you're a big company and can afford to litigate
thoroughly, you can get away with just statutory damages.
Judge: Does your expert call out these items and trace out a nexus
from those to the profits you have in mind? I think the answer
is no, but maybe I don't understand the expert.
The law requires you to prove a causal nexus between the
infringement and the body of profits that you're seeking.
How do you propose to prove that nexus?
Oracle: I think the law with respect to infringer's profits, rather
than damages, only requires us to show that there was a product
that contained infringing material and that the product produced
revenue, and then the burden shifts to the other side. If I'm
wrong about that, I still think it's possible to demonstrate a
nexus by showing that speed was very important to Google in
getting Android out, and by copying they accelerated that.
Judge: We heard the testimony of Mr. Bloch. I couldn't have told
you the first thing about Java before this problem. I have
done, and still do, a significant amount of programming in other
languages. I've written blocks of code like rangeCheck a hundred
times before. I could do it, you could do it. The idea that
someone would copy that when they could do it themselves just
as fast, it was an accident. There's no way you could say that
was speeding them along to the marketplace. You're one of the
best lawyers in America, how could you even make that kind of
argument?
Oracle: I want to come back to rangeCheck.
Judge: rangeCheck! All it does is make sure the numbers you're
inputting are within a range, and gives them some sort of
exceptional treatment. That witness, when he said a high school
student could do it--
Oracle: I'm not an expert on Java -- this is my second case on Java,
but I'm not an expert, and I probably couldn't program that in
six months. Let me come back to rangeCheck after I've reminded
the Court about the test files.
These test files were created by decompiling the Oracle code --
Sun code. That was not an accident, and not something they did
by mistake. They did it intentionally, and they did it for the
purpose of saving money, or time, or both. You can't look at those
decompiled files and say there's no meaning in that; it accelerated
Android, that's why they did it.
[PJ: Let me remind everyone that the testimony was that a contractor, Noser, did it, and it did it contrary to specific instructions from Google.]
Let me come back to rangeCheck. Every time I talk about this,
I feel like I'm either saying it's important or it's not important.
That's a false dichotomy. No one can say it's a big thing. But
it was something that was copied, and it was important to TimSort,
which had a significant performance advantage. Now they could have
done it a different way. If you take a nine-line copyrighted poem,
and you pick it because it's available, and you publish it, and no
one buys your anthology because of the poem, and you could have
gotten another poem in five minutes, it's copyright infringement
and you're entitled to infringer's profits.
Now, I accept that this is a much harder argument for rangeCheck
than for the other files. My point is mostly a matter of principle,
that I think we're entitled to make a case for infringer's profits.
If I were just trying to do something tactical, like I'd take statutory
damages for rangeCheck and infringer's profits for the other files,
frankly I think the Court would think I was playing games. I think
the case for infringer's profits on the decompiled files--
Judge: But where's the nexus?
Oracle: They were using this to test and produce Android!
Judge: [missed the question]
Oracle: That's what I'm going to be asking these people [the Google
executives they want to bring in].
Judge: So this is a fishing expedition?
Your side did no discovery on this prior to trial, this was
a non-issue, just for coloration, and now you're in the fix
that you haven't won anything over that, and you want to make
it into a federal case -- well, it is a federal case [laughter] --
but you want to make it into a bigger federal case.
Oracle: We have testimony from both experts about the test files.
In addition, I agree with you; nobody thought we'd be going
to the jury on these particular issues alone. Nobody thought
the jury would hang on fair use. We had suggested that this
all be put off; I'm not going to reargue this, but we think
it's wrong to send this to the jury alone.
Judge: Well, if I rule against you on copyrightability, then even
question 1 and 1a is moot.
Oracle: Yes, it is. And one of the things I suggested is that these
two tiny issues should not be the single subject of phase 3.
For example, if you decide against us on copyrightability, this
will resolve the issue--
Judge: It won't resolve rangeCheck. That's still there, and I don't
want to be stampeded into making a decision. I have a lot to read
before I can tell you what the answer is on the big issue.
So in the meantime, we have to get through the rest of phase 3.
We're in this position where I think you are making a huge stretch.
[Boies tries to say something, but the judge cuts him off] I've
got a criminal calendar to go to in a few minutes.
Oracle: Can I make one suggestion? I haven't talked to my client,
sometimes my clients shoot me for these things, but let me make
a proposal: put off sending this to the jury, and if it's determined
that there's no copyrightability for the APIs, we'll take statutory
damages for these two things and not make an infringer's profits
claim. If it turns out we eventually go to the jury on the API
damages, we'll seek infringer's profits at that time.
Judge: Well, who would try that part of the case? Say you lose
on the API, who would decide the amount of statutory damages?
Oracle: [momentarily flustered] I'd stipulate to whatever the court
does. I'd waive the jury on that.
I'm just trying to work something out here. It makes no sense
for us to try these two tiny issues in front of the jury. On the
other hand, as a matter of principle, I don't think it's right
to relieve them of the obligation under 504(b).
[Purcell steps up to respond]
Judge: Mr. Purcell, I don't have time to negotiate with you, but
I have a two-part ruling for you, it's called modus vivendi.
You can look that up in that file cabinet of yours. [laughter]
It means a way to muddle through, at least for today.
First, Oracle should submit tonight a detailed nexus for the
infringer's profits. If it's so minimal, so speculative a
connection, we won't even go there. But I won't rule as a
matter of law now; that's just how I think it should be, and
I'd have to look at the Mackie case, the Polar Bear case, etc.
If Google wants to weigh in on that, I'd welcome that as well.
That would be due by 9pm tonight.
The second thing is, I think the idea that Mr. Boies suggested
is a good enough start that you, as good enough lawyers, ought
to be able to find a way to draft a simple two-page document
that would put off to the future a better way to deal with this
problem.
[Purcell gets ready to talk again]
I don't know what's gotten into you, you need to let me finish.
…
If there were a further trial later, does that mean the expert
reports get reopened, that they get to fix the problems with those
two files?
Google: [Purcell] I just want to let you know that we'd be comfortable
having the court decide [...]
Judge: Well, that's part of what's being suggested, but there are
other moving parts that you'd have to address and come up with
a written agreement.
So, that's all I have to say on that.
Google: [Van Nest] You said we could weigh in at 9pm too, right?
Judge: Yes, absolutely.
Now, I believe one dedicated juror is still in the jury room,
reading one of those books. So not all the jurors have left
the building, but there won't be any notes coming out today.
They'll be here from 8 to 1 tomorrow. What time would you like
to reconvene tomorrow? 8?
[Everyone seems to be okay with 8, so 8 it is.]
Tue May 15 14:01:41 PDT 2012 Right. If it goes against Oracle one way, it gets to elect some other way. To the very last second. That's its idea of fair. Nobody forced Oracle to turn down Google's earlier contingent offer or to turn down the statutory damages. Oracle greatly miscalculated with this litigation.
So everybody gets to do more briefs, due by 9 PM tonight. Still think you want to be a lawyer? I'm guessing not. And did any of us guess that this judge can code? That is the biggest surprise of the entire trial, to me. No wonder he was able to comprehend the technical testimony. But it does make me wonder, why then is he having such a hard time figuring out whether APIs can be copyrighted?
Update 6: Oracle's slides used in its closing statement are entered as an exhibit. Here are the titles of the slides, done for us by an anonymous reader: -
Oracle v. Google
- Key Points of Evidence
- Google's Infringement: Just Two Questions
- Google Has No Defenses
- Differences Between Android's Dalvik Virtual Machine And Java Virtual Machine Do
Not Excuse Google's Infringement
- Java And Android Are Similar In Ways Relevant To Patent Infringement
- Prior Existence Of Virtual Machines Does Not Excuse Google’s Infringement
- Prior Existence Of Symbolic References Does Not Excuse Google’s Infringement
- Preponderance Of Evidence Means More Likely Than Not
- Google Infringes ’104 Patent
- Google Disputes Only “Symbolic References”
- Google Infringes In Two Independent Ways
- Truth Is In Android Source Code: Android Resolves Symbolic References
- Dispute boils down to: is field index a “symbolic reference” under Court’s
definition?
- Definition Of “Symbolic Reference”
- Common Examples Of Symbolic References That Are Numbers, But Not Locations
- Google’s Expert Admits That Numbers Can Be Symbolic References
- Claim 11 Requires “Obtaining Data” – That Is The Actual Data The References
Refer To
- Google Expert Confirms ’104 Patent Obtains Data From Data Object
- IGET Is An Android Instruction That Obtains Actual Data From Data Object
- Google Hid The Actual Data In Its Presentation About IGET
- Google Admits Chart Is Incomplete
- Google’s Expert Admits IGET Instruction Obtains Data From Data Object Properly
Shown On Chart
- Both Experts Agree: IGET Instruction Obtains Value Of Data From Data Object
Properly Shown On Chart
- IGET Obtains Data From Specified Field
- Definition Of “Symbolic Reference”
- Google’s Expert Admits That Field Index Contained In IGET Instruction Is Not
Numeric Memory Location Of Actual Data
- Google Confirms That IGET Instruction Does Not Contain Numeric Memory Location
Of Actual Data
- Symbolic References Must Be Resolved But Numeric References Need Not Be
- Resolve.c Resolves The Index Contained In The Instructions
- Google Admits That Field Index Contained In Instructions Must Be Converted Into
“Numeric Memory Location”
- For dexopt infringement, dispute boils down to: is symbolic reference resolution
dynamic?
- Google Infringes In Two Independent Ways
- Google Admits That Android’s dexopt Resolves Symbolic References
- Google Admits That Android’s dexopt Symbolic Reference Resolution Is Dynamic
- Calling It “Static Linking” Does Not Change Fact That Resolution Is Dynamic
- Google’s Expert Tries To Undo Key Bornstein Admission
- Google has no claim construction order ruling that “dynamic” means at “runtime”
- Google Admits That dexopt Resolution Is Dynamic
- Has Oracle proven that it is more likely than not that Android bytecode
instructions contain symbolic references?
- Google Infringes ’520 Patent
- Google Disputes Only “Simulating Execution”
- Dispute boils down to: does dx tool “simulate execution”?
- Truth Is In Android Source Code: Android Simulates Execution
- Google’s Stack Argument Is Irrelevant
- Google’s “Pattern Matching” Label Is Irrelevant
- That Code Other Than Simulator.java Calls ParseArray Is Irrelevant
- Google’s “Pattern Matching” Label Is Irrelevant
- Google’s Expert Admits Android’s dx tool “Parses” And That Parsing Is Part Of
Simulation Execution
- Truth Is In Android Source Code: Android Simulates Execution
- Has Oracle proven that it is more likely than not that
Android simulates execution?
- [Titleless Slide showing special verdict form Q3 on willfullness]
- Willfulness Instructions: Recklessness
- Google’s Reckless Path to Patent Infringement
- Everyone Who Adopts Java Takes A License
- Google Made Java Central To Android
- Google Adopted Java Platform Components In Android
- Google Admits That Dalvik Is Interchangeable With Java Virtual Machine
- Google Uses Java Solutions To Overcome Performance And Memory Challenges In
Android
- Google Understands That Speed Matters To Users
- Android Relies On ’104 Patent’s Symbolic Reference Resolution To Run Faster
- Benchmark Tests Prove Android Runs Faster Because Of ’104 Patent
- Google’s Expert Cannot Credibly Dispute Performance Benchmark Results
- Google’s Own Performance Analysis Show 20% Speed Improvement For dexopt
- ’520 Performance Gain Promoted At Google Conference
- ’520 Performance Gain “Worth Putting In” Google Presentation
- Google's Motive to Infringe—750,000 Android Activations Per Day
- Google Acted Recklessly And Decided It Did Not Want To Know
- Google Knew Or Should Have Known: Google Employs Key Sun Inventors
- Google Worries About Its Java Patent Infringement
- Google Knows It Needs License For Sun’s Patents
- Google Knows Sun Owns Java Virtual Machine Patents
- Google’s “Clean Room”—No Defense
- Google Chooses Not To Ask About Sun’s Java Patents
- Google Knew Or Should Have Known Likely To Infringe
- Google Had Three Legitimate Choices
- Google Rejects Sun Implementation
- Google Rejects Sun’s Specification License
- Google Rejects Sun’s “Open Source” Java
- “Open Source” Has Conditions And Restrictions
- Google’s Actual Choice—Act Recklessly
- Willfulness Instructions: Cover Up
- Google Conceals Infringement From Sun
- Sun Tells Google It Needs License
- Google Anticipates Litigation Over Java
- Google Decides To Wait For Sun To Sue
- Oracle Gives Google Many Chances To Take License
- July 20, 2010 - Oracle Tells Google Android Infringes
- Google Makes No Changes To Android To Avoid Infringing ’104 And ’520 Patents
- Google Knows It Needs A License
- Willfulness Instruction: Five Factors
- [Titleless slide with special verdict form Q3 (willfullness)]
I don't know if Oracle did this slide presentation as an exhibit, just so they could be used by the jury as a trial exhibit, but if so, one can only hope that the jury remembers that the judge told them that nothing the lawyers say in their opening or closing statements is evidence. And a good thing, in that some of the items on the list stand out immediately as balderdash. One item of sliced baloney, for example, is where Oracle's slide says that Google infringed the '104 patent to speed up Android. The judge himself told Oracle that their "speed" argument regarding rangeCheck was ridiculous, and Google has provided ample evidence that Android does not infringe the '104 patent, which the USPTO has already preliminarily ruled is invalid. Invalid would mean that no one can infringe it, because it's not a valid patent. We await the final determination, as Oracle appeals everything, including that. But I mean, really. Also Google testified that it didn't believe it needed a license, and that Jonathan Schwartz, then CEO of Sun, welcomed Android and Google to the Java family. It's also not true that everyone who uses Java takes a license. I could go on, but it gives me heartburn to think of Michael Jacobs saying these things.
Update 7: All the trial exhibits are now available as PDFs here. Some are also done as text. Look for the date nearest the day, as they are listed by the date they were entered, which could be a day or so after the date of their use in the courtroom.
Update 8: We now have the transcript [PDF] of the day.
|