Indeed, Oracle has itself benefitted from the compatibility between the J2SE and Android platforms. For example, Oracle admitted that it accepted Google’s contribution of Josh Bloch’s TimSort.java and ComparableTimSort.java source code and incorporated it into Oracle’s OpenJDK 7, which is the current Oracle release of J2SE.

Oracle (1197 [PDF; Text]) returns to its interoperability argument. However, as we pointed out yesterday, this same interoperability issue exists between the many different Java platforms (J2SE, J2ME, ...).

In the end, nothing to get too excited about in either of these briefs.

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

Docket

05/24/2012 - 1194 - Transcript of Proceedings held on May 23, 2012, before Judge William H. Alsup. Court Reporter/Transcriber Katherine Powell Sullivan, RPR, CRR, CSR, Telephone number 415-794-6659/ Katherine_Sullivan@cand.uscourts.gov. Per General Order No. 59 and Judicial Conference policy, this transcript may be viewed only at the Clerks Office public terminal or may be purchased through the Court Reporter/Transcriber until the deadline for the Release of Transcript Restriction.After that date it may be obtained through PACER. Any Notice of Intent to Request Redaction, if required, is due no later than 5 business days from date of this filing. Redaction Request due 6/14/2012. Redacted Transcript Deadline set for 6/25/2012. Release of Transcript Restriction set for 8/22/2012. (Sullivan, Katherine) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1195 - Exhibit List Joint List of Admitted Trial Exhibits - Phase 1 by Oracle America, Inc... (Jacobs, Michael) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1196 - Exhibit List Joint List of Admitted Trial Exhibits - Phase 2 by Oracle America, Inc... (Jacobs, Michael) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1197 - Brief re 1192 Trial Brief Oracle's May 24, 2012 Copyright Reply Brief filed byOracle America, Inc.. (Related document(s) 1192 ) (Jacobs, Michael) (Filed on 5/24/2012) (Entered: 05/24/2012)

05/24/2012 - 1198 - TRIAL BRIEF Google's May 24, 2012 Copyright Liability Trial Brief by Google Inc.. (Attachments: # 1 Exhibit A, # 2 Exhibit B)(Van Nest, Robert) (Filed on 5/24/2012) (Entered: 05/24/2012)

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

Documents

1197

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’S MAY 24, 2012
COPYRIGHT REPLY BRIEF

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

---

Android is not interoperable with Java. Java applications cannot run on Android. Android applications cannot run on Java. This was intentional. Google did not want an interoperable platform and offers no proof it set out to create one. Google took only what it wanted, hijacking the Java developers by using their familiarity with the Java APIs to get them to program for Android. Google’s “compatibility” claim is not supported by the law or the facts.

I. INTERFACES AND EXCEPTIONS

The parties agree that Android Froyo includes 158 of the 171 interfaces from the 37 API packages in J2SE 5.0. ECF No. 1192 at 1. This illustrates not just the extent of Google’s copying, but also that Google selected the interfaces it wanted to copy. Google’s failure to implement all of the interfaces puts the lie to Google’s claim that “the public interfaces in the 37 API packages are functionally required for compatibility with the APIs in those packages.” Id. at 3. Google’s copying served its own business goals and was not compelled by any compatibility requirement, functional or otherwise. In fact, Google deliberately chose not to be compatible.

Google’s example of the Comparable interface demonstrates this as well. The Java programming language does not require a Comparable interface (TX 1062), and it did not exist in Java before version 1.2 (ECF No. 1192-3 at line 79), so Google did not have to copy it. In J2SE, 50 classes in a variety of packages implement the Comparable interface. Android copies this same structure, but omits a few of the 50 classes. For example, the classes CompositeName and CompoundName from the javax.naming API package each implement Comparable, but Android does not include that package. See TX 610.2 at docsapijavalangComparable.html.

