So now we are back to the remaining and important copyright questions. The parties have each responded to the Court's request for additional (and, I am hopeful, final) briefing on the subject. What is interesting is the spin that each party gives to answering the Court's questions.

In Google's case (1192 [PDF, including Exhibits; Text, excluding exhibits]) everything ties back to compatibility, i.e., the compatibility between Android and Java and the assertion that programs that run on Android should be able to run on Java, at least to the extent they are written to only use the 37 APIs.

The record does demonstrate, however, that code that relies on APIs that are common to the two platforms will compile and execute on both platforms. RT 2172:6-11 (Astrachan) (“Q. Do you have an opinion, professor, whether, from a computer science perspective, Android and Java are compatible with respect to the methods and other constructors and other items in the classes of the 37 accused packages? A. Yes. For those 37 packages, the code that I write on one platform will run on the other platform.”); see also RT 2171:24-2172:11 (Astrachan); RT 2287:1- 8 (Mitchell) (“I think the point that was illustrated by this code and Dr. Astrachan’s description of it is that, for a given piece of code such as this class that he wrote with a marker, it may run on both platforms if the only things it requires are things that are common to the two”); RT 2292:25- 2293:14 (Mitchell) (agreeing that Dr. Astrachan’s code would work both on the Android and J2SE platforms, and that calling the two platforms “compatible” in this sense is using “a great definition of ‘compatible’”).

Had Google not implemented the publicly declared interfaces that are in the 37 API packages, code that depends on them would not work. For example, if Android did not declare the Comparable interface, then a class that includes “implements Comparable” as part of its declaration would not compile. Moreover, had Android omitted the Comparable interface, methods that depend on it, like ComparableTimSort, would not function on the Android platform. Thus, because the public interfaces in the 37 API packages are functionally required for compatibility with the APIs in those packages, those interface declarations are not copyrightable.

Because aspects of a computer program that are functionally required for compatibility are not copyrightable, it does not matter what the defendant does with them. Even if the defendant’s product is not compatible with the plaintiff’s product, the plaintiff still cannot assert infringement based only on the copying of unprotected elements. “The protection established by the Copyright Act for original works of authorship does not extend to the ideas underlying a work or to the functional or factual aspects of the work.” Sega, 977 F.2d at 1524 (emphasis added) (citing 17 U.S.C. § 102(b)). A “party claiming infringement may place no reliance upon any similarity in expression resulting from unprotectable elements.” Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1446 (9th Cir. 1994) (quotation marks and citation omitted; emphasis in original). Thus, because the SSO of the 37 API packages is functionally required for compatibility, Google was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.

No application or program written for the J2SE platform runs on Android.

...

Many applications and programs written for the J2SE platform will not run on Android for the additional reason that Google did not include all of the Java API packages and classes.

So did Oracle (Sun) itself fragment J2SE with J2ME?

***************

Docket

05/23/2012 - 1189 - OBJECTIONS to Answer to Juror May 22 question regarding "symbolic reference" and Request for Curative Instruction by Oracle America, Inc.. (Jacobs, Michael) (Filed on 5/23/2012) (Entered: 05/23/2012)

05/23/2012 - 1190 - JURY VERDICT (Phase II). (dt, COURT STAFF) (Filed on 5/23/2012) (Entered: 05/23/2012)

05/23/2012 - 1191 - Brief Oracle's May 23, 2012 Copyright Brief filed byOracle America, Inc.. (Jacobs, Michael) (Filed on 5/23/2012) (Entered: 05/23/2012)

05/23/2012 - 1192 - TRIAL BRIEF Google's May 23, 2012 Copyright Liability Trial Brief by Google Inc.. (Attachments: # 1 Exhibit A, # 2 Exhibit B, # 3 Exhibit C, # 4 Exhibit D, # 5 Exhibit E)(Van Nest, Robert) (Filed on 5/23/2012) (Entered: 05/23/2012)

05/23/2012 - 1193 - Jury Notes - Phase I and Phase II (4/18/12 - 5/23/12) (dt, COURT STAFF) (Filed on 5/23/2012) (Entered: 05/23/2012)

***************

Documents

1189

MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
[email]
KENNETH A. KUWAYTI (Bar No. 145384)
[email]
MARC DAVID PETERS (Bar No. 211725)
[email]
DANIEL P. MUINO (Bar No. 209624)
[email address telephone fax]

BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[email address telephone fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[email address telephone fax]

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email address telephone fax]

Attorneys for Plaintiff
ORACLE AMERICA, INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.
Plaintiff,
v.
GOOGLE INC.
Defendant.

Case No. CV 10-03561 WHA

ORACLE AMERICA, INC.’S
OBJECTION TO COURT’S
ANSWER TO JUROR QUESTION
REGARDING “SYMBOLIC
REFERENCE”AND REQUEST FOR
CURATIVE INSTRUCTION

Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

---

Oracle further objects to the Court’s answer delivered on May 22, 2012 to the question asked by a juror at 10:35 a.m. regarding “the symbolic reference definition” and requests a curative instruction.

As part of its answer to the juror’s question, the Court instructed the jury that a reference to data might be numeric or symbolic, but cannot be both. The Court’s construction of “symbolic reference” does not have a “one or the other” quality, so the Court’s May 22 instruction was not consistent with its claim construction. The inconsistency can be mitigated if the Court clarifies that the “data” referred to in its construction is the ultimate data to be obtained or used after symbolic reference resolution is performed—that is the “data” that is claimed elsewhere in the claim language. Oracle requests that the Court promptly provide a curative instruction on that point for the jury during deliberations on May 23, 2012.

The juror’s question on May 22 at 10:35 a.m. asked:

In the symbolic reference definition, if we find a reference that identifies data by a numeric memory location of the data, does the existence of an initial numeric reference preclude the existence of a symbolic reference?

(RT 4352:8-13.) In response, the Court repeated the construction of “symbolic reference”—“a reference that identifies data by a name other than the numeric memory location of the data, and that is resolved dynamically rather than statically”—but then instructed the jury that the references in question must be in the instructions and that a reference is “either going to be a numeric reference or it’s going to be a symbolic reference.” (RT 4353:9-16.) The Court further stated that “for any given reference, it can’t be both. It’s got to be one or the other.” (Id.) The Court explained the jury’s inquiry was to be as follows:

So how do you tell what it is? You look at the instruction set. You look at the reference. And you ask this question: Is that thing referring to the numeric memory location?

