Oracle America, Inc. v. Google Inc.
Filing
509
DECLARATION of RUCHIKA AGRAWAL in Opposition to #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-1, #2 Exhibit 1-2, #3 Exhibit 1-3, #4 Exhibit 1-4, #5 Exhibit 1-5, #6 Exhibit 1-6, #7 Exhibit 1-7, #8 Exhibit 1-8, #9 Exhibit 1-9, #10 Exhibit 1-10, #11 Exhibit 1-11, #12 Exhibit 1-12, #13 Exhibit 2-1, #14 Exhibit 2-2, #15 Exhibit 2-3, #16 Exhibit 2-4, #17 Exhibit 2-5, #18 Exhibit 2-6, #19 Exhibit 2-7, #20 Exhibit 2-8, #21 Exhibit 2-9, #22 Exhibit 2-10, #23 Exhibit 2-11, #24 Exhibit 2-12, #25 Exhibit 2-13, #26 Exhibit 2-14, #27 Exhibit 2-15, #28 Exhibit 2-16, #29 Exhibit 2-17, #30 Exhibit 3-1, #31 Exhibit 3-2, #32 Exhibit 3-3, #33 Exhibit 3-4, #34 Exhibit 3-5, #35 Exhibit 3-6, #36 Exhibit 3-7, #37 Exhibit 3-8, #38 Exhibit 3-9, #39 Exhibit 3-10, #40 Exhibit 3-11, #41 Exhibit 4-1, #42 Exhibit 4-2, #43 Exhibit 4-3, #44 Exhibit 5-1, #45 Exhibit 5-2, #46 Exhibit 5-3, #47 Supplement 5-4)(Related document(s) #496 , #494 , #492 , #493 , #495 ) (Kamber, Matthias) (Filed on 10/7/2011)
EXHIBIT 4-3
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
EXHIBIT 4-3
I, Benjamin F. Goldberg, Ph.D., submit the following expert report (“Patent Validity
Report”) on behalf of plaintiff Oracle America, Inc. (“Oracle”):
I.
INTRODUCTION
1.
This report pertains to my review, analysis, and opinions regarding the validity of
the patents-in-suit asserted by Oracle against Google in the case known as Oracle America,
Inc. v. Google, Inc., pending in the United States District Court for the Northern District of
California, Case No. 10-03561-WHA.
2.
Of note, my report contains a detailed rebuttal to the seven validity reports
submitted by four different Google experts. My failure to address any specific statement in any
of Google’s reports does not imply that I agree with the statement, and no such agreement should
be inferred.
A.
Retention
3.
I have been retained to consult with Oracle’s counsel, review documents and
other information, prepare expert reports, and be available to testify regarding my opinions on
behalf of Oracle in connection with litigation brought by Oracle against Google.
4.
I have been asked to render opinions concerning the validity of the asserted
claims of the patents-in-suit in light of the prior art and other validity challenges put forth by
Google discussed in this report.
B.
Scope of Work Performed and Expected Testimony
5.
In general I have reviewed materials to provide technical teaching and opinions
regarding the validity of the patents-in-suit.
6.
As stated in Oracle’s list of issues for expert testimony, I expect to testify at trial
regarding:
a. State of the art, subject matter, novelty, and significance of the claimed
inventions in relation to the patents-in-suit;
b. Priority dates of the patents-in-suit;
1
pa-1475723
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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 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
EXHIBIT 4-3
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 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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
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
EXHIBIT 4-3
Dated: August 25, 2011
DR. BENJAMIN F. GOLDBERG
pa-1475723
148
EXHIBIT 4-3