The parties count different numbers of exceptions, but they agree Google copied over 1250 throws clauses. See ECF No. 1192 at 1. Oracle’s exception count shows Google again copied almost all, but not all, of the throws clauses exactly, further confirming that compatibility requirements did not drive its extensive copying. Google gives the example of the FileNotFoundException, which is not required by the Java programming language (TX 1062), but was included in Android anyway. Google failed to include other exceptions defined in J2SE 5.0, such as RefreshFailedException, which is part of Java’s API package javax.security.auth but not

1

---

Android’s version of the package. Compare TX 610.2 at docsapijavaxsecurityauthpackagesummary. html with TX 767 at javaxsecurityauthpackage-summary.html.

II. ANDROID AND JAVA ARE NOT INTEROPERABLE

Android is not interoperable with Java. Surely it is a huge red flag that in response to the Court’s questions about interoperability, Google resorts to claiming Android is “compatible with the skills and expectations of Java language programmers.” ECF No. 1192 at 7.

Google states there is no quantitative data in the record showing the extent to which applications written for one platform will run on the other. Id. at 5. Actually, there is. The testimony of both parties’ experts is 0%. See ECF No. 1191 at 4-5. Google could not identify a single application at trial or in its brief that can run on both platforms. But the record contains plenty of evidence of simple applications that will not run on both platforms because Google left out many Java API packages, apparently in favor of its own “better” APIs. See id. at 3-7.

Google can point only to the short piece of code Dr. Astrachan wrote at trial, and his testimony that “For those 37 packages, the code that I write on one platform will run on the other platform.” ECF No. 1192 at 5. As discussed in Oracle’s opening brief, even this is not true, as Dr. Astrachan himself admitted. See ECF No. 1191 at 3-6. Moreover, Google presented no evidence at trial that its selective API copying will allow the reuse of a significant number of such code fragments. It cites only to Dan Bornstein’s vague statement that “there’s a lot 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.” ECF No. 1192 at 6. Google now claims it selective copying “reduced the effort required to ‘port’ an application” from Java to Android in a way that is “similar” to what is necessary to port an application from one Java platform to another. Id. But the record contains no evidence at all of the effort required to port code from one Java platform to another, or how that compares with porting code from Java to Android. Google’s quotation from Dr. Reinhold has nothing to do with this point. See id.

Google fails to identify any evidence in the record that its copying motive was interoperability. Google cites to only two things. The first is Dan Bornstein’s testimony that the goal was not to create interoperability but only to “provide something that was familiar to

2

---

developers.” ECF 1192 at 7 (quoting RT 1783:19-21 (Bornstein)). Mr. Bornstein confirms immediately before and after this sentence that it was not a goal to implement all of the packages in any Java platform. See RT 1783:15-22 (Bornstein). Google also cites the Noser statement of work, which it quotes as stating Google “was ‘interested in compatibility with J2SE 1.5…..’” ECF No. 1192 at 7 (emphasis in original). But the document requires Noser to provide only a subset of packages, and makes clear Google never intended to fully implement even those, stating Google will deliver “a ‘detailed minimum list of methods and classes to be implemented.’” TX 2765 at 21-22. Google wanted to capture Java developers, not achieve interoperability.

III. GOOGLE DISTORTS THE NINTH CIRCUIT’S HOLDING IN SEGA

Sega is a fair use case. The Ninth Circuit summarized its holding as follows:

We conclude that where 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, disassembly is a fair use of the copyrighted work, as a matter of law. Our conclusion does not, of course, insulate Accolade from a claim of copyright infringement with respect to its finished products.

Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1527-28 (9th Cir. 1993).

Google seizes on the court’s statement that “Accolade copied Sega’s software solely in order to discover the functional requirements for compatibility with the Genesis console―aspects of Sega’s programs that are not protected by copyright.” Id. at 1522. But that statement does not help it here. First, Google did not copy the Java APIs to “discover” anything. The APIs were readily available for viewing online and Google copied them into Android, so the holding of Sega does not even apply. Second, Google has not shown the Java APIs are merely “functional requirements.” The Ninth Circuit did not conduct a detailed analysis of this issue in Sega because the question of infringement in the final product was reserved by Sega and left for remand. See id. at 1528. But the decision shows that in determining whether an element of a computer program is a mere functional requirement the court will look to the level of creative expression involved. That is what the court used to distinguish the S-E-G-A 20 byte initialization code from the “original program” in Atari v. Nintendo, 975 F.2d 832, 840 (Fed. Cir. 1992). Sega, 977 F.2d at 1524 n.7 (emphasis in original). Google witnesses admitted there was significant creative