If the answer is yes, then it’s a numeric reference. If the answer is no, it’s not referring to the numeric memory location, then it’s a symbolic reference.

(RT 4353:17-23.) The Court stated:

If you find a numeric reference, that's a numeric reference. End of story. It can't be both. Because a numeric reference is something that refersdirectly to the location in memory where that data is stored. It’s not symbolic.

1

---

(RT 4354:5-8.)

The Court’s claim construction of “symbolic reference” imposes no such limitation. In particular, under the Court’s construction, a reference could be symbolic as to some data and numeric as to other data. Indeed, so long as the reference is symbolic as to some data, then it “identifies data by a name other than the numeric memory location of the data” and the reference is a symbolic reference, regardless of whether it identifies other data by location. Hence, the answer to the juror’s question should have been, “No, the existence of an initial numeric reference does not preclude the existence of a symbolic reference.” By instructing the jury as it did, the Court imposed an additional limitation on its construction of “symbolic reference” that is not present in the original construction. That additional limitation may result in a finding of noninfringement or no finding at all, as the jury wrestles with the question whether, in Android, an index to an entry in a table can only be a numeric reference to data even if it is also a symbolic reference to data in the data object.

Clarifying what “data” is actually at issue in the Court’s construction could mitigate the harm. The Court’s construction is not explicit on what that “data” may be. Reading the construction of symbolic reference in context, the “data” of the Court’s construction is the “data” that is actually claimed in the ’104 patent: the data that is “obtained” in Claim 11 and the data that is “thereafter used” in Claims 39, 40, and 41. By disambiguating what “data” is at issue in the Court’s construction of symbolic reference, on the facts here, the jury may have less difficulty determining whether a reference is symbolic or numeric.

Oracle’s infringement position is that Dalvik bytecode instructions contain “symbolic references” (as defined by the Court) in the form of indices (including field indices—the “01” from Google’s demonstrative) that identify the actual data to be obtained by a name (“01”) other than the numeric memory location of that data. See, e.g., RT 3303:2-3304:20 (Mitchell); TX 4015, 7:12-13.

By contrast, Google argued that the field indices (“01”) can only be numeric references because they are the location of “data” in the Field ID table of a dex file, which contains information used to perform the resolution process and locate the data to be obtained. Google’s

2/p>

---

argument ignores that the field indices specify the actual data to be obtained (i.e., the data in an Android data object), making them symbolic references under the Court’s construction of “symbolic reference.” Moreover, the ’104 patent never refers to information used in the resolution process as “data.” Instead, the patent specification and claim language refer to “data” as being thereafter used for the operation identified by the instruction (e.g., the LOAD instruction accesses or fetches a value from a data object). Under the Court’s construction, the jury could find that the indices contained in Dalvik bytecode instructions are “symbolic references” to the actual data they identify—they refer to that data by a name (e.g., field index “01”) other than the numeric memory location of that data (e.g., byte offset “48”).

If the Court clarifies that “data” in its construction means the “data” that is actually claimed in the ’104 patent, then any inconsistency will be mitigated. (’104 patent, Claim 11: “obtaining data in accordance to said numerical references”; Claims 39, 40: “wherein data from a storage location identified by a numeric reference is thereafter used for the operation when the instruction contains a symbolic field reference”; Claim 41: “wherein data from a storage location is used thereafter for the operation when the instruction contains a symbolic field reference.”)

Without that clarification, the jury may be misled into thinking that because Google has argued that a field index (“01”) is a location in the Field ID table, which contains information not claimed or mentioned in the ’104 patent claims, the field index must only be a numeric reference and cannot be a symbolic reference to the claimed data—the actual data to be obtained. That is incorrect under the Court’s construction of “symbolic reference.”

Oracle therefore requests that the Court promptly provide a curative instruction to the jury that the “data” referenced in the asserted claims of the ’104 patent is the claimed data—the actual data to be obtained or used after symbolic reference resolution is performed.

Dated: May 23, 2012

MORRISON & FOERSTER LLP

By: /s/ Michael A. Jacobs
Michael A. Jacobs
Attorneys for Plaintiff
ORACLE AMERICA, INC.

3

---

1190

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF CALIFORNIA

ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.

No. C 10-03561 WHA

SPECIAL VERDICT FORM

YOUR ANSWERS MUST BE UNANIMOUS.

Direct Infringement

1. Has Oracle proven by a preponderance of the evidence that Google directly infringes claims 11, 27, 29, 39, 40, or 41 of United States Patent Number RE38,104?

	Yes (Infringing)	No (Not Proven)
CLAIM 11:	________	___X____
CLAIM 27:	________	___X____
CLAIM 29:	________	___X____
CLAIM 39:	________	___X____
CLAIM 40:	________	___X____
CLAIM 41:	________	___X____

---

2. Has Oracle proven by a preponderance of the evidence that Google directly infringes claims 1 or 20 of United States Patent Number 6,061,520?

	Yes (Infringing)	No (Not Proven)
CLAIM 1:	________	___X____
CLAIM 20:	________	___X____

3. Has Oracle proven by clear and convincing evidence that Google willfully infringed one or more claim of an asserted patent? (Answer this question only if above you answered “Yes” to one or more claims of a given patent.)

	Yes (Willful)	No (Not Proven)
For the '104 Patent:	________	________
For the '520 Patent:	________	________

Dated: May 23, 2012.

/s/ Greg Thompson
FOREPERSON

2

---

1191

MORRISON & FOERSTER LLP
MICHAEL A. JACOBS (Bar No. 111664)
[email]
KENNETH A. KUWAYTI (Bar No. 145384)
[email]
MARC DAVID PETERS (Bar No. 211725)
[email]
DANIEL P. MUINO (Bar No. 209624)
[email address telephone fax]

BOIES, SCHILLER & FLEXNER LLP
DAVID BOIES (Admitted Pro Hac Vice)
[email address telephone fax]
STEVEN C. HOLTZMAN (Bar No. 144177)
[email address telephone fax]

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email address telephone fax]

Attorneys for Plaintiff
ORACLE AMERICA, INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.
Plaintiff,
v.
GOOGLE INC.
Defendant.

Case No. CV 10-03561 WHA

ORACLE MAY 23, 2012
COPYRIGHT BRIEF

Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

---

Oracle submits this brief in response to the Court’s request for further briefing regarding interfaces, exceptions and interoperability (ECF No. 1181).

I. INTERFACES AND EXCEPTIONS

