

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. 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. 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 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. 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. 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? 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.