3

---

expression here. See RT 750:2-752:14 (Bloch); TX 1090 at 128:8-18 (Astrachan Dep.). Third, uses the term “compatibility” very differently from the Ninth Circuit in Sega. The issue in Sega was that defendant’s games “would not operate” on Sony’s console without copying, not that being “compatible with the skills and expectations of Java language programmers” permitted copying. Compare Sega, 977 F.2d at 1515-16 with ECF No. 1192 at 7.

Google also overlooks the fact that Sega was about fair use. It incorrectly claims that under Sega “it does not matter” whether or not it copied to make Android compatible. ECF No. 1192 at 8. Sega requires a defendant to have “a legitimate reason” for even intermediate copying. See, e.g., Sega, 977 F.2d at 1527-28. Google’s interoperability argument does not pass the red face test. Copying to “embrace and extend” is the opposite of what the court endorsed.

IV. SONY V. CONNECTIX

The Court asked the parties to address what Connectix ultimately duplicated to allow desktops to run PlayStation games. The Ninth Circuit and district court opinions do not discuss or analyze this issue. Both courts emphasize that Sony did not accuse the final product of infringement. See, e.g., Sony Computer Entm’t Inc. v. Connectix Corp., 48 F. Supp. 2d 1212, 1217 (N.D. Cal. 1999) (“Sony I”) (“Sony’s copyright infringement claim is based on a theory of intermediate infringement.”); Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 604 (9th Cir. 2000) (“Sony II”) (“nor does Sony contend that Connectix’s final product contains infringing material”). Unfortunately, because Sony is twelve years old, Oracle could not obtain copies of the complete record within the Court’s briefing timetable.

The materials Oracle has been able to retrieve show the content Connectix duplicated is far simpler than the Java APIs. Connectix alleged it “began with an empty table consisting of entry points into the BIOS.” Connectix’s Opening Appellate Brief, 1999 WL 33623860, at *13 (9th Cir. May 27, 1999). The precise nature of this empty table or its entry points is unclear, but most likely it was a list of memory addresses of functions that game programs could invoke as needed. Connectix alleged that about a third to a half of the functions were “standard ‘C’ language functions that would be familiar to any experienced programmer.” Id. Connectix alleged that it implemented 137 of 242 of the functions from Sony’s BIOS. See id. at *18.

4

---

Oracle does not see any reference in the record it retrieved to an application binary interface (“ABI”). An ABI describes low-level system conventions, such as how one routine passes arguments to, and receives a return value from, another. Unlike an API, an ABI does not specify which routines must exist or how they are intended to be used.

As Sony shows, not all interfaces are the same. Nothing in the Sony record suggests that there was significant creativity in the entry point table Connectix copied, in stark contrast to the trial record in this case. Neither opinion addressed whether Connectix copied an original structure, sequence, or organization in its BIOS program or the table. The district court noted that “Sony BIOS consists of a combination of C source code and R3000 micro-processor assembly language.” Sony I, 48 F. Supp. 2d at 1215. The C language does not recognize the concepts of a class or interface hierarchy, and nothing in Connectix’s table approaches the complex interrelationships in the Java APIs. The only reference to sequence at all is Connectix’s claim that its entry point table needed to “contain the same entry points, and be in the same order and format” as Sony’s table. Connectix Opening Appellate Br., 1999 WL 33623860, at *13.

Whether Connectix copied names from Sony’s BIOS, and for what purpose, is also unclear, but it appears to have been very limited, unlike here. Sony alleged that Connectix’s Virtual Game Station (“VGS”) “includes several function names that are identical to function names used in the PlayStation operating system.” Pl.’s Mot. TRO, 1999 WL 33743495 at 2 (N.D. Cal. Feb. 3, 1999). Sony argued this point not to claim that Connectix’s VGS (the final product) was infringing, but instead as evidence to prove that Connectix had, at some intermediate point, disassembled (and therefore copied) Sony’s BIOS when creating the VGS. See id. But it is not clear that the names were used to call the functions—they could have been used for debugging purposes instead—and Connectix’s allegation regarding the table of entry points suggests they were not. Connectix’s Opening Appellate Brief, 1999 WL 33623860, at *13.