A. Please state how many “interfaces” are included in the joint table supplied by
counsel. (Dkt. No. 1124). Also please state how many “exceptions” were
“thrown” and the extent to which they were duplicated by Google. Each side
should also include one example of an “interface” and one example of a
“throw” to illustrate the most salient points about these features.

1. Interfaces

The joint table at ECF No. 1124 includes 171 interfaces from Java 2 Standard Edition (“J2SE”) 5.0 and 158 interfaces from Android Froyo.

Interfaces can be used to group classes in different packages. For example, the interface java.util.Set is implemented by seven classes spread across three different packages. See TX 610.2 at /docs/api/java/util/Set.html under “All Known Implementing Classes.” The classes implementing java.util.Set include, among others, java.util.EnumSet, java.util.HashSet, java.util.concurrent.CopyOnWriteArraySet, and javax.print.attribute.standard.JobStateReasons. Id.

While a class can only inherit from one superclass, it can implement more than one interface. TX 984 at 259. The class java.util.HashSet, for example, implements the interfaces java.util.Set, java.lang.Cloneable and java.io.Serializable. TX 610.2 at /docs/api/java/util/HashSet.html. An interface establishes relationships that might not otherwise exist between classes. See TX 984 at 259; RT 589:13-590:23 (Reinhold); RT 1239:5-7 (Mitchell).

Interfaces influence SSO at the method level as well. Every method declared in an interface must be implemented by each class that implements that interface, or else be inherited from a superclass of that class. TX 984 at 224. As mentioned above, java.util.HashSet implements the interface java.util.Set, which declares 15 distinct methods. The HashSet class implements eight of those methods itself (add, clear, clone, contains, isEmpty, iterator, remove and size); it inherits three of them (equals, hashCode, removeAll, and the toArray methods) from

1

---

its direct superclass AbstractSet; and it inherits the remainder from AbstractCollection, the direct superclass of AbstractSet. TX 610.2 at /docs/api/java/util/HashSet.html.

Interfaces can also be subtypes of interfaces in different packages. RT 601:22-602:1 (Reinhold) (interfaces in java.nio.Channels are subtypes of the interface java.io.Closeable).

Google copied many of the classes that implement the interfaces defined in the J2SE API, but not all of them. For example, Google implemented only a subset of the classes that implement the interface java.util.Set: Android does not include the class javax.print.attribute.standard.JobStateReasons, which is present in J2SE, because Android did not include the javax.print package. Compare TX 610.2 at /docs/api/java/util/Set.html with TX 767 at /java/util/Set.html. As the above shows, the interfaces in J2SE embody significant creative expression. Google copied them, including their complex SSO, by choice, not by necessity.

2. Exceptions

Exceptions are used to report error conditions. “When a program violates the semantic constraints of the Java programming language, the Java virtual machine signals this error to the program as an exception.” “Programs can also throw exceptions explicitly, using throw statements.” TX 984 at 297. The API documentation for J2SE 5.0 specifies 176 exceptions in the 37 asserted packages. See package listings for each of the 37 J2SE API packages in TX 610.2. Of these, 165 are copied into Android Froyo. Compare id. with TX 767.

Based on an analysis of the compiled class libraries for J2SE 5, the throws clauses (exception lists) of the 6,508 J2SE 5.0 methods in the table at ECF No. 1142 contain 2,220 exceptions (including scenarios when multiple methods threw the same exceptions). Based on a similar analysis, there are 2,241 exceptions mentioned in the exception lists for Android Froyo. Of these, 1,828 throws clauses (comprising 2,014 exceptions) are identical between J2SE 5.0 and Android Froyo, including the order of exceptions.

The list of exceptions a method throws represents the expression of a structural choice. According to the Java Language Specification, “When an exception is thrown, control is transferred from the code that caused the exception to the nearest dynamically-enclosing catch clause of a try statement (§14.20) that handles the exception.” TX 984 at 302. The “catch”

2

---

clause that handles the exception can be within the method either directly or indirectly. See id. For example, the method java.security.cert.Certificate declares the following method:

public abstract void verify(PublicKey key, String sigProvider)
throws CertificateException, NoSuchAlgorithmException, InvalidKeyException,

NoSuchProviderException, SignatureException

TX 610.2 at /docs/api/java/security/cert/Certificate.html. This method “[v]erifies that this certificate was signed using the private key that corresponds to the specified public key,” and it throws various exceptions in the event of unsupported signature algorithms, an incorrect key, and other scenarios. Id. By specifying that this method “throws” five different types of exceptions, the API designers have required any code that calls the method to handle all five error scenarios.

In Android, Google could have created different exception lists using supertypes of the listed exceptions. “For each checked exception that can result from execution of the body of a method or constructor, a compile-time error occurs unless that exception type or a supertype of that exception type is mentioned in a throws clause in the declaration of the method or constructor.” TX 984 at 221 (emphasis added). For example, in the case of the verify() method listed above, all of the listed exceptions are subtypes of java.security.GeneralSecurityException. TX 610.2 at /docs/api/java/security/GeneralSecurityException.html. The method would still compile if the throws clause had included only GeneralSecurityException.

The Java Language Specification places no significance on the order of the exceptions in a throws clause. See TX 984 at 221-22. The fact that Android copied 1,828 exception lists verbatim shows that Google copied more than what it required for its alleged goal of “compatibility.” To the extent that the exception lists are identical between Java and Android, it is because the Android API designers chose to make them identical.

II. EVIDENCE REGARDING INTEROPERABILITY

A. To what extent, if at all, have applications and programs written for the J2SE
platform before Android arrived been able to run on Android?

No application or program written for the J2SE platform runs on Android. There are several reasons for this: (a) Android applications start up in a completely different way from standard Java applications; (b) Android applications are compiled to Dalvik bytecode rather than

3

---

Java bytecode; and (c) Android applications are packaged as “apk” files, which are similar to but incompatible with Java’s “jar” files. Many applications and programs written for the J2SE platform will not run on Android for the additional reason that Google did not include all of the Java API packages and classes. Evidentiary support for each of these points can be found in the trial record as described below.

The Q&A that Google developed for the Android announcement and “early look” release of the Android SDK in November 2007 confirms that Android is not interoperable with Java:

Q48. Does Android support existing Java apps?

A. No.

Q49. Is Android Java compatible?

A. No.

