Oracle America, Inc. v. Google Inc.

Filing 497

Declaration of DANIEL PURCELL in Support of 496 MOTION in Limine No. 5, 494 MOTION in Limine No. 3, 492 MOTION in Limine No. 1, 493 MOTION in Limine NO. 2, 495 MOTION in Limine No. 4 filed byGoogle Inc.. (Attachments: # 1 Exhibit 1, # 2 Exhibit 2, # 3 Exhibit 3, # 4 Exhibit 4, # 5 Exhibit 5, # 6 Exhibit 6, # 7 Exhibit 7, # 8 Exhibit 8, # 9 Exhibit 9, # 10 Exhibit 10, # 11 Exhibit 11, # 12 Exhibit 12, # 13 Exhibit 13, # 14 Exhibit 14, # 15 Exhibit 15, # 16 Exhibit 16, # 17 Exhibit 17, # 18 Exhibit 18, # 19 Exhibit 19, # 20 Exhibit 20, # 21 Exhibit 21, # 22 Exhibit 22, # 23 Exhibit 23, # 24 Exhibit 24, # 25 Exhibit 25, # 26 Exhibit 26, # 27 Exhibit 27, # 28 Exhibit 28, # 29 Exhibit 29, # 30 Exhibit 30, # 31 Exhibit 31, # 32 Exhibit 32, # 33 Exhibit 33, # 34 Exhibit 34, # 35 Exhibit 35, # 36 Exhibit 36, # 37 Exhibit 37, # 38 Exhibit 38, # 39 Exhibit 39, # 40 Exhibit 40)(Related document(s) 496 , 494 , 492 , 493 , 495 ) (Kamber, Matthias) (Filed on 10/7/2011)

Download PDF
EXHIBIT 33 UNITED STATES DISTRICT COURT NORTHERN DISTRICT OF CALIFORNIA SAN FRANCISCO DIVISION ORACLE AMERICA, INC. Plaintiff, Case No. 3:10‐cv‐03561‐WHA  vs. GOOGLE INC. Defendants. EXPERT REPORT OF DR. BENJAMIN F. GOLDBERG REGARDING VALIDITY OF PATENTS-IN-SUIT SUBMITTED ON BEHALF OF PLAINTIFF ORACLE AMERICA, INC. pa-1475723 execute the indicated action. It is inefficient, however, for interpreters to resolve the same symbolic references repeatedly. As James Gosling, the inventor of the ’104 patent, explained, “each time an instruction comprising a symbolic reference is interpreted, execution is slowed significantly.” (’104, 2:13-15.) Accordingly, there was a long-felt need to increase the speed at which interpreters executed code containing symbolic references. 421. The ’104 patent satisfied this need by designing an interpreter that operated on intermediate form object code and, whenever it resolves a symbolic reference to data, stores the corresponding numerical (i.e., memory location) reference for later use. (See generally ’104 patent.) When the interpreter described in the patent encounters a subsequent reference to the data, it simply goes to the corresponding memory location rather than performing another timeconsuming symbolic reference resolution. (See, e.g., id. at 2:35-59.) The ’104 patent thus eliminated the need to resolve the same symbolic reference twice. (See, e.g., ’104, 2:60-67.) As summarized in the ’104 patent: As a result, the ‘compiled’ intermediate form object code of a program achieves execution performance substantially similar to that of the traditional compiled object code, and yet it has the flexibility of not having to be recompiled when the data objects it deals with are altered like that of the traditional translated code, since data reference resolution is performed at the first execution of a generated instruction comprising a data reference. (Id. at 2:60-67.) 422. The ’104 patent reduced the number of symbolic reference resolutions that occur during run time and thus solved the need to quickly execute intermediate form object code having symbolic references. 2. 423. The ’104 Patent Led to Commercial Success I understand that Sun Microsystems and Oracle have implemented the claimed invention of the ’104 patent in their Java virtual machines. In May 1996, James Gosling and Henry McGilton co-authored a white paper entitled “The Java Language Environment,” in which they describe symbolic reference resolution for Java. (James Gosling & Henry McGilton, White pa-1475723 127 Paper, The Java Language Environment (May 1996), available at http://java.sun.com/docs/white/langenv/.) The white paper documents the core pieces of Java, including symbolic reference resolution as disclosed in the ’104 patent. 424. The white paper explains, “Java’s memory management model is based on objects and references to objects.” (Id. at ch.2.1.6 (emphases in original).) Java bytecode references objects via symbolic references “that are resolved to real memory addresses at run time by the Java interpreter.” (Id. at ch.6.1.) The chapter on “Interpreted and Dynamic” further explains symbolic reference resolution: The Java compiler doesn’t compile references down to numeric values—instead, it passes symbolic reference information through to the byte code verifier and the interpreter. The Java interpreter performs final name resolution once, when classes are being linked. Once the name is resolved, the reference is rewritten as a numeric offset, enabling the Java interpreter to run at full speed. (Id. at ch.5.1.2.) 425. Therefore, Java interpreter only needs to incur “the small expense of a name lookup the first time any name is encountered” and need not incur the expense the second time that name is encountered. (Id.) After the interpreter performs the first name lookup, it can simply reference the “numeric offset.” (Id.) In this way, the ’104 patent allows “the Java interpreter to run at full speed.” (Id.) 426. Others in the field have recognized Java’s execution performance. (See, e.g., Patrick Niemeyer & Joshua Peck, Exploring Java, Ch. 1.2 (O’Reilly 2d Ed. 1997), available at http://doc.novsu.ac.ru/oreilly/java/exp/index.htm (Although “[i]n general, interpreters are slow . . . Java is a fast interpreted language.”).) Some consider Java as “a top performer along with C++ in many cases” even though Java requires an extra step of interpretation. (Carmine Mangione, Performance tests show Java as fast as C++, JavaWorld (Feb. 1, 1998), available at http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf.html.) 427. I understand that testimony at trial will show customer demand for devices with faster execution performance. Because the ’104 patent increases Java interpreters’ execution pa-1475723 128 speed, it has contributed to Java’s acceptance in the market as a fast interpreted language. Therefore, I understand that there is a nexus between the claimed invention of the ’104 patent and Java’s commercial success. 428. Similarly, the ’104 patent helps Android achieve good execution performance. I have read Professor Mitchell’s Opening Patent Infringement Report, Section VI entitled “RE38,104 (Reference Resolution)” and understand that the evidence at trial will show that Android’s Dalvik VM and the dexopt tool that optimizes .dex files both employ the ’104 patent. Specifically, I understand that the evidence at trial will show that Dalvik VM and dexopt replace symbolic references with numeric references such as a simple integer v-table offset. Google has characterized the symbolic reference resolution as an “optimization” and has featured it in a presentation describing the implementation of the Dalvik virtual machine. (Google I/O Android Video on “Dalvik Virtual Machine Internals” by Dan Bornstein (2008), available at http://developer.android.com/videos/index.html#v=ptjedOZEXPM.) Therefore, Google also acknowledges how symbolic reference resolution increases execution speed and has marketed its significance through a Google I/O presentation to software developers. 429. Furthermore, I have read Professor Mitchell’s Opening Patent Infringement Report, Section IV B, entitled “The Claimed Invention in the Patents-in-Suit are Necessary to Achieve Sufficient Performance and Security”. I understand that Dr. Mitchell, in consultation with Oracle Java engineers Bob Vandette and Dr. Peter B. Kessler, have conducted benchmark testing and analysis of the technology described in the ’104 patent, and they have confirmed that the performance of Android would be poor without the benefit of using the ’104 patent. I further understand that the performance benchmark testing results show an execution speed improvement of as much as 13 times with the ’104 patent than without the ’104 patent. 430. I understand that testimony at trial will show customer demand for devices with faster execution performance. Based on the benchmark analysis, I conclude that Android would have been a slower, and thus less attractive platform if it had not implemented the ’104 patent. pa-1475723 129 Therefore, I understand that there is a nexus between the claimed invention of the ’104 patent and Android’s commercial success. 431. For at least the above reasons, it is my opinion that secondary considerations demonstrate the non-obviousness of the ’104 patent. B. ’205 patent 1. 432. The ’205 Patent Solved a Long-Felt Need Traditional Just-In-Time (“JIT”) Java compilers translate Java bytecode into native machine code continuously during runtime, compiling the bytecode “just-in-time” before it is about to be loaded or executed. Traditional JIT compilers then cache the compiled code for later use. Symantec Corporation’s JIT compiler, which Sun licensed and integrated into JDK 1.1, is an example of such a traditional JIT compiler. (See Symantec’s Just-In-Time Java Compiler to be Integrated Into Sun JDK 1.1 (Apr. 7, 1997), available at http://www.symantec.com/about/news/release/article.jsp?prid=19970407_03 (Symantec’s JIT compiler “instantly convert[s] Java bytecode to native code on the fly . . . .”).) 433. With JIT compilation, “[O]verall program execution time now includes JIT compilation time, in contrast to the traditional methodology of performance measurement, in which compilation time is ignored.” (Ali-Reza Adl-Tabatabai et al., Fast, Effective Code Generation in a Just-In-Time Java Compiler, 33 PLDI ’98 Proceedings of the ACM SIGPLAN 1998 Conference on Programming Language Design & Implementation, 280, 280 (1998).) “As a result, it is extremely important for the compiler optimizations to be lightweight and effective.” (Id.) Furthermore, “native code generated by a JIT compiler does not always run faster than code executed by an interpreter. For example, if the interpreter is not spending the majority of its time decoding the Java virtual machine instructions, then compiling the instructions with a JIT compiler may not increase the execution speed.” (’205, 2:5-10.) Accordingly, as the ’205 patent inventors recognized, “there [was] a need for new techniques for increasing the execution speed of computer programs that are being interpreted.” (Id. at 2:27-29.) “Additionally, there [was] a pa-1475723 130 need for new techniques that provide flexibility in the way in which interpreted computer programs are executed.” (Id. at 2:29-31.) 434. The ’205 patent satisfied this long-felt need by providing a hybrid code execution technique that combines interpretation and execution of compiled code. The claimed invention compiles a portion of Java bytecode into native machine code and has a mechanism to switch between execution of Java bytecode and compiled native machine code during runtime. The claimed invention can choose to compile and optimize only the frequently-executed bytecode into native machine code. It can forego JIT compilation of less-frequently-executed bytecode, thereby reducing overall compilation time and memory usage (because compiled code typically takes up more space than bytecode). The claimed invention thus increases execution speed of Java bytecode in a flexible way. 2. 435. The ’205 Patent Led to Commercial Success I understand that the HotSpot virtual machine first became an optional component of JDK 1.2 on or about March 18, 1998. (See Plaintiff Oracle America, Inc.’s Objections & Responses to Defendant Google, Inc.’s Fourth Set of Interrogatories at 3.) 436. I understand that Java engineer Dr. Peter Kessler has confirmed that the HotSpot virtual machine employs the _fast_invokevfinal() nonstandard bytecode to implement the asserted claims of the ’205 patent. (8/4/2011 Kessler Dep. 53:16-55:10, 63:2-14, 64:15-68:13.) I also understand that Dr. Kessler testified that JDK 1.2 and subsequent versions, and HotSpot 1.0 and subsequent versions practice the asserted claims of the ’205 patent. (Id. at 179:4-11.) 437. The _fast_invokevfinal() bytecode is implemented in the OpenJDK 7 version of HotSpot. (See Bytecodes.java, available at http://www.docjar.com/html/api/sun/jvm/hotspot/interpreter/Bytecodes.java.html.) The _fast_invokevfinal() method is also implemented in the JDK 6 version of HotSpot. See Bytecodes.cpp for JDK 6, available at http://openjdk.java.net/projects/jdk6/ (JDK6u21|hotspot\src\share\vm\interpreter).) pa-1475723 131 438. The HotSpot virtual machine has become “Sun Microsystems, Inc.’s high- performance VM for the Java platform.” (White Paper, The Java HotSpot Performance Engine Architecture, available at http://java.sun.com/products/hotspot/whitepaper.html.) 439. Today, the HotSpot virtual machine is widely used in various Java products. For example, “Java HotSpot technology provides the foundation for the Java SE platform, the premier solution for rapidly developing and deploying business-critical desktop and enterprise applications.” (Id.) 440. The white paper for the Java HotSpot virtual machine explains that the patented hybrid code execution technique is critical to HotSpot’s performance. The white paper prominently features the patented technique as follows: Rather than compiling method-by-method, just in time, the Java HotSpot VM runs the program immediately using an interpreter and analyzes the code as it runs to detect the critical “hot spots” in the program. It then focuses the attention of a global native-code optimizer on the hot spots. By avoiding compilation of infrequently executed code (most of the program), the Java HotSpot compiler can devote much more attention to the performance-critical parts of the program, without necessarily increasing the overall compilation time. This hot-spot monitoring is continued dynamically as the program runs, so that it literally adapts its performance on-the-fly to the needs of the user. (Technical White Paper, The Java HotSpot Virtual Machine, Sec. 3, Sun Microsystems, Inc. (May 2011), available at http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSp ot_WP_Final_4_30_01.html.) 441. As can be seen from the above quote (and from the white paper as a whole), the patented hybrid code execution technique allows the HotSpot virtual machine to execute bytecode and native machine code interchangeably, choosing which instructions to run in native machine code. Therefore, the patented technique helps the HotSpot virtual machine minimize the compilation time and improve its runtime performance. 442. The CLDC HotSpot Implementation, a high performance virtual machine for embedded devices, also uses the hybrid code execution technique. (See The CLDC HotSpot pa-1475723 132 Implementation Virtual Machine 14, available at http://java.sun.com/products/cldc/wp/CLDC_HI_WhitePaper.pdf.) 443. I understand that testimony at trial will show customer demand for devices with good execution performance. Given such need for execution performance, I understand that the patented feature has contributed to the widespread use of the HotSpot virtual machine in various Java products. Therefore, I understand that there is a nexus between the claimed invention of the ’205 patent and HotSpot’s commercial success. 444. Similarly, the ’205 patent has contributed to Android’s commercial success. I have read Professor Mitchell’s Opening Patent Infringement Report, Section VII entitled “6,910,205 (Hybrid Code Execution),” and understand that the evidence at trial will show that Android’s Just-In-Time (JIT) compiler and dexopt tool implement the claimed invention of the ’205 patent. 445. Google has publicly recognized the importance of having a fast JIT compiler and has made an active decision to include a JIT compiler (which, again, implements the claimed invention of the ’205 patent) into the Android platform to improve Android’s performance. (See Google I/O JIT Video, “A JIT Compiler for Android's Dalvik VM” (2010), available at http://developer.android.com/videos/index.html#v=Ls0tM-c4Vfo.) In fact, Google’s own benchmark analysis shows 2 times to 5 times faster execution as a result of the Android JIT compiler. (Id.) Google acknowledges that having a fast JIT compiler is important because “JIT will enable a new class of applications written for the Android platform.” (Id.) Therefore, I understand that the functionalities of the ’205 patent, which I understand are implemented in Android JIT compiler, contribute to Android’s commercial success. 446. Furthermore, I have read Professor Mitchell’s Opening Patent Infringement Report, Section IV B, entitled “The Claimed Invention in the Patents-in-Suit Are Necessary to Achieve Sufficient Performance and Security.” I understand that Dr. Mitchell, in consultation with Oracle Java engineers Bob Vandette and Dr. Peter Kessler, have conducted benchmark testing and analysis of the technology described in the ’205 patent on Android, and they have pa-1475723 133 confirmed that the performance of Android would be poor without the benefit of using the ’205 patent. I further understand that the Android performance benchmark testing results show an execution speed improvement of as much as 3.3 times with the claimed invention of the ’205 patent than without the invention. 447. I understand that testimony at trial will show customer demand for devices with good execution performance. Based on the benchmark analysis, I conclude that Android would have been a slower, and thus less attractive, platform if it had not implemented the ’205 patent. Therefore, I understand that there is a nexus between the claimed invention of the ’205 patent and Android’s commercial success. 3. 448. The ’205 Patent Has Received Industry Praise The HotSpot virtual machine, which employs the invention of the ’205 patent, has received awards and praise from the industry due to its hybrid code execution technique. For example, JavaWorld selected Java HotSpot Server VM version 2.0 as the winner of JavaWorld 2001 Editors’ Choice Award for the best Java virtual machine category. (Jennifer Wilson, Best in Java (June 6, 2001), available at http://www.javaworld.com/javaworld/jw-06-2001/j1-01awards.html.) The article acknowledged the HotSpot’s “adaptive optimizer” and commented: “The HotSpot engine provides very high performance and great stability.” (Id.) I understand that the phrase “adaptive optimizer” refers to the HotSpot’s capability to selectively compile and optimize certain bytecode instructions into native machine code while interpreting other bytecode as is. 449. Moreover, many articles have touted the HotSpot virtual machine’s hybrid code execution technique. (See, e.g., Bill Venners, The HotSpot Virtual Machine, How Hotspot Can Improve Java Program Performance and Designs, available at http://www.artima.com/designtechniques/hotspot.html (“The adaptive optimization approach yields a program in which the code that is executed 80 to 90 percent of the time is native code as heavily optimized as statically compiled C++, with a memory footprint not much bigger than a pa-1475723 134 files and places the constants in a separate shared table. (’702, 5:6-17.) Because the resulting multi-class file – comprising the reduced class files and the shared table – contains only one copy of constants and the reduced class files do not contain the duplicated constants, the patented approach significantly reduces the memory usage. 2. 454. The ’702 Patent Led to Commercial Success The ’702 patent has contributed to Android’s commercial success. I have read Professor Mitchell’s Opening Patent Infringement Report, Section VIII entitled “5,966,702 (Class File Redundancy Removal”, and understand that the evidence at trial will show that Android’s dx tool implements the ’702 patent. Specifically, I understand that the evidence at trial will show that the dx tool pre-processes class files into a .dex file format that can be interpreted by the Dalvik Virtual Machine. I also understand that the evidence at trial will show that the dx tool pre-processes class files by removing the duplicated constants from multiple class files and storing them in a shared constant pool in a .dex file. 455. Google has presented and therefore marketed how the shared constant pool minimizes memory space. According to a Google I/O presentation, Google has “collapsed all of those, the separate constant pools into one constant pool . . . . [T]here’s less total storage required for this shared constant pool.” (Google I/O Android Video on “Dalvik Virtual Machine Internals” by Dan Bornstein (2008), available at http://developer.android.com/videos/index.html#v=ptjedOZEXPM.) Based on Professor Mitchell’s Opening Patent Infringement Report, I understand that the excerpt above refers to the functionalities of the ’702 patent. 456. Furthermore, I have read Professor Mitchell’s Opening Patent Infringement Report, Section IV entitled “Android’s Success Is Due to the Claimed Inventions” and understand that Dr. Mitchell, together with Oracle Java engineer Noel Poore, have conducted benchmark testing and analysis, which has confirmed that the performance of Android would be poor without the benefit of using the ’702 patent. I further understand that the performance pa-1475723 136 benchmark testing results show that a .dex file for an application is between 1.45 and 3.33 times smaller than it would be if duplicate constant removal were not performed. 457. I understand that testimony at trial will show customer demand for devices that use memory efficiently and thus can store more applications or data. Based on the benchmark analysis, I conclude that Android would not have same the capacity to store and run large numbers of applications as it currently has if it had not implemented the ’702 patent. I conclude that Android would be a less attractive platform if it had not implemented the ’702 patent. Therefore, I understand that there is a nexus between the claimed invention of the ’702 patent and Android’s commercial success. 458. For at least the above reasons, it is my opinion that secondary considerations demonstrate the non-obviousness of the ’702 patent. D. ’520 patent 1. 459. The ’520 Patent Solved a Long-Felt Need Conventional Java compilers generate a method called <clinit> to perform class initialization, including initialization of static arrays. (’520, 1:57-62.) The inventors of the ’520 patent recognized that, when using bytecode methods for array initialization, “the amount of code required to initialize the array is many times the size of the array, thus requiring a significant amount of memory.” (Id. at 2:53-58.) Given the limited amount of memory available on devices, and particularly on embedded devices, there was a need to initialize arrays using less memory space. 460. The ’520 patent solved this need by providing a more memory-efficient static array initialization. The invention of the ’520 patent recognizes bytecode instructions that perform static array initialization and replaces the lengthy sequence of bytecode instructions with an instruction for performing the static array initialization. The replacement “sav[es] a significant amount of memory” (id. at 3:4-7), and thus solved the long-felt need to reduce memory footprint during initialization of arrays. pa-1475723 137 2. 461. The ’520 Patent Led to Commercial Success I understand that testimony at trial will show customer demand for devices that use memory efficiently and thus can store more applications or data. The ’520 patent has helped Android minimize its memory usage and thus helped it become commercially successful. 462. I have read Professor Mitchell’s Opening Patent Infringement Report, Section IX entitled “6,061,520 (Play Execution),” and understand that the evidence at trial will show that Android’s dx tool implements the ’520 patent. Specifically, I understand that the evidence at trial will show that the dx tool processes each <clinit> method, including those that initialize static arrays. 463. Google has presented and marketed how efficiently the dx tool initializes arrays. Google explained the problem with conventional static array initialization: “sometimes you really need to have just a big array of data and if you’ve ever looked at what something like this looks like ... in a .class file, it’s not pretty. So that, this really is the code that’s needed to initialize that previous array. It’s 44 bytes of instructions, another 35 bytes in the constant pool, and it’s 4 instruction dispatches just to initialize each element. And each time you add another element to say ... an int array, it’s 11 bytes of code and constant combined and another ... 4 instruction dispatches.” (Google I/O Android Video on “Dalvik Virtual Machine Internals” by Dan Bornstein (2008), available at http://developer.android.com/videos/index.html#v=ptjedOZEXPM.) Google explained the benefit of using the technique of the ‘520 patent: “... we’re only using 46 bytes for ... this example and as you add elements to that int array, it’s just 4 more bytes per element, which is exactly the data represented. And we only have to interpret one opcode to do that entire initialization... that’s fill-array-data. . . . And this is both a speed and a space efficiency win. Measured on our system libraries it saves us something like a 100K.” (Id.) Based on Professor Mitchell’s Opening Patent Infringement Report, I understand that the fill-array-data opcode refers to the claimed “instruction requesting the static initialization of the array”, for example, of the ’520 patent. pa-1475723 138 464. Furthermore, I have read Professor Mitchell’s Opening Expert Report, Section IV entitled “Android’s Success Is Due to the Claimed Inventions” and understand that Dr. Mitchell, together with Oracle Java engineer Noel Poore, have conducted benchmark testing analysis, which has confirmed that the performance of Android would be poor without the benefit of using the ’520 patent. The performance benchmark testing compared the size in bytes of .dex files both with and without the static array initialization optimization of the claimed invention of the ‘520 patent. I understand that the benchmarking testing results showed that all .dex files were larger without the static array initialization optimization. I also understand that the benchmarking testing results showed as much as 57% memory savings for an array of size 100 of primitive data type int. 465. I understand that testimony at trial will show customer demand for devices that use memory efficiently and thus can store more applications or data. Based on the benchmark analysis, I conclude that the capacity of Android to load large numbers of applications would be reduced if it did not implement the claimed invention of the ’520 patent, and thus would be a less attractive platform. Therefore, I understand that there is a nexus between the claimed invention of the ’520 patent and Android’s commercial success. 466. For at least the above reasons, it is my opinion that secondary considerations demonstrate the non-obviousness of the ’520 patent. E. ’720 patent 1. 467. The ’720 Patent Solved a Long-Felt Need Since the implementation of Java virtual machines, there has been a need among system developers to have efficient use of memory among multiple virtual machine processes, while providing a robust environment for executing the multiple virtual machine processes concurrently. While Java virtual machines are attractive for multi-process systems, developers were very much aware of the disadvantages associated with startup time and memory management of these virtual machines. For example, each virtual machine had a distinct address pa-1475723 139 space physically separate from that of the other virtual machines, and so each virtual machine consumed vital system resources. Additionally, initialization costs were repeated for each virtual machine. A later approach, implemented in an attempt to address memory management, involved the virtual machines sharing some memory between the processes, while maintaining individual memory spaces. This approach had its own drawbacks. Initialization costs were still repeated for each virtual machine and the individual memory spaces were not always necessary. Memory usage improved, but was still inefficient. This approach was not practical for smaller devices having limited memory resources. 468. The ’720 patent satisfied this need with a new approach to virtual machine memory management and startup that used process cloning with copy-on-write technology to share memory between a master virtual machine and a cloned virtual machine, until the cloned virtual machine needed to modify the shared memory. The ’720 patent’s approach is well-suited to smaller devices having limited memory resources because (a) it shares common libraries between processes, (b) it does not have to repeat initialization costs for each cloned virtual machine, and (c) it shares memory between processes by default. It also reduces startup time by cloning a prewarmed master virtual machine to create a child virtual machine. 2. 469. The ’720 Patent Led to Commercial Success I understand that testimony at trial will show customer demand for devices that use memory efficiently and can run multiple applications. The ’720 patent has helped Android minimize its memory usage and thus helped it become commercially successful. 470. I have read Professor Mitchell’s Opening patent Infringement Report, Section IV entitled “Android’s Success Is Due to the Claimed Inventions” and understand that Dr. Mitchell, together with Oracle Java engineers, Erez Landau and Seeon Birger, have conducted benchmark testing and analysis, which has confirmed that the performance of Android would be poor without the benefit of using the ’720 patent. I further understand that the performance benchmark testing results show that Android’s use of the ’720 patent results in as much as 40% pa-1475723 140 memory savings for Android, memory savings of 2MB per each additional running application, and also a 0.10 second per application launch time savings. Professor Mitchell describes that disabling the ’720 functionalities in Android increases memory consumption by 70%. 471. Google has given presentations on the Zygote process to software developers. Google explained: “[the]VM process that initializes a Dalvik VM and preloads a lot of these libraries . . . . It uses copy-on-write to maximize re-use and minimize footprint so that data structures are shared and it won’t do a full copy unless some of those data structures are to be modified.” (Google I/O Video on “Anatomy and Physiology of an Android” by Patrick Brady (2008), available at http://developer.android.com/videos/index.html#v=G-36noTCaiA.) Based on Professor Mitchell’s Opening Patent Infringement Report, I understand that the excerpt above refers to Zygote and the ’720 patent. The fact that Google presented Zygote’s ability to software developers indicates that the ability to “maximize re-use and minimize footprint” is significant. 472. Google has stated: “Application switching on a mobile device is extremely critical; we target significantly less than 1 second to launch a new application.” (Multitasking the Android Way, available at http://developer.android.com/resources/articles/multitaskingandroid-way.html.) I find that the saving of 0.10 seconds that Zygote provides (as determined by Prof. Mitchell) is a substantial part of “significantly less than 1 second.” 473. I understand that testimony at trial will show customer demand for devices that use memory efficiently and devices that can quickly startup applications. Based on the benchmark analysis, I conclude that without the substantial memory savings and application startup time savings provided by the claimed invention of the ’720 patent, the capacity of Android to run large numbers of simultaneous applications, and the responsiveness of doing so, would be substantially diminished. Therefore, I understand that there is a nexus between the claimed invention of the ’720 patent and Android’s commercial success. pa-1475723 141 possible subsequent results of an action by a method.” (Id. ¶ 37.) In my opinion, the finegrained security model described in the ’447 and ’476 patents provides a more flexible model and offers greater protection from harmful actions. 2. 482. The ’447 and ’476 Patents Led to Commercial Success I understand that Sun Microsystems implemented and Oracle continues to implement the security model described in the ’447 and ’476 patents in Java. Li Gong’s book entitled “Inside Java™ 2 Platform Security” explains the security model in detail: [E]ach class is associated—when it is defined—with an instance of ProtectionDomain. A ProtectionDomain is a convenience class for grouping . . . static permissions . . . . [A] resource access is granted if every ProtectionDomain in the current execution context has been granted the permission required for that access, that is, if the code and Principals specified by each ProtectionDomain are granted the permission. (Li Gong et al., Inside Java™ 2 Platform Security, Second Edition 58 (2003) (OAGOOGLE0000106419).) 483. The security model is implemented across multiple Java classes, including java.security.ProtectionDomain, and java.security.AccessController. (See id. at ch.5-6.) 484. Sun Microsystems first introduced the new security model in JDK 1.2 in December 1998. (Li Gong, Java Security: A Ten Year Retrospective, 2, available at http://www.acsac.org/2009/program/keynotes/gong.pdf (OAGOOGLE0100359495) ( “JDK 1.2 introduced the fine-grained access control model, which continued essentially unchanged till this day.”).) Even though it has been over a decade since Sun Microsystems introduced the finegrained security model, “the overall architecture had in fact been carried over to both the enterprise Java and mobile Java platforms.” (Id. at 1.) In fact, Java SE 5.0 and 6.0, for example, still include the java.security package that implements the fine-grained security model. (See, e.g., Class ProtectionDomain for Java™ 2 Platform Standard Ed. 5.0, available at http://download.oracle.com/javase/1.5.0/docs/api/java/security/ProtectionDomain.html; Class ProtectionDomain for Java™ Platform Standard Ed. 6, available at http://download.oracle.com/javase/6/docs/api/java/security/ProtectionDomain.html.) pa-1475723 144 485. I understand that testimony at trial will show customer demand for devices with increased security protection. In my opinion, the functionalities of the ’447 and ’476 patents have contributed to the widespread adoption of the fine-grained security model in Java products. Therefore, I understand that there is a nexus between the claimed inventions of the ’447 and ’476 patents and Java’s commercial success. 3. 486. The ’447 and ’476 Patents Have Received Industry Praise Java’s fine-grained security model, which implements the functionalities of the ’447 and ’476 patents, has received praise from the industry. When Sun Microsystems released JDK 1.2, the industry praised the fine-grained security model for solving the earlier problems with Java’s sandbox approach. (See, e.g., Web Based Programming Tutorials, available at http://www.webbasedprogramming.com/Java-1.2-Unleashed/ch03.htm (“The security model implemented by the Java sandbox has been strengthened and at the same time made more flexible from JDK 1.0 to JDK 1.2.”); Monica Pawlan, JDK 1.2: New Features and Functionality (May 1998), available at http://www.pawlan.com/monica/articles/jdk1.2features/ (“JDK 1.2 introduces a strong security model . . . . The JDK 1.2 security policy is easy to configure, provides fine-grained access control, and applies to all Java applets and applications.”); Larry Koved et al., The Evolution of Java Security (May 24, 2003), available at http://www.developertutorials.com/tutorials/java/evolution-java-security-050524-1448/ (“The new JDK 1.2 permission model is much more flexible and even permits application-defined resources to be added to the access control system.”).) 4. 487. Google Copied the Claimed Inventions of the ’447 and ’476 Patents I understand that the evidence at trial will show that, in developing its competing Android software, Google copied the desirable functionalities of Java’s fine-grained security model claimed in the ’447 and ’476 patents. (See, e.g., Android Developers Package Reference (listing Android APIs including the java.security package), available at http://developer.android.com/reference/java/security/package-summary.html.) The Android pa-1475723 145 Dated: August 25, 2011 DR. BENJAMIN F. GOLDBERG pa-1475723 148

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.


Why Is My Information Online?