In any event, none of this had anything to do with the holding in Sony. Sony, like Sega, was a fair use case about intermediate copying for reverse engineering. See Sony II, 203 F.3d at 608. For the same reasons that Sega does not bear on the copyrightability of the SSO of the Java APIs or absolve Google for its infringement, neither does Sony.

5

---

Dated: May 24, 2012

MORRISON & FOERSTER LLP

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

Attorneys for Plaintiff
ORACLE AMERICA, INC.

6

---

1198

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 24, 2012 COPYRIGHT
LIABILITY TRIAL BRIEF

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

---

I. The exceptions counts in Google’s May 23, 2012 brief

Due to errors in the program used, Google’s May 23, 2012 Brief misstated the number of exceptions thrown by J2SE 5.0 and Android 2.2. As summarized in Exhibit A to this brief, for the 37 packages at issue, the public methods in J2SE 5.0 throw 2,400 exceptions, while the public methods for those packages in Android 2.2 (“Froyo”) throw 2,316 exceptions. For the 37 packages at issue, the public methods in the two platforms throw 2,304 exceptions that are the same in the two platforms, while J2SE throws 107 exceptions that are not thrown by Android— 84 of which are thrown by methods that are not implemented in Android—and Android throws 12 exceptions that are not thrown by J2SE. For most of the packages at issue, the public methods in Android and J2SE throw exactly the same exceptions.¹

II. Oracle’s “compatibility” arguments

Oracle argues in its May 23 brief that the Android and J2SE platforms are not compatible for three reasons, but these reasons are irrelevant to determining whether the SSO of the 37 API packages is copyrightable. Specifically, Oracle argues that Android and J2SE applications are not compatible because Android applications (1) typically use a different “entry point” than J2SE applications, (2) once compiled, are in Dalvik bytecode instead of Java bytecode, and (3) once compiled, typically are stored in “apk” files instead of “jar” files.

First, Oracle’s arguments proceed from an erroneous premise—that the “compatibility” analysis should be based on whether the Android platform is compatible in all respects with the J2SE platform. That misses the point. The purpose of implementing the Java language APIs in Android is to allow developers writing in the freely-available Java language to use the familiar, established and basic APIs that Java language developers all learn. See RT 762:13-23 (Bloch); RT 961:13-962:3 (Swetland); RT 1018:4-23 (Morrill); RT 1769:11-17 (Bornstein). Implementing those APIs in Android allows Java language developers to use the skills and experience they have, and ensures that they can reuse source code that they have written using the APIs in the 37 API packages. RT 2183:2-11 (Astrachan). Without these basic APIs, the Java

_______________________

¹ These numbers are not identical to the numbers reported by Oracle, which may be due to slight differences in how the exceptions were counted.

1

---

language is largely useless. RT 683:14-684:4 (Reinhold); RT 782:9-14 (Bloch); RT 1477:2-13 (Schmidt); RT 1960:4-8 (Schwartz).

The relevant compatibility analysis, therefore, is whether Google’s implementation of the APIs in the 37 packages is compatible with J2SE’s implementation of those APIs from a technical, computer science perspective—and it is. RT 2172:6-11 (Astrachan); RT 2292:25- 2293:14 (Mitchell). It is irrelevant whether Android is compatible, in its entirety, with a specific product of Oracle, with Oracle’s licensing or business model, or with definitions of “compatibility” that Oracle has chosen to adopt for self-serving business reasons.²