No application written for the Java platform will run on Android, even if it uses only the 51 API packages from J2SE 5.0 that Google copied into Android. Java platform applications are required to include a special method called “main” that serves as the entry point (where program execution begins), but Android does not use the main() entry point. The Java platform requirement for the main() method may be found, for example, in Section 2.16.1 of the Java Virtual Machine Specification:

A Java Virtual Machine starts execution by invoking the method main of some specified class, passing it a single argument, which is an array of strings. This causes the specified class to be loaded (§2.16.2), linked (§2.16.3) to other types that it uses, and initialized (§2.16.4). The method main must be declared public, static, and void.

TX 25 at 40; see also TX 984 at 309.

Android embodies a different application model than the Java platform. It does not use the main() method as the entry point of an application. As Dr. Astrachan confirmed, Java programs must be rewritten to run on Android:

Q. Mr. Jacobs asked you about the program that you wrote this morning, and he asked you whether it would run, whether it would compile on the Android platform as opposed to Java. Would you have written this program any differently if someone told you it needed to run on the Android platform as opposed to the Java Platform?

4

---

A. I would have changed the main. That’s a Java entry point. Otherwise nothing else would change.

Q. Okay.

THE COURT: Change what?

THE WITNESS: The main.

THE COURT: Where is that?

THE WITNESS: The Public Static Void Main. That’s a requirement of the Java Platform and the Java Language on that platform. That’s the launch point for a program.

THE COURT: You would change it to what?

THE WITNESS: For how to do that on Android. That’s a little different.

RT 2221:11-2222:3 (Astrachan).

Java applications will not run on Android for the additional reason that Java applications are compiled to Java bytecode, while Android applications are compiled to Dalvik bytecode. See RT 2287:9-22 (Mitchell). Since programs are not normally distributed in source code format for security and efficiency reasons, this means a program compiled for distribution for the Java platform has to be recompiled by the developer for distribution for the Android platform before it can run on Android. An Android phone does not have the ability to convert Java class files to Android dex files.

A third reason why Java applications will not run on Android is that Java and Android use different file formats. Java applications are distributed in “jar” files. See, e.g., TX 610.2 at /docs/guide/jar/jar.html. Google distributes Android applications in “apk” files. See TX 757.

This is only the tip of the iceberg, however. Oracle has already described elsewhere how many categories of Java applications that will not run on Android because Google chose not to include the API packages or classes they require for common functions like interacting with the graphical user interface, sound, image input/output and printing. See ECF No. 1118 at 18-19. While Oracle is not aware of any metric that measures the exact percentage of programs that are incompatible for this reason, it is instructive to look at the relatively simple applications Sun distributed with JDK5 as demos and samples to teach developers how to program for the Java

5

---

platform. These demos and samples are contained in the JDK5 archives found in the directory licenseebundles/jdk1.5.0 of TX 623. There are 36 relevant examples. Of these only one, the sample application in sample/nio/server, might run on Android if compiled into Dalvik bytecode and distributed as an apk file but for the fact that, like all Java applications, it uses main() as an entry point. See RT 2221:11-2222:3 (Astrachan). The 20 Java demo applets in demo/applets will not run on Android because Android does not support applets and is missing the required java.applet and java.awt API packages and subpackages. See TX 1072 (list of copied packages). The 11 demo applications in demo/jfc will not run in Android because Android is missing the required java.awt and javax.swing API packages and subpackages, among other reasons. See id. The four applications in demo/management will not run on Android because Android is missing the required java.lang.management API package, among other reasons. See id.¹

The fact that Android will not run simple applications designed to demonstrate the features of the Java platform is strong evidence that Android was never meant to be compatible with Java.

B. To what extent, if at all, have applications and programs written after
Android arrived been able to run both on Android and J2SE?

As shown above, applications written for the Java platform do not run on Android. This did not change after Android arrived. Applications written for Android do not run on the Java platform. As with the JDK5 examples above, an examination of the sample applications that Google provides with the Android SDK to teach developers how to program for Android shows that none of the Android applications Google included will run on the Java platform, even though they are written in the Java programming language. (See TX 43cupcake15 - GOOGLE-00- 00000523developmentsamples.) Dr. Bloch testified that the “simplest program that you can write in any language is called the Hello World Program. It just uses that programming language to print Hello World, and that’s how you sort of start off with [a] new language. You learn how to

_______________________

¹ The directory demo/jvmti also contains seven “instrumentation agents” that demonstrate how the Java Virtual Machine Tools Interface (JVMTI) can be used to access information in a running VM, but these will not work on Android since Android doesn’t include JVMTI. However JVMTI is optional under the TCK rules for J2SE 5.0, so Oracle does not include them in its count.

6

---

write a program that simply prints Hello World in the language.” RT 782:23-783:2 (Bloch). Google’s “Hello World” application for Android is called “HelloActivity.java,” and it will not run on the Java platform. See HelloActivity.java in TX43cupcake15 - GOOGLE-00- 00000523developmentsamplesHelloActivitysrccomexampleandroidhelloactivity. Google’s HelloActivity.java lacks a main() method, which is a required Java platform entry point, and it requires classes and methods defined in the android.app and android.os API packages, which do not exist in the Java platform. Id.; see TX 1072 (Android API packages copied from Java begin with “java” or “javax.”); see also RT 2180:3-15 (Astrachan).

The other sample applications, which are more complex than “Hello World” yet still relatively simple, are not interoperable with Java either. For example, the LunarLander application requires classes and methods defined in the android.app, android.content, android.content.res, android.graphics, android.graphics.drawable, android.os, android.util, android.view, android.widget API packages, none of which exist in the Java platform. See LunarLander.java and LunarView.java in TX43cupcake15 - GOOGLE-00- 00000523developmentsamplesLunarLandersrccomexampleandroidlunarlander; TX 1072. Similarly, none of the standard “stock” applications for Android, which include the calculator, calendar, and alarm clock, are interoperable with Java. See, e.g., AlarmClock.java in TX43cupcake15 - GOOGLE-00-00000523packagesappsAlarmClocksrccom androidalarmclock; TX 1072.

When even Google’s simple, sample applications will not run on the Java platform, it confirms what Google said at the inception of Android: Android does not support existing Java applications, and Android is not Java-compatible. TX 383 at 8.

C. How, if at all, have Android and the replication of virtually all of the 37
packages promoted interoperability?

Android’s use of the 37 API packages copied from Java has not promoted interoperability.

Android has harmed interoperability. As discussed in sections II.A and II.B above, Android and the Java platform are not interoperable. Applications and programs written for one will not run on the other. See

7

---

RT 1331:16-1332:2 (Mitchell) (“So you don’t really have compatibility. You can’t ship code from one platform to another.”).

Google will no doubt argue that by copying some of the Java APIs packages it has furthered interoperability to some degree. But Google cannot claim interoperability even for the 37 APIs Google it copied nearly identically because it did not copy everything from those packages. See ECF No. 1124-1 at Ex. A (missing classes and methods in java.awt.font, java.beans, javax.security.auth, java.security.auth.callback, javax.security.auth.login, and javax.security.auth.x500). The result is, as noted above, that many standard Android applications, including “the simplest program you can write in any language” (RT 782:23-783:2 (Bloch)), cannot run on Java. See section II.B supra.

This type of partial, selective copying is harmful to interoperability, not helpful. Google’s strategy, known as “embrace and extend,” was to adopt enough of the Java APIs to attract Java developers to Android, but not enough to make Android compatible. Sun successfully raised a similar claim in the Sun v. Microsoft case, where it alleged Microsoft “embraced” Java by licensing the Java technology and then “extended” it by developing “strategic incompatibilities” in the version of Java it created for the Windows platform. Sun Microsystems, Inc. v. Microsoft Corp., 87 F. Supp. 2d 992, 995 (N.D. Cal. 2000). Judge Whyte recognized how damaging such a partially compatible platform can be:

In the present case, Sun has demonstrated a possibility of irreparable harm, if an injunction restraining Microsoft’s distribution of non-compliant Java Technology is not issued. Microsoft’s unauthorized distribution of incompatible implementations of Sun’s Java Technology threatens to undermine Sun’s goal of cross-platform and cross-implementation compatibility. The threatened fragmentation of the Java programming environment harms Sun’s relationship with other licensees who have implemented Java virtual machines for Win32- based and other platforms. In addition, Microsoft’s unparalleled market power and distribution channels relating to computer operating systems pose a significant risk that an incompatible and unauthorized version of the Java Technology will become the de facto standard. The court further finds that money damages are inadequate to compensate Sun for the harm resulting from Microsoft’s distribution of software products incorporating non-compliant Java Technology as the harm to Sun’s revenues and reputation is difficult to quantify.

8

---

Id. at 997-98. See also ADA v. Delta Dental Plans Ass’n, 126 F.3d 977, 981 (7th Cir. 1997) (noting that “standardization of language promotes interchange among professionals” and “[t]he fact that Delta uses most of the Code but made modifications is the reason ADA objects”).

Google’s distribution of its “free” Android platform is just as harmful to Oracle. Oracle is forced to compete using its for-charge licensing model against an infringing system that is licensed for free. And, similar to Microsoft in the operating system market, Google has achieved a dominant position in the smartphone market, where Android phones containing these incompatible APIs are being activated at a rate of 750,000 phones per day. See RT 1017:4-16 (Morrill).

If Google wanted to promote interoperability, it could have made Android compatible. A well-developed system is in place for promoting the interoperability of Java implementations and the platform’s “write once, run anywhere capability,” supported by many individuals and companies. See, e.g., RT 293:8-296:4 (Ellison); 360:6-363: 10 (Kurian); 2055:7-21 (McNealy). The Java specification license allows an independent implementation if, among other things, it “fully implements” the specification, does not “modify, subset, superset or otherwise extend” the Java name space, and passes the TCK. TX 610.1. Google itself acknowledged that “[t]he only way to demonstrate compatibility with the Java specification is by meeting all of the requirements of Sun’s Technology Compatibility Kit, TCK, for a particular edition of Sun’s Java.” RT 976:16- 978:1 (deemed admission). But Google never even attempted to have Android pass the TCK. (RT at 984:22-24 (Lee).)

Rather than further interoperability by following these procedures and taking a license, Google undermined interoperability by creating an incompatible fork of the Java platform. The uncontroverted evidence at trial was that Google is the only company that is commercially using the Java APIs that has not taken a license. See, e.g., RT 293:8-294:21 (Ellison); 385:20-386:8 (Kurian), 487:10-488:7 (Page). Google is a source of incompatibility, not interoperability.

9

---

D. To what extent was interoperability an actual motive of Google at the time the
decision was made to replicate the 37 packages?

Google never proved interoperability was its motive in replicating the 37 packages. To the contrary, the evidence showed Google did not care about interoperability. It copied what it wanted to provide Java developers with a familiar enough programming environment so they would migrate over to Android.

Under questioning from his own counsel, Google developer Dan Bornstein testified bluntly that interoperability was not one of Google’s goals:

Q. Did Android implement all the API packages present in any particular Java Platform?

A. No.

Q. All right. And why not?

A. That wasn’t a goal of the project. The goal of the project was to provide something that was familiar to developers. It wasn’t to provide any particular preexisting set of packages.

RT at 1783:15-22 (Bornstein).

Daniel Morrill, the technical program manager for Android compatibility, testified at trial that Google has a compatibility program that “is intended to make sure that compatible Android devices can run applications written to the Android SDK.” (1001:10-12, 1009:19-1010:4). But he made it clear Google does not even try to support applications written to the Java SDK:

Q. Now, Android does not support Java applications, correct?

A. That is correct.

Q. And so Android is not Java compatible, correct?

A. That’s correct.

RT 1010:4-7 (Morrill).

Even Google’s counsel conceded that, rather than promote interoperability, Google chose to replace Java API packages with Android packages that Google thought were “better:”

So there were lots of packages that would make no sense to put them in Android, the user interface, some of the other things that make a smart phone a smart phone. So there was no reason to put those in Android.

10

---

Then there were others where we were doing our own Android specific APIs, so there was no need for the Java ones. We had better ones that we wanted to put in for our APIs.

So you started with all of them. You took out the ones that weren’t applicable. You took out the ones where we had better ones. And what you had left was this collection of 51 that were certainly all of the core ones.

RT 1138:21-1139:12 (emphasis added).

Google’s approach stands in contrast to what Andy Rubin claimed Danger did when it created its smartphone platform. Mr. Rubin stated that Danger expressly set out to try to be interoperable with Java. See RT at 1588:19-25 (“Well we wanted to make sure that when somebody, when one of those university students who graduated knew how to program in Java wrote a program, we wanted to make sure that that program could run on other devices too, not only our device. So we wanted to make sure that we were compatible with other devices that happened to be running the Java programming language.”). Mr. Rubin did not claim there was any such goal for Android.