Second, each of Oracle’s arguments also points only to superficial distinctions that ignore that source code that uses the APIs that are common to the two platforms is interoperable with both platforms. With respect to the entry point used, Professor Astrachan explained that while J2SE encloses applications in a method called “main,” Android uses a procedure that is “a little different.” RT 2221:11-2222:3. But Professor Astrachan also explained that, aside from this slightly different startup procedure, “[o]therwise nothing else would change.” RT 2221:18 (emphasis added).³ The other two points that Oracle raised—the differences in the bytecode used and the differences between the “apk” and “jar” file formats—are relevant only to the compiled versions of applications. Neither of the latter two points affects whether source code written for the Android platform will function on the J2SE platform or whether source code written for the J2SE platform can be re-used for the Android platform—the salient question for compatibility.

Oracle further argues that these three arguments represent only the “tip of the iceberg,” in that J2SE and Android applications are not fully compatible because Google did not implement all 168 of the J2SE 5.0 API packages. But as Google explained in its May 23 brief, even if source

_________________________

² Oracle implicitly acknowledges in its May 23 brief that its “interoperability” arguments are grounded in its concerns about its “for-charge licensing model” and that it is wedded to the erroneous notion that the only compatibility that matters is the type it prefers, namely that a set of Java APIs is not “compatible” unless it is compatible with “a particular edition of Sun’s Java.” Dkt. 1191 at 9:4-20.

³ Although Professor Astrachan testified that the launch point for applications in Android is “a little different,” there is nothing in the record that states that Android cannot use “main” as an entry point for an Android application. Indeed, a “command line” Android application can use “main” as its entry point.

2

---

code written for one platform uses APIs not available on the other platform, the portions of the source code that rely on common APIs will run on both platforms, which means the platforms are, with respect to those APIs, compatible. See Dkt. 1192 at 6:5-10. Professor Mitchell conceded that this is useful. RT 2289:21-23; see also RT 1787:23-1788:4 (Bornstein).

Oracle’s brief illogically assumes that it would for some reason be better for Android to be incompatible in every sense rather than being, as it is, compatible with the APIs in the 37 packages.⁴ Jonathan Schwartz—Sun’s CEO at the time that Android was launched—testified to the contrary:

Q. And did you actually give interviews in which you said you thought Android was helping Java?

A. I did. . . . .

At least if they picked an Open Source Java implementation, they could be a part of the community. If they had picked something that was completely variant, it would have had no utility to us whatsoever.

RT 1992:2-12.

Indeed, Oracle has itself benefitted from the compatibility between the J2SE and Android platforms. For example, Oracle admitted that it accepted Google’s contribution of Josh Bloch’s TimSort.java and ComparableTimSort.java source code and incorporated it into Oracle’s OpenJDK 7, which is the current Oracle release of J2SE. RT 1865:11-20 (Oracle’s Resp. to Google’s RFA No. 170); RT 822:10-15 (Bloch); see also RT 823:3 (Bloch) (testifying that Dr. Reinhold of Oracle praised the performance of TimSort when J2SE 7 was released). It is undisputed that TimSort is compatible with both the J2SE and Android platforms.

III. Sony Comp. Entm’t, Inc. v. Connectix Corp.

In Sony Comp. Entm’t, Inc. v. Connectix Corp., the Ninth Circuit held that Connectix’s copying and disassembly of the Sony PlayStation BIOS—the “basic input-output system” that was the software program that operated the Sony PlayStation video game console—was a fair use

___________________

⁴ Oracle’s quote from Judge Whyte’s decision in Sun v. Microsoft is inapposite. “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.” RT 725:10-12 (Reinhold). Unlike Microsoft, Google has never claimed that Android is an implementation of J2SE. Android is a different platform than J2SE.

3

---

because Connectix’s purpose in doing so was “for the purpose of gaining access to the unprotected elements of Sony’s software.” 203 F.3d 596, 598, 602 (9th Cir. 2000).

The Ninth Circuit’s opinion does not discuss in any detail precisely what the unprotected elements were; instead, the opinion refers to the “functional” and unprotected elements of the Sony software, without identifying specifically what they are. See, e.g., id. at 603 (“There is no question that the Sony BIOS contains unprotected functional elements.”), 605 (“If Sony wishes to obtain a lawful monopoly on the functional concepts in its software, it must satisfy the more stringent standards of the patent laws.”).