The most Google has argued was that it was trying to create some kind of limited interoperability for the 37 API packages it copied. Dr. Astrachan made this argument. See RT 2183:2-11, 2224:3-8 (Astrachan). Dr. Astrachan, of course, cannot speak directly to Google’s motive, which is not a proper subject of expert testimony. The actual evidence that Google intended to further even this limited form of interoperability was scant. Mr. Lee mentioned it in passing, claiming Google referred back to Sun’s API specifications “to make sure that we were maintaining—not—or maintaining interoperability with their implementations.” RT 1201:12-22 (Lee). Mr. Lee certainly did not claim Google was trying to achieve interoperability overall, however. Instead, he testified that Google only “supports certain Java APIs,” which he described as the “good stuff from Java.” TX 1067 (Lee Dep.) at 48:10-14, 48:16 (played at RT 982:15-21).

In any event, neither Mr. Lee’s nor Dr. Astrachan’s testimony supports the notion that Google was trying to achieve interoperability even with the 37 API packages at issue because, as noted in section II.C above, the parties agree that Google did not include all of the classes or interfaces from even those 37 APIs. See ECF No. 1124.

11

---

Moreover, even if Google had what it thought were “better” APIs, if its motive had been to promote interoperability then in cases where Google had alternate APIs it preferred it still could have supported the use of the existing standard Java user-interface APIs alongside its own. Google presented no evidence at trial that it ever did anything of the kind.

This case is not Sony or Sega for many reasons. See, e.g., ECF No. 853 at 15-16. Of particular relevance here, however, is that Google’s copying has nothing to do with the type of interoperability addressed in those cases. In Sony, the defendant engaged in reverse engineering that was necessary to develop a final product which Sony did not allege infringed its copyrights. Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 600, 603 (9th Cir. 2000). Likewise in Sega, the court found reverse engineering to be fair use “[w]here disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access[.]” Sega Enters. Ltd. V. Accolade, Inc., 977 F.2d, 1510, 1527-28 (9th Cir. 1992). The court emphasized that its decision “does not, of course, insulate Accolade from a claim of copyright infringement with respect to its finished products.” Id. at 1528. Notably, in rejecting the contention that copying Sega’s simple 20 byte initialization code was not fair use, the court distinguished this basic sequence from the console key in Atari v. Nintendo, because “Creativity and originality went into the design of that program.” Id. at 1524 n. 7 (citing Atari v. Nintendo, 975 F.2d 832, 840 (Fed. Cir. 1992).)

Here, Google’s copying was neither “intermediate” nor necessary. Google’s expert admitted that Google could have designed its own APIs and in fact did so elsewhere. See, e.g., RT 2212:25-2213:19 (Astrachan). Dan Bornstein testified that Google’s copying included API packages “where it might―it might not be necessary, but it would be surprising to not find them.” RT 1782:6-1783:10 (Bornstein). Copying to lure a competitor’s developers is not the same as reverse engineering to ensure interoperability. Unlike the Accolade games that would not have functioned on Sega’s Nintendo system unless Accolade copied the 20 byte instruction sequence, Android could have functioned perfectly well if Google had not copied the Java APIs that took more than a decade to build. And unlike Sony and Sega, Android is not interoperable with Java. The reasoning in Sony and Sega does not apply here.

12

---

Dated: May 23, 2012

MORRISON & FOERSTER LLP

By: /s/ Michael A. Jacobs
Michael A. Jacobs

Attorneys for Plaintiff
ORACLE AMERICA, INC.

13

---

1192

KEKER & VAN NEST LLP
ROBERT A. VAN NEST - # 84065
[email]
CHRISTA M. ANDERSON - # 184325
[email]
DANIEL PURCELL - # 191424
[email address telephone fax]

KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[address telephone fax]

KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email address telephone fax]

IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
[email]
GREENBERG TRAURIG, LLP
[address telephone fax]

Attorneys for Defendant
GOOGLE INC.

UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION

ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.

Case No. 3:10-cv-03561 WHA

GOOGLE’S MAY 23, 2012 COPYRIGHT
LIABILITY TRIAL BRIEF

Dept.: Courtroom 8, 19th Floor
Judge: Hon. William Alsup

---

Google hereby responds to the Court’s request for more briefing regarding interfaces, exceptions and interoperability. See Dkt. 1181. Like the other aspects of the SSO of the 37 API packages, interfaces and exceptions are functional requirements for compatibility with the APIs in those packages, and therefore are not copyrightable. Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1522 (9th Cir. 1992) (citing 17 U.S.C. § 102(b)). By implementing the SSO of the 37 API packages, Google increased the extent to which source code is compatible with both the Android and J2SE platforms.

I. The interfaces and exceptions that are publicly declared in the 37 API packages are
functional requirements for compatibility with the APIs in those packages, and
therefore are not copyrightable.

A. With respect to the 37 API packages, J2SE and Android declare substantially
the same number of interfaces, and throw exactly the same number of
exceptions.

In J2SE 5.0, the 37 API packages at issue include declarations for 171 interfaces, while in Android 2.2 (“Froyo”), the 37 API packages include declarations for 158 interfaces. These 158 interfaces in Android 2.2 are a subset of the 171 interfaces in J2SE 5.0, i.e., source code referencing, implementing or extending these 158 interfaces in Android 2.2 will also be compatible with J2SE 5.0. Exhibit A, attached hereto, shows the number of interface declarations on a package-by-package basis.¹ For most of the 37 packages, the number of interface declarations is the same in J2SE and Android. See Ex. A.

In both J2SE 5.0 and Android 2.2, the public methods in the 37 API packages throw 1,257 exceptions. Exhibit B, attached hereto, shows the number of exceptions thrown by the public methods on a package-by-package basis. For each of the 37 packages, the number of exceptions thrown is the same in J2SE and Android. See Ex. B.

B. Example: the Comparable interface.

Interfaces are a listing of methods and fields that “capture what is common across . . . very different things,” with the purpose of allowing standardized, simplified interaction with those

______________________

¹ Exhibits A and B were both created by programmatic analysis of compiled versions of J2SE 5.0 and Android 2.2—i.e., programmatic analysis of compiled versions of the source code that was admitted into evidence as TX 623 (J2SE 5.0) and TX 46 (Android 2.2).

1

---