In its opening Ninth Circuit appellate brief, however, Connectix explained that its Virtual Game Station software (“VGS”) emulated both the Sony PlayStation hardware, and the Sony PlayStation BIOS software. In developing VGS, Connectix first emulated the PlayStation’s microprocessor in software. Ex. B (Connectix Br.) at 11.⁵ Connectix also studied the “interaction between Sony’s BIOS and the hardware” and then “wrote software to emulate the hardware functionality.” Id. at 11-12. The Connectix code that emulated the Sony PlayStation hardware dwarfed the Connectix code that it subsequently wrote that emulated Sony’s BIOS, see id. at 31 n.8, much as the Android source code that implements the 37 API packages is dwarfed by the rest of the Android source code.

After Connectix had written its hardware emulation code, it “reverse engineered Sony’s BIOS by running PlayStation games in conjunction with the BIOS and its software emulator of the hardware.” Id. at 12. This was necessary because “[o]perations systems, system interface procedures, and other programs like the Sony BIOS are not visible to the user when they are operating.” Sony, 203 F.3d at 600. Connectix then “proceeded to write code to emulate the necessary BIOS functionality.” Ex. B at 13. This final step was therefore analogous to the process by which Google wrote its own code implementing the 37 API packages. Connectix “began with an empty table consistent of the entry points into the BIOS.” Id. In order to ensure that the VGS was compatible with PlayStation games, this table had to “contain the same entry

___________________

⁵ Google previously filed a copy of Connectix’s opening appellate brief as Exhibit GG to the Reply Declaration of Michael S. Kwun that was filed on August 29, 2011. See Dkt. 369-3.

4

---

points, and be in the same order and format, as the table in Sony’s BIOS.” Id.

It appears that when the software code in PlayStation games invoked the Sony BIOS, this process included the name of the BIOS function that was being accessed. See id. at 13-14 (“Connectix engineers could typically deduce the requisite BIOS functionality by examining the function name, the information sent to and from the BIOS, or the general grouping of functions requested by PlayStation games.”). Through a variety of means, Connectix determined the purpose, parameters and return formats for 137 of the 242 functions implemented in the Sony BIOS,⁶ and then “independently wrote code to implement the required functionality.” Id. at 13- 15 & n.3. A minority of these functions (“a third to a half”) were standard C programming language functions, id. at 13, while the rest were not. In sum, Connectix’s VGS implemented the Sony PlayStation BIOS interfaces. See JONATHAN BAND &MASANOBU KATOH, INTERFACES ON TRIAL 2.0 at 61 (MIT Press 2011) (in Sony, the Ninth Circuit found that intermediate copies were fair use where “they were necessary for the uncovering of elements not protected by Sony’s copyright—specifically, the BIOS’s interface specifications.”).

Again, this process was analogous to the process by which Google implemented the 37 API packages. Google, like Connectix, implemented some but not all of the functions from the plaintiff’s software system, choosing only those functions necessary to accomplish its purpose. For those functions, Google, like Connectix, ensured that it duplicated the same “entry points” and each function’s functionality, including the information sent to and from the system. Many of the Sony functions, like many of the J2SE functions, performed standard functions familiar to any programmer. Google, like Connectix, wrote its own implementing code. Indeed, the key distinction between the present case and Sony, is that Connectix created intermediate copies of Sony’s implementing code, for which it had to rely on fair use. Google did not copy Oracle’s implementing code, and thus section 102(b) itself precludes copyright infringement liability.

________________________

⁶ Connectix implemented only 137 of the 242 functions because those were the only functions invoked by the games that Connectix tested. Id. at 18. This parallels Google’s decision to implement some but not all of the J2SE 5.0 API packages, and most but not all of the JS2E 5.0 exceptions. Moreover, this means that VGS likely was not “fully compatible” with the Sony PlayStation—and that full compatibility is not relevant to the section 102(b) analysis.

5

---

Dated: May 24, 2012

KEKER & VAN NEST LLP

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

Attorneys for Defendant
GOOGLE INC.

6

---