common features. RT 590:9-11 (Reinhold). Like classes and methods, interfaces have a declaration, and are part of the APIs at issue. TX 984 (The Java Language Specification, 3d ed.) at 114; RT 590:1-3 (Reinhold) (“The term Application Programming Interface includes these interfaces in the classes and methods and everything else.”).

For example, the java.lang package includes a declaration for the “Comparable” interface. This interface has a single method, called compareTo. The source code declaration of the Comparable interface, without comments, is:

public interface Comparable {
. . .

public int compareTo(T o);

}

Ex. C (excerpt from TX 623),² lines 82, 121-22. This means that any class that “implements” the Comparable interface must declare a method called “compareTo” that returns an integer and accepts a single argument that has the same “type” as the class being declared. The documentation for the compareTo method provides that if there are two objects called “x” and “y” that are instantiated from the same class, and that class implements the Comparable interface, the source code expression “x.compareTo(y)” will return a negative integer if x is less than y, a zero if x and y are equal, and a positive integer if x is greater than y. See Ex. C, lines 114-16.

The Comparable interface includes only one method, but an interface can have additional methods or fields. The Comparable interface allows a developer to declare a method that relies on the presence of the compareTo method that is promised for all classes that implement the Comparable interface. For example, the ComparableTimSort.java file, written by Josh Bloch, includes a method that sorts arrays of objects that implement the Comparable interface. See Ex. D (TX 45.2), lines 20-22. At various points in ComparableTimSort.java, the source code generically refers to a “Comparable” object, e.g.:

if (((Comparable) a[runHi++]).compareTo(a[lo])

________________________

² Exhibit C is a printed version of the file licenseebundles/sourcebundles/ tmp/j2se/src/share/classes/java/lang/Comparable.java, from TX 623.

2

---

Ex. D, line 286. The “(Comparable)” syntax indicates that the object “a” must be an object instantiated from a class that implements the Comparable interface. By making use of the interface construct, Josh Bloch was able to write the ComparableTimSort method in a manner that works for any array of Comparable objects. Indeed, if tomorrow a developer were to create a new class that implemented the Comparable interface, Josh Bloch’s ComparableTimSort method would sort an array of objects instantiated from that new class, even though Josh Bloch could not have known about that developer’s new class when he wrote the source code for the ComparableTimSort method.

Had Google not implemented the publicly declared interfaces that are in the 37 API packages, code that depends on them would not work. For example, if Android did not declare the Comparable interface, then a class that includes “implements Comparable” as part of its declaration would not compile. Moreover, had Android omitted the Comparable interface, methods that depend on it, like ComparableTimSort, would not function on the Android platform. Thus, because the public interfaces in the 37 API packages are functionally required for compatibility with the APIs in those packages, those interface declarations are not copyrightable. Sega, 977 F.2d at 1522 (citing 17 U.S.C. § 102(b)).

C. Example: the FileNotFoundException exception.

Exceptions are a type of class used by the Java language to communicate to a program that a particular error has occurred. TX 984 at 297. An exception can signal a problem internal to the program, such as having a beginning index that is greater than the ending index when sorting an array. An exception can also signal an external problem, such as a missing file.

When an error occurs, the method in which the error occurs is said to “throw” the relevant exception. Id. The method can then either address (“catch”) the exception itself, or pass the exception on to the code that called the method.³ In the latter case, the declaration of the method generally must include the word “throws” followed by the type of exception that is thrown. Id. at

________________________

³ Because a method that throws an exception passes that exception to the code that calls the method, the exception can be thought of as part of the “input-output” schema for a method, although it is not the same as the “return” for the method.

3

---

394 (discussing inclusion of throw in method and constructor declarations); see also id. at 301-02, 222 (explaining why not all types of exceptions must be listed in the method declaration). Methods may throw more than one exception.⁴ Id. at 221.

As an example, the method java.io.FileReader FileReader(File file) can throw the java.io.FileNotFoundException. This informs the code that called the FileReader method that the requested file could not be found, and thus could not be read. The declaration of the java.io.InputStream method indicates the type of exception that may be thrown so that developers invoking FileReader know that their code needs to “catch” that type of exception:

public FileReader(File file) throws FileNotFoundException

Ex. E (excerpt from TX 610.2⁵) (emphasis added).

The exceptions named in the throws clause are “part of the contract between the implementor [of the method] and the user [of the method—i.e., the developer writing source code that invokes the method].” TX 984 at 299. Because of this, the Java language specification requires the compiler to check to ensure that exceptions are properly handled. Id. at 299. For example, if “throws FileNotFoundException” is removed from the declaration of a method that throws that exception in the implementation of that method (such as the FileReader method), the class that contains the method will not compile. Id. at 301. In addition, if an application catches that exception, but the method that throws the exception does not have a throw clause with that exception in its declaration, the application that calls the method will fail to compile. Id.

As a result, maintaining the correct information about thrown exceptions in the method declaration is necessary for compatibility. Indeed, the thrown exceptions are part of the method declaration. See TX 984 at 210 (defining “Throws_opt” as part of the “MethodHeader”), 221 (discussing the “throws” clause). Because the thrown exceptions are part of the functional requirements for compatibility with the 37 API packages, they are not copyrightable. Sega, 977

__________________________

⁴ The table in Ex. B counts the total number of exceptions thrown by methods in the public API. Because more than one exception may be thrown by a method, this is larger than the number of methods that throw exceptions.

⁵ Exhibit D is a printed version of the file /java/lang/Comparable.html, from TX 610.2. This file is also available on the web at http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/ Comparable.html.

4

---

F.2d at 1522 (citing 17 U.S.C. § 102(b)).

II. Because the SSO of the 37 API packages is functionally required for compatibility
with the APIs in those packages, it is not copyrightable.

A. Because Android implements the SSO of the 37 API packages, code written
using the APIs in those packages is interoperable between Android and J2SE.

There is no quantitative data in the trial record that demonstrates the extent to which J2SE applications written before Android was released are able to run on the Android platform. Nor is there any quantitative data in the trial record that demonstrates the extent to which post-Android applications are able to run both on the Android and J2SE platforms.

The record does demonstrate, however, that code that relies on APIs that are common to the two platforms will compile and execute on both platforms. RT 2172:6-11 (Astrachan) (“Q. Do you have an opinion, professor, whether, from a computer science perspective, Android and Java are compatible with respect to the methods and other constructors and other items in the classes of the 37 accused packages? A. Yes. For those 37 packages, the code that I write on one platform will run on the other platform.”); see also RT 2171:24-2172:11 (Astrachan); RT 2287:1- 8 (Mitchell) (“I think the point that was illustrated by this code and Dr. Astrachan’s description of it is that, for a given piece of code such as this class that he wrote with a marker, it may run on both platforms if the only things it requires are things that are common to the two”); RT 2292:25- 2293:14 (Mitchell) (agreeing that Dr. Astrachan’s code would work both on the Android and J2SE platforms, and that calling the two platforms “compatible” in this sense is using “a great definition of ‘compatible’”). Professor Astrachan explained this during trial as follows:

Q. Have you formed an opinion, Professor, regarding what, if anything, accounts for the fact that the 37 packages in both have the same structure, organization, and use the same names?

A. Those same names that we have in Android and in Java are needed so that the code inter-operates, so that code I write can be reused in another situation. So for the functionality of using those APIs, the method signatures need to be the same so that the code will inter-operate and meet programmer expectations.

RT 2183:2-11. Ensuring that the signatures used by Android for the APIs in the 37 packages match the signatures used in J2SE “is what allows me to use the libraries on both—use the code I write, like that code up there, on both platforms. Because I’m using those method signatures, my

5

---

code will function the same on both platforms.” RT 2183:17-20; see also RT 2185:5-9 (“that structure of the names of the classes, packages, and methods needs to be the same so that the code will work on both platforms, be compatible, inter-operate, so that I can call the methods. Those need to be the same.”).

Moreover, even to the extent that a J2SE application relies on J2SE APIs that are not supported on the Android platform—or to the extent that an Android application relies on Android APIs that are not supported on the J2SE platform—the portion of the source code that relies on APIs that are common to the two platforms will not need to be rewritten. Thus, even for applications that rely on APIs that are not common to both platforms, the Android and J2SE platforms are still partially compatible. Indeed, Professor Mitchell testified that one reason why he believes Google wanted to use the APIs in the 37 packages is because those APIs “are known and used in existing code.” RT 2289:21-13 (emphasis added); see also RT 1787:23-1788:4 (Bornstein) (“And, actually, not even just a matter of comfort, but there’s a lot of source code out there that wasn’t—you know, wasn’t written by—well, that was written by lots of people that already existed that could potentially work just fine on Android. And if we went and changed all the names of things, then that source code wouldn’t just work—”).

By implementing these core APIs, Google reduced the effort required to “port” an application from one platform (e.g., the J2SE platform) to another (e.g., the Android platform), thus promoting increased interoperability. This effort is similar to what is necessary to “port” applications from, for example, the J2SE platform to a given profile of the J2ME platform, or from one profile of the J2ME platform to another. As Dr. Reinhold testified:

Write once, run anywhere was never a promise that if you wrote code for one Java platform that it would automatically/magically work on another.

The write once, run anywhere promise is relative to a one of the Java platforms. If you write an application that uses Java SE 5, then you can run it on Sun’s implementation, on Oracle’s implementation, on IBM’s implementation, and on others.

Will that same code run on a particular configuration of Java ME? Well, it depends. It might. It might not. It depends which APIs it uses.

RT 725:10-20 (emphasis added).

6

---

In addition, because the Android platform shares a common core set of APIs with the J2SE platform, developers are able to use experience they gain from working with one platform when developing applications for the other platform. Developers expect these core APIs when they write code in the Java language. RT 2202:6-11, 2203:11-15 (Astrachan); RT 2291:1-8 (Mitchell); RT 364:17-21 (Kurian); RT 519:16-520:6 (Screven). In this sense, Android is compatible with the skills and expectations of Java language programmers.

Finally, the record establishes that interoperability was a motive of Google at the time it made the decision to implement the 37 API packages. Google chose the 37 API packages precisely because Java language developers expect them to be present when they write code in the Java language. RT 1782:6-1783:10 (Bornstein). “The goal of the project was to provide something that was familiar to developers.” RT 1783:19-21. And in hiring the contractor Noser to help write source code implementing the 37 API packages, Google explained in its Statement of Work detailing “the responsibilities of Noser and the Project Services to be provided by Noser” that Google was “interested in compatibility with J2SE 1.5 . . . .” TX 2765 at 9, 12 (emphasis added).

B. Under Sega, elements that are functionally required for compatibility are not
copyrightable, regardless of how they are used.

In Sega, the Ninth Circuit held that Accolade’s copying and disassembly of Sega’s firmware code was a fair use, because Accolade’s purpose in copying was “for studying or examining the unprotected aspects of a copyrighted computer program . . . .” 977 F.2d at 1520 (emphasis added). Those unprotected aspects were “the functional requirements for compatibility with the Genesis console—aspects of Sega’s programs that are not protected by copyright. 17 U.S.C. § 102(b).” Id. at 1522 (emphasis added).

The logical order of the Ninth Circuit’s reasoning is important. The Ninth Circuit did not hold that the fair use doctrine allowed Accolade to copy aspects of Sega’s programs that were required for compatibility. Instead, the Ninth Circuit held that functional requirements for compatibility are not protected by the Copyright Act in the first instance. That is, Accolade did not need to rely on the fair use doctrine to establish that it was entitled to copy functional

7

---

requirements for compatibility. Instead, it relied on the fair use doctrine to establish that it was allowed Accolade to copy and disassemble all of Sega’s code to the extent necessary to determine what was functionally required for compatibility.

Because aspects of a computer program that are functionally required for compatibility are not copyrightable, it does not matter what the defendant does with them. Even if the defendant’s product is not compatible with the plaintiff’s product, the plaintiff still cannot assert infringement based only on the copying of unprotected elements. “The protection established by the Copyright Act for original works of authorship does not extend to the ideas underlying a work or to the functional or factual aspects of the work.” Sega, 977 F.2d at 1524 (emphasis added) (citing 17 U.S.C. § 102(b)). A “party claiming infringement may place no reliance upon any similarity in expression resulting from unprotectable elements.” Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1446 (9th Cir. 1994) (quotation marks and citation omitted; emphasis in original). Thus, because the SSO of the 37 API packages is functionally required for compatibility, Google was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.

However, as noted, by implementing the SSO of the 37 API packages, Google intended to promote interoperability. And by implementing that SSO, Google increased the extent to which source code written for one platform will operate on the other.

Dated: May 23, 2012

KEKER & VAN NEST LLP

/s/ Robert A. Van Nest
By: ROBERT A. VAN NEST

Attorneys for Defendant
GOOGLE INC.

8

---