decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Oracle v. Google - The Dispute Over Prof. Mitchell's Patent Report - UPDATED 2Xs
Monday, September 19 2011 @ 09:00 AM EDT

Not to be lost in all of the activity of the last week is Google's pending motion to strike portions of the Mitchell patent report prepared for Oracle. 410 [PDF] Google's argument is that Oracle, through the Mitchell report, is trying to introduce new infringement contentions. Specifically, Google raises three points:

  1. To allege infringement of Claim 11 in the ‘104 patent, the Mitchell Report improperly relies on source code files that were not identified in Oracle’s infringement contentions;
  2. To allege infringement of Claim 1 in the ‘702 patent, the Mitchell Report improperly relies on source code files that were not identified in Oracle’s infringement contentions;
  3. The Mitchell Report improperly includes three accused products not identified by Oracle in its infringement contentions.


Google's arguments turn on local rules that, Google contends, require "pinpoint citations" to allegedly infringing code identifying every limitation (every claim element of the asserted patent). Google argues that Oracle failed to include those pinpoint citations in their original infringement contentions, as required by the local rules, and now is attempting to introduce them through the back door in Prof. Mitchell's report.

If that weren't enough, Google also asserts that Oracle is also trying to introduce three new devices as infringing products (the LG Optimus, HTC Droid Incredible 2 and the Motorola Atrix) that weren't included in Oracle's infringement contentions, once again attempting to introduce them through the back door.

Not surprisingly, Oracle sees the picture a little differently. 435 [PDF] Oracle contends the local rules have no such "pinpoint citation" requirement and that the rules only require the infringement contentions "be sufficient to provide reasonable notice to the defendant why the plaintiff believes it has a ‘reasonable chance of proving infringement.’” This argument will turn on those cases cited by Google which appear to interpret the local rules differently where the infringement contentions involve computer software and the source code for that software has been made available to the plaintiff.

As for the addition of three new devices to the list of infringing devices, Oracle contends that it is Android that infringes and that any list they have provided of devices embodying Android has merely been a representative, not definitive, list. My instincts say that Oracle will likely prevail on this point.

If Oracle is attempting to back door these contentions, the approach doesn't seem to be a new one for the Boies Schiller firm. Boies Schiller pulled the same thing in SCO v. IBM, slipping in new claims in their experts reports. In that case, the magistrate judge sanctioned them by striking the 187 technology disclosures its experts had tried to introduce after the close of discovery. Yet here that firm is again, accused of doing the same thing. Here's the article when the magistrate judge ordered the claims thrown out in the SCO case: http://groklaw.net/article.php?story=2006122614184271

No hearing has been set on this motion to date.

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

UPDATE:

We don't have all of the Mitchell Patent Report, only that portion filed by Oracle, but here is the portion that Oracle produced as Exhibit A. [PDF] We will try to get a transcription of this added in the next day or so.

UPDATE 2: We have it done, and we've placed it at the very end.

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

Docket:

435 – Filed and Effective: 09/15/2011
ORDER
Document Text: RESPONSE (re 410 MOTION to Strike Portions of the Mitchell Patent Report ) Oracle Opposition To Motion To Strike Portions of Mitchell Report filed byOracle America, Inc.. (Peters, Marc) (Filed on 9/15/2011) (Entered: 09/15/2011)

436 – Filed and Effective: 09/15/2011
ORDER
Document Text: DECLARATION of Marc David Peters in Opposition to 435 Opposition/Response to Motion filed byOracle America, Inc.. (Attachments: # 1 Exhibit 1, # 2 Exhibit 2, # 3 Exhibit 3, # 4 Exhibit 4, # 5 Exhibit 5, # 6 Exhibit 6)(Related document(s) 435) (Peters, Marc) (Filed on 9/15/2011) (Entered: 09/15/2011)

437 – Filed and Effective: 09/16/2011
ORDER
Document Text: ORDER GRANTING STIPULATED REQUEST TO EXTEND DISCOVERY CUT-OFF FOR DEPOSITION OF DAVID AUGUST re 432 Stipulation filed by Oracle America, Inc.. Signed by Judge Alsup on September 16, 2011. (whalc1, COURT STAFF) (Filed on 9/16/2011) (Entered: 09/16/2011)

438 – Filed and Effective: 09/16/2011
ORDER
Document Text: ORDER DENYING MOTION TO FILE PRECIS UNDER SEAL, Order by Hon. William Alsup denying 419 Administrative Motion to File Under Seal.(whalc1, COURT STAFF) (Filed on 9/16/2011) (Entered: 09/16/2011)

439 - Filed and Effective: 09/16/2011
Letter
Letter from Michael A. Jacobs REQUEST FOR LEAVE TO FILE PORTIONS OF DEPOSITION TRANSCRIPT (unredacted pursuant to Order--Dkt. 438). (Swoopes, Roman) (Filed on 9/16/2011) (Entered: 09/16/2011)


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

Documents

410

ROBERT A. VAN NEST - #84065
. [email]
CHRISTA M. ANDERSON - #184325
[email]
KEKER & VAN NEST LLP
[address, phone, fax]

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

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

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

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

Honorable Judge William Alsup

Hearing Date: September 29, 2011
Hearing Time: 8:00 a.m.

DEFENDANT GOOGLE INC.’S
MOTION TO STRIKE PORTIONS OF
THE MITCHELL PATENT REPORT

PLEASE TAKE NOTICE that on September 29, 2011 at 8:00 a.m., or as soon thereafter as counsel may be heard, Defendant Google Inc. (“Google”) will, and hereby does, respectfully move to strike portions of the Opening Expert Report of John C. Mitchell Regarding Patent Infringement (the “Mitchell Report,” Ex. A). This Motion is based on the following memorandum of points and authorities in support, the Declaration of Mark H. Francis (“Francis Decl.”) and accompanying exhibits, the entire record in this matter and on such evidence as may be presented at a hearing on this motion.

INTRODUCTION

Oracle presented an expert report that identifies for the first time files and products as central to its patent infringement allegations, which were not previously identified in Oracle’s Disclosure of Asserted Claims and Infringement Contentions (“ICs”). In so doing, Oracle circumvents the requirements of the Patent Local Rules and ignores the Court’s warning that Oracle must provide full disclosure of its infringement theories in its ICs. See Transcript of Proceedings (Dkt. No. 110) at 10:14–11:13 (April 6, 2011). Google therefore requests that all sections of the Mitchell Report discussing or relying upon newly-identified source code files, products or theories be stricken from the report and that Oracle be precluded from introducing these new theories or facts at trial. See Monolithic Power Sys. v. O2 Micro Int’l Ltd., No. 08-cv- 04567, 2009 U.S. Dist. LEXIS 101035 (N.D. Cal. Oct. 16, 2009) (granting a motion to strike portions of an expert report relating to products not identified in the infringement contentions).

As per the Court’s instructions (Dkt. No. 382), Google raises only three specific points of critique in this motion. They are representative of similar problems in other sections of the Mitchell Report, which are not addressed herein. Google therefore respectfully requests leave to seek appropriate additional relief once this motion is decided.

CRITIQUE A – To Allege Infringement of Claim 11 in the ‘104 patent, the Mitchell Report
Improperly Relies on Source Code Files That Were not Identified in Oracle’s ICs

Paragraphs 255, 270, 271, 273, 277, 279, 282, 287, 289, 292, and 296 of the Mitchell Report should be stricken. These paragraphs discuss and rely on the DvmDex.h source code file to meet required elements of claim 11 of the ‘104 patent, and the DvmDex.h file was not

1

identified in Oracle’s ICs.

Patent Local Rule 3-1 (c) required Oracle to provide “[a] chart identifying specifically where each limitation of each asserted claim is found within each Accused Instrumentality.” Patent L.R. 3-1(c) (emphasis added). “Where the Accused Instrumentality includes computer software based upon source code made available to the patentee, patentees must provide ‘pinpoint citations’ to the code identifying the location of each limitation.” Genentech, Inc. v. Trustees of U. of Penn, 10-cv-2037, Dkt. No. 63 at *4 (N.D. Cal. Dec. 13, 2010) (citations omitted, emphasis added); see also Vasudevan Software, Inc. v. International Business Machines Corp., No. 09-cv-05897, 2011 WL 940263 at *7 (N.D.Cal. February 18, 2011) (“the authority is clear that a plaintiff should provide citations once a plaintiff has had a sufficient opportunity to review the source code, at least with respect to contentions that are or may be based upon it.”) (citations omitted).

Oracle’s ICs fail to identify a substantial portion of the code that the Mitchell Report now cites as meeting the claim limitations of U.S. Patent No. RE38,104 (“the ‘104 patent”). One such instance pertains to the requirement in claim 11 for storing a numerical reference. (See Ex. B, ‘104 patent at claim 11 (“determining a numerical reference ... storing said numerical references, and obtaining data in accordance to said numerical references” (emphasis added).) The Mitchell Report repeatedly points to code in the file DvmDex.h as allegedly satisfying the “storing” limitation of claim 11. (See, e.g., Mitchell Report at ¶ 271 (“the DvmDex.h file also has dvmDexSetResolvedClass which serves to store the resolved symbolic reference after the class name gets resolved...” (emphasis in original)); id. at ¶ 277 (“[t]he DvmDex.h file contains the source code for the dvmDexSetResolvedMethod function, which serves to store the resolved symbolic reference...” (emphasis in original)); see also id. at ¶¶ 255, 270, 273, 279, 282, 287, 289, 292, and 296 (all nine paragraphs identify code in DvmDex.h as storing the reference).) It is evident from the Mitchell Report that Oracle’s infringement claims rest on the “storing” limitation in claim 11 being allegedly performed by code in DvmDex.h. But DvmDex.h is never referenced in Oracle’s ICs. (See Ex. C, Oracle’s claim chart on the ‘104 patent (no mention of DvmDex.h).)

2

The issue here is straightforward. On the one hand, Oracle believes that it may rely on source code files not identified in its ICs for key elements of its infringement theories, so long as those files in some way relate to code identified in the ICs. (See Oracle’s Opposition to Google’s Précis Letter, Dkt. No. 380, at 1-2 (asserting that Oracle’s ICs “quote from the Resolve.c source file” that “contains calls” to functions “implemented in the DvmDex.h source file” and thus while the “Report provides more detail,” “the ICs disclose the role of that code.”).) Google, on the other hand, maintains that Oracle’s infringement theories for trial must be consistent with its infringement theories in its ICs. In other words, Oracle is limited to the source code (i.e., the “pinpoint citations” required by the Patent Local Rules), that were identified in its ICs as allegedly meeting the asserted patent claims. Anything less violates the requirement that a plaintiff include “pinpoint citations” to the accused source code. See Genentech at *4. Indeed, by failing to include these files in its ICs, Oracle telegraphed an intention not to cite them and not to rely on them. See Dkt. No. 281 at *7. See generally, Fleming v. Escort, Inc., No. 09-cv- 105, 2011 WL 2173796 at *4 (D. Idaho June 2, 2011) (precluding a party’s expert from relying upon “computer files [that] were not referenced in [its] chart accompanying its Invalidity Contentions” because the other party “had no way of knowing how these 12 files related in any way to the limitations and claims of the patents in dispute until [the expert] filed his expert report. That is precisely what Local Patent Rule 3.3 seeks to avoid.”).

Oracle’s late disclosure is especially egregious given that Android source code and documentation – including the newly identified files – were openly and freely available on the Internet long before Oracle filed suit, such that Oracle did not need formal discovery to develop its infringement theories. Moreover, Dr. Mitchell acknowledges that he personally “participated in the analysis and preparation of” the IC claim charts. (See, e.g., Mitchell Report at ¶ 229.) Oracle therefore has no excuse for the discrepancies between the source code files identified in Oracle’s ICs and what was eventually put forward in the Mitchell Report.

Accordingly, Google respectfully requests that the Court strike from the Mitchell Report ¶¶ 255, 270, 271, 273, 277, 279, 282, 287, 289, 292, and 296 which improperly refer to and rely upon the DvmDex.h file (and source code within that file) that was not identified in Oracle’s ICs.

3

CRITIQUE B – To Allege Infringement of Claim 1 in the ‘702 patent, the Mitchell Report
Improperly Relies on Source Code Files That Were Not Identified in Oracle’s ICs

Similarly, paragraphs 459, 460, 461, 468, 476 and 478 of the Mitchell Report should also be stricken because they discuss and rely on source code files to meet a required element of claim 1 of the ‘702 patent (removing duplicates) that Oracle never identified in its ICs.

As noted above, Patent Local Rule 3-1 (c) required Oracle to provide “[a] chart identifying specifically where each limitation of each asserted claim is found within each Accused Instrumentality.” (Id., emphasis added.) And Oracle was also required to provide “pinpoint citations” to the allegedly infringing source code in its ICs.

A required element of Claim 1 of U.S. Patent No. 5,966,702 (“the ‘702 patent”) is removing duplicated elements from class files. (See Ex. D, ‘702 patent at claim 1 (“determining plurality of duplicated elements ... forming a shared table ... removing said duplicated elements ... and forming a multi-class file” (emphasis added).) As a preliminary matter, Oracle’s ICs do not provide any pinpoint citations to source code for this claim element (see Ex. E at 13-17), as required by law and statute, and only makes passing references to a handful of source code files: DexFile.java, TypeIdsSection.java, TypeIdItem.java, ConstantPoolParser.java (id. at 17).

Putting that aside, the Mitchell Report now alleges that this required claim element of “removing . . . duplicated elements” occurs by way of a “TreeMap” structure (Mitchell Report at ¶ 458) – however, this infringement theory was never discussed or disclosed in Oracle’s ICs. Indeed, Dr. Mitchell now refers to a number of source code files supporting this TreeMap process that were not identified in the ICs either. See id. at ¶ 459 (referring to code in files ClassDefsSection.java, UniformItemSection.java, Section.java); id. at ¶ 461 (referring to code in file FieldIdsSection.java and noting that “[t]his is the step at which removal of duplicate constants is performed”); id. at ¶ 468 (“...The TreeMap will not store more than one copy of a duplicated element. By way of example, the StringIdsSection.java code stores all the strings from the class files into a TreeMap object called “strings,” thereby determining the duplicate strings among the class files.”).

Dr. Mitchell expressly relies upon these files as his only basis for alleging that Android

4

implements the removal of duplicates:
The third element of claim 1, recites “removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files.” The Android dx tool removes the duplicated elements from the plurality of class files (e.g., as part of the process of forming the .dex file multiple copies of the duplicated elements are not added to the tables that will be used to form the .dex file) and obtains a plurality of reduced class files in the form of the ClassDefSection (the ClassDefSection including a subset of the code and data contained in the class files) in the manner discussed above and again here. In particular, and as described above in the Android code, as class files are processed to form a .dex file, TreeMap is used to identify and remove duplicate elements from ClassDefSection (which generally includes the Dalvik byte code associated with the input class files after the identified duplicates have been removed).
Id. at ¶ 476 (emphasis added); see also id. at ¶ 478 (“The information in the ClassDefsSection and the data as shown in the slide form the reduced class files”).

In short, Oracle purposely chose to ignore this required claim limitation in its ICs – failing to provide a single pinpoint citation to any source code. Yet, Oracle now wants to present at trial a whole slew of newly identified source code to justify its allegations for this required claim element. Simply put, Oracle should not be allowed to change its theory this late in the case because the Patent Local Rules require early disclosure of such theories, and further, require leave to amend to change such theories. Accordingly, Google respectfully requests that the Court strike from the Mitchell Report ¶¶ 459, 460, 461, 468, 476 and 478 because they improperly refer to and rely upon the above files that were not identified in Oracle’s ICs.

CRITIQUE C – The Mitchell Report Improperly Includes Three Accused Products Not
Identified by Oracle in its Infringement Contentions

Oracle’s infringement allegations should be limited to the specific products accused in the ICs: Google Dev Phones, Nexus One, Nexus S, HTC’s EVO 4G, HTC’s Droid Incredible, HTC’s G2, Motorola’s Droid, and Samsung’s Captivate. (Ex. F, ICs at § I.B.) The Mitchell Report identifies three additional devices not included in Oracle’s ICs, all of which should be stricken. (See Mitchell Report at ¶ 191 (adding the LG Optimus, HTC Droid Incredible 2 and the Motorola Atrix).)

5

Patent Local Rule 3-1 requires, in relevant part, that infringement contentions provide:
(b) Separately for each asserted claim, each accused apparatus, product, device, process, method, act, or other instrumentality (“Accused Instrumentality”) of each opposing party of which the party is aware. This identification shall be as specific as possible. Each product, device, and apparatus shall be identified by name or model number, if known. Each method or process shall be identified by name, if known, or by any product, device, or apparatus which, when used, allegedly results in the practice of the claimed method or process;

...

(d) For each claim which is alleged to have been indirectly infringed, an identification of any direct infringement and a description of the acts of the alleged indirect infringer that contribute to or are inducing that direct infringement. Insofar as alleged direct infringement is based on joint acts of multiple parties, the role of each such party in the direct infringement must be described.

...

(Emphasis added.) According to these rules, products accused of direct or indirect infringement must be explicitly identified in a plaintiff’s infringement contentions. Oracle’s generalized assertions of infringement by “Google devices running Android” or “other mobile devices running Android” are insufficient under the Patent Local Rules to extend Oracle’s infringement allegations to cover unidentified products, as are attempts to suggest that the identified products are merely “representative.” See Bender v. Advanced Micro Devices, Inc., No. 09-cv-1149, 2010 U.S. Dist. LEXIS 11539 at 3 (N.D. Cal. February 1, 2010) (“even if [the plaintiff] can establish that it is appropriate to use representative claim charts, he has not in all instances adequately identified the accused products at issue. Pursuant to Rule 3-1(b), the patentee’s identification of which accused products allegedly infringe cannot be so amorphous or imprecise so as to force the opposing party to essentially ‘guess which versions of its products’ are allegedly infringing. InterTrust Techs. Corp. v. Microsoft Corp., No. C 01-1640 SBA, 2003 U.S. Dist. LEXIS 22736, at *6 (N.D. Cal. Nov. 26, 2003)”); Bender v. Advanced Micro Devices, Inc., No. 09-cv-01152, 2010 U.S. Dist. LEXIS 89957 at *9 (N.D. Cal. July 29, 2010) (“plaintiff must identify each accused product and link it to a representative product [claim chart] in order to provide [the defendant] with fair notice of the specific products which are accused in this lawsuit.”).

6

Some courts have held that a party may rely on representative products in ICs to seek discovery on similar products (see, e.g., Honeywell Int’l, Inc. v. Acer America Corp., 655 F. Supp. 2d 650 (E.D.Tex. 2009)), however, parties need “good cause” to amend their contentions and identify new products. See generally LG Elecs., Inc. v. Q-Lity Computer, Inc. v. Asustek Computer, Inc., 211 F.R.D. 360 (N.D. Cal. December 4, 2002); Atmel Corp. v. AuthenTec, Inc., No. 06-cv-2138, 2008 U.S. Dist. LEXIS 10846 (N.D. Cal. January 31, 2008). In any event, fact discovery closed without Oracle ever seeking leave to amend its contentions to add newly released or newly identified products. In particular, Oracle never moved for leave to include the LG Optimus, HTC Droid Incredible 2 or the Motorola Atrix as accused products.

Determining which specific products stand accused is of paramount importance to get this case trial-ready and to better understand the full extent of Google’s potential exposure regarding Oracle’s indirect infringement allegations. Oracle’s general accusation against Google’s “Android platform” itself is untenable in many respects. First, Oracle’s entire indirect infringement allegation is contingent on the same version of Android (i.e., the exact same source code) being implemented in third party devices. Yet, third parties can modify Android source code before placing it on their devices, and Oracle’s allegations must account for the specific source code in each of the devices it accuses of infringement. Oracle should not be allowed to hand-wave over its burdens of proof in the same manner it disregards the Patent Local Rules of this Court. Second, many asserted claims are “method” claims (e.g., ‘104 patent claims 27 and 39; ‘702 patent claims 1 and 6), and as such, Oracle must demonstrate actual use of the patented functionality on an accused device – not just the capability in software code. See Muniauction, Inc. v. Thomson Corp., 532 F.3d 1318, 1328 (Fed. Cir. 2008) (“a method claim is directly infringed only if each step of the claimed method is performed”). Third, many asserted claims explicitly require physical components like a computer processor and memory (e.g., ‘104 patent claims 22 and 40; ‘702 patent claims 13, 15 and 16) but Android itself is purely software, so alleged infringement of these claims must be directed at a physical device. Accordingly, Google respectfully requests that any assertions of patent infringement are limited to the products explicitly identified in Oracle’s ICs.

7

CONCLUSION

Google will be unfairly prejudiced if Oracle is permitted to circumvent the Patent Local Rules and improperly introduce entirely new theories of liability in the Mitchell Report at this very late stage of the case, so close to trial. And Oracle has no excuse in this case, where it has targeted publicly available open source code.

Google does not seek an order to strike the Mitchell Report in its entirety, but rather to strike the sections that go beyond the allegations set forth in the infringement contentions. For the forgoing reasons, Google respectfully requests the Court grant the relief it deems appropriate, such as an order providing that Oracle and its experts cannot refer to or rely upon source code that was not specifically identified in the infringement contentions to support its allegations of infringement of the ‘104 patent (i.e., ¶¶ 255, 270, 271, 273, 277, 279, 282, 287, 289, 292, and 296) and of the ‘702 patent (i.e., ¶¶ 459, 460, 461, 468, 476 and 478), and that any assertions of patent infringement are limited to the products explicitly identified in the infringement contentions (i.e., Google Dev Phones, Nexus One, Nexus S, HTC’s EVO 4G, HTC’s Droid Incredible, HTC’s G2, Motorola’s Droid, and Samsung’s Captivate). Google further requests leave to file, at the appropriate time, a motion to strike or a motion-in-limine concerning additional portions of the Mitchell Report not raised in this motion.

8

DATED: September 8, 2011

KEKER & VAN NEST, LLP

By: /s/ Christa M. Anderson

ROBERT A. VAN NEST (SBN 84065)
[email]
CHRISTA M. ANDERSON (SBN 184325)
[email]
KEKER & VAN NEST LLP
[address, phone, fax]

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

DONALD F. ZIMMER, JR. (SBN 112279)
[email]
CHERYL A. SABNIS (SBN 224323)
[email]
KING & SPALDING LLP
[address, phone, fax]

IAN C. BALLON (SBN 141819)
[email]
HEATHER MEEKER (SBN 172148)
[email]
GREENBERG TRAURIG, LLP
[address, phone, fax]

ATTORNEYS FOR DEFENDANT
GOOGLE INC.

9

I hereby attest that Christa M. Anderson concurs in the e-filing of this document.

/s/ Cheryl A. Sabnis /s/
Cheryl A. Sabnis

10


410-Attachment 1

ROBERT A. VAN NEST - #84065
. [email]
CHRISTA M. ANDERSON - #184325
[email]
KEKER & VAN NEST LLP
[address, phone, fax]

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

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

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

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

DECLARATION OF MARK H. FRANCIS IN SUPPORT OF DEFENDANT GOOGLE
INC.S’ MOTION TO STRIKE PORTIONS OF THE MITCHELL PATENT REPORT

Date: September 29, 2011
Time: 8:00 a.m.
Courtroom: 9, 19th Floor
Judge: The Honorable William Alsup

Trial Date: October 31, 2011

1

I, MARK H. FRANCIS, declare as follows:

  1. I am an associate in the law firm of King & Spalding LLP, counsel for defendant Google Inc. (“Google”) in this case. I submit this declaration in support of Google’s Notice of Motion and Motion To Strike Portions of Mitchell Patent Report. I make this declaration based on my own personal knowledge. If called as a witness, I could and would testify competently to the matters set forth herein.
  2. Attached to this declaration as Exhibit A is a true and correct copy of the cover page, a portion of page 64, pages 81-132, 196-218 and 384 from the August 8, 2011 Opening Expert Report of John C. Mitchell Regarding Patent Infringement Submitted on Behalf of Plaintiff Oracle America, Inc. A confidentiality designation has been removed from the cover page because confidential information is not included in the excerpts included in Exhibit A.
  3. Attached to this declaration as Exhibit B is a true and correct copy of U.S. Patent No. RE 38,104 (“the ‘104 patent”).
  4. Attached to this declaration as Exhibit C is a true and correct copy of pages 14-67 from the infringement claim chart on the ‘104 patent, which was attached as Exhibit A to Oracle’s Second Supplemental Patent Local Rule 3-1 Disclosure of Asserted Claims and Infringement Contentions, served on April 1, 2011.
  5. Attached to this declaration as Exhibit D is a true and correct copy of U.S. Patent No. 5,966,702 (“the ‘702 patent”)
  6. Attached to this declaration as Exhibit E is a true and correct copy of pages 13-17 from infringement claim chart on the ‘702 patent, which was attached as Exhibit C to Oracle’s Second Supplemental Patent Local Rule 3-1 Disclosure of Asserted Claims and Infringement Contentions, served on April 1, 2011.
  7. Attached to this declaration as Exhibit F is a true and correct copy of the first three pages of Oracle’s Second Supplemental Patent Local Rule 3-1 Disclosure of Asserted Claims and Infringement Contentions, served on April 1, 2011.

2

I declare under penalty of perjury that all the foregoing facts are true and correct and that this declaration was executed on September 8, 2011 in New York, New York.

/s/ Mark H. Francis /s/
Mark H. Francis

I hereby attest that Mark H. Francis concurs in the e-filing of this document.

/s/ Cheryl Sabnis /s/
Cheryl Sabnis

3


435

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

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

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email]
[address, phone, 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 OPPOSITION TO GOOGLE INC.’S
MOTION TO STRIKE PORTIONS OF THE MITCHELL PATENT REPORT

Date: September 29, 2011
Time: 8:00 a.m.
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

TABLE OF CONTENTS

Page

I. INTRODUCTION .......... 1

II. LEGAL STANDARD ....... 1

III. ARGUMENT ............ 2

A. Response to Critique A: The Report on Infringement of Claim 11 of the ’104 Patent Is Supported by the ICs ... 2

B. Response to Critique B: The Report on Infringement of Claim 1 of the ’702 Patent Is Supported by the ICs ... 7

C. Response to Critique C: The Report on the Scope of the Accused Instrumentalities Is Supported by the ICs ... 10

IV. CONCLUSION ........... 13

i

TABLE OF AUTHORITIES

Page(s)

Cases

Am. Video Graphics, L.P. v. Elec. Arts, Inc.,
359 F. Supp. 2d 558 (E.D. Tex. 2005) ... 6

Big Baboon Corp. v. Dell, Inc.,
723 F. Supp. 2d 1224 (C.D. Cal. 2010) ... 6

Bowoto v. Chevron Corp.,
No. C 99-02506 SI, 2006 U.S. Dist. LEXIS 65139 (N.D. Cal. Aug. 29, 2006) ... 6

DataTreasury Corp. v. Wells Fargo & Co.,
No. 2:06-CV-72 DF, 2010 U.S. Dist. LEXIS 110658 (E.D. Tex. Sept. 13, 2010) ... 2

Diagnostic Sys. Corp. v. Symantec Corp.,
Nos. SACV 06-1211 DOC (ANx), SACV 07-960 DOC (ANx), 2009 U.S. Dist. LEXIS 53916 (C.D. Cal. June 5, 2009) ... 6

Fenner Invs., Ltd. v. Hewlett-Packard Co.,
No. 6:08-CV-273, 2010 U.S. Dist. LEXIS 17536 (E.D. Tex. Feb. 26, 2010) ... 2, 12

Genentech, Inc. v. Trustees of the Univ. of Pa.,
No. C 10-2037-LHK (PSG), 2010 U.S. Dist. LEXIS 142450 (N.D. Cal. Dec. 13, 2010) ... 5, 6

Orion IP, LLC v. Staples, Inc.,
407 F. Supp. 2d 815 (E.D. Tex. 2006) ... 6
Shared Memory Graphics LLC v. Apple, Inc.,
No. C-10-2475 VRW (EMC), 2010 U.S. Dist. LEXIS 138868 (N.D. Cal. Dec. 30, 2010) ... 2, 12

Sicurelli v. Jeneric/Pentron Inc.,
No. 03-CV-4934 (SLT) (KAM), 2005 U.S. Dist. LEXIS 42233 (E.D.N.Y. May 3, 2005) ... 2, 9

Vasudevan Software, Inc. v. Int’l Business Machines Corp.,
No. C09-05897 RS (HRL) (N.D. Cal. Feb. 18, 2011) ... 5

Other Authorities

Compatibility Definition Document for Android 2.2, available at
http://source.android.com/compatibility/android-2.2-cdd.pdf ... 11

Civ. L.R. 3-4(e) ... 5

ii

Dan Morrill, On Android Compatibility, available at:
http://android- developers.blogspot.com/2010/05/on-android-compatibility.html ... 11

Pat. L.R. 3-1(b) ... 1

Pat. L.R. 3-1(c) ... 1

iii

I. INTRODUCTION

Oracle opposes Google’s motion to strike portions of the Mitchell Opening Patent Infringement Report (“Report”).1 Oracle’s Infringement Contentions (“ICs”) notified Google in detail how Android infringes the asserted claims and which Android “instrumentalities” are accused. The ICs span more than 400 pages. That Google needed to attach a 59-page excerpt from the ICs just to explain Oracle’s infringement theories as to two asserted claims reveals how detailed the ICs are. The Report provides only additional explanation and evidence to support the infringement theories disclosed in Oracle’s ICs. Where the Report quotes from additional Android source code files, it does so only to explain in more detail how Android infringes the asserted patent claims. To support Oracle’s contention that all Android devices have the same infringing elements, the Report shows that device manufacturers use the Google-provided source code on their Android devices without modifying those elements. The Report is fully supported by the ICs. It does not introduce any new infringement theories or accused instrumentalities.

Google’s motion is not properly directed to whether the Report deviates impermissibly from the ICs. Instead, Google’s motion is based on a belated challenge to the adequacy of Oracle’s ICs. But the time for challenging the ICs passed long ago. Moreover, at a Court directed meet-and-confer on the ICs, Oracle invited Google to pose any questions it wished if it had difficulty understanding the scope of Oracle’s infringement theories. Google never responded. Google is responsible for failing to seek clarification, whether informally as invited or formally by moving to compel more detailed ICs. Google should not be allowed to use the Report as a vehicle to express its dissatisfaction with the ICs at this late stage in the case.

II. LEGAL STANDARD

The applicable legal standard may be found in the text of the local rule and from decisions in this district and elsewhere that address similar issues. The Patent Local Rules require an identification of each Accused Instrumentality and a “chart identifying specifically where each

________________________

1 Portions of Prof. Mitchell’s Opening Patent Infringement Report are attached as Exhibit A to the Declaration of Mark H. Francis in Support of Defendant Google Inc.’s Motion to Strike Portions of the Mitchell Patent Report (“Francis Decl.”).

1

limitation of each asserted claim is found within each Accused Instrumentality.” Pat. L.R. 3-1(b)- (c). Google incorrectly states that “Oracle was also required to provide ‘pinpoint citations’ to the allegedly infringing source code in its ICs.” (Mot. at 4.) The Patent Local Rules do not require such detail. Rather, infringement contentions “must be sufficient to provide reasonable notice to the defendant why the plaintiff believes it has a ‘reasonable chance of proving infringement.’” Shared Memory Graphics LLC v. Apple, Inc., No. C-10-2475 VRW (EMC), 2010 U.S. Dist. LEXIS 138868, at *10-11 (N.D. Cal. Dec. 30, 2010) (quoting View Eng’g, Inc. v. Robotic Vision Sys., Inc., 208 F.3d 981, 986 (Fed. Cir. 2000)). Oracle’s ICs did that, and more.

Although expert reports on patent infringement may not introduce infringement theories not previously set forth in the patentee’s infringement contentions, the “scope of infringement contentions and expert reports are not, however, coextensive.” Fenner Invs., Ltd. v. Hewlett- Packard Co., No. 6:08-CV-273, 2010 U.S. Dist. LEXIS 17536, at *6-7 (E.D. Tex. Feb. 26, 2010). “[E]xpert reports are expected to provide additional information regarding the specific factual bases for plaintiffs’ infringement contentions.” Sicurelli v. Jeneric/Pentron Inc., No. 03-CV- 4934 (SLT) (KAM), 2005 U.S. Dist. LEXIS 42233, at *33 (E.D.N.Y. May 3, 2005). Thus, expert reports may provide additional explanation and evidence to support the infringement theories disclosed in the infringement contentions. See DataTreasury Corp. v. Wells Fargo & Co., No. 2:06-CV-72 DF, 2010 U.S. Dist. LEXIS 110658, at *23 (E.D. Tex. Sept. 13, 2010) (denying defendant’s motion to strike portions of plaintiff’s infringement expert report because report did “not substantially deviate from [the] infringement contentions”). This is only common sense— otherwise, the Patent Local Rules would have done away with infringement and invalidity reports altogether.

III. ARGUMENT

A. Response to Critique A: The Report on Infringement of Claim 11 of the ’104 Patent Is Supported by the ICs

The ’104 patent is directed to systems and methods for resolving symbolic references to numerical references. (See ECF No. 137 (“Claim Construction Order”) at 22.) Claim 11 of the ’104 patent recites, inter alia, “determining a numerical reference corresponding to said symbolic

2

reference [and] storing said numerical references.” (Declaration of Mark H. Francis in Support of Defendant Google Inc.’s Motion to Strike Portions of the Mitchell Patent Report (“Francis Decl.”) Ex. B, ’104 patent col.7 ll.5-14 (emphasis added).)

Oracle’s ICs for the ’104 patent disclose two different infringement theories. (Declaration of Marc D. Peters in Support of Oracle America, Inc.’s Opposition to Google Inc.’s Motion to Strike Portions of the Mitchell Patent Report (“Peters Decl.”) Ex. 1, ICs Ex. A.) The ICs include a detailed, sixty-seven-page claim chart mapping specific Android components or functionalities to each claim limitation. (See id.)

The first infringement theory involves the Android “dexopt” tool, which is a tool for verifying and optimizing the classes in a Dalvik executable (“.dex”) file. The ICs summarize this infringement theory by quoting an admission from Dan Bornstein, an Android engineer, that when a .dex file arrives on a device, “it will have symbolic references to methods and fields, but afterwards it might just be . . . a simple integer vtable offset so that when, for invoking a method, instead of having to do say a string-based lookup, it can just simply index into a vtable.” (Id. at 2.) As Mr. Bornstein described, the dexopt tool tries to resolve the symbolic references in the instructions contained in the .dex file and stores or replaces the symbolic references with corresponding numerical references.

The ICs map the DexOptimize.c and Optimize.c Android source code files to the “storing” limitation. (Id. at 43-67.) Those source files include the dvmOptResolveInstField and dvmOptResolveStaticField functions, which, as their names suggest, resolve a symbolic reference to a field. (Id. at 49-53.2) The quoted source code shows that both functions call the dvmDexSetResolvedField function. (Id. at 50, 53.) The comments to those calls show that the dvmDexSetResolvedField function stores the resolved reference. (Id. at 50 (“Add it to the resolved table so we’re faster on the next lookup.”); see also id. at 52 (the same).) The ICs thus specify how the dexopt tool stores the resolved references for later use, and thereby infringe the ’104 patent.

________________________

2 The referenced functions and comments are highlighted in the claim charts attached to the Peters Declaration.

3

The Report tracks the “dexopt” infringement theory. The Report quotes the same admission by Bornstein and explains that the dexopt tool “looks at every instruction in a method and tries to resolve symbolic references and determines, stores, or replaces symbolic references with corresponding numeric references (i.e., Android quickens the instructions where Android can).” (See Report ¶¶ 233, 248.) The Report quotes source code from the Optimize.c source file, just like the ICs, to show how Android meets the “storing” limitation. (Id. ¶¶ 250-54.) Specifically, the Report explains that the dvmOptResolveInstField function implemented in the Optimize.c source file can resolve a field and store data about the resolved field in a table for later use. (Id. ¶ 253.) The Report traces the dvmOptResolveInstField function to a call to the dvmDexSetResolvedField function. (Id.) That called function is implemented in the DvmDex.h file. (See id. ¶ 255.) The Report quotes from the DvmDex.h file to explain that the called function uses “a table indexed by the field index in the constant pool to write . . . the resolved field information.” (Id.) Accordingly, the Report quotes from the DvmDex.h file to detail the role of the dvmDexSetResolvedField function, which is already disclosed in the ICs. The Report simply cites additional support for the theory disclosed in the ICs.

Oracle’s second infringement theory involves the Dalvik virtual machine itself. The ICs summarize this infringement theory by referencing comments from an Android engineer, which are located in the Resolve.h file, that “constant pool references are resolved into pointers to VM structs.” (Peters Decl. Ex. 1 at 2 (internal quotation marks omitted).) The ICs map the Resolve.c source file to the “storing” limitation. (Id. at 17-34.) That source file implements the dvmResolveClass function (among others), which, according to the comment to this call in the quoted source code, “cache[s] a copy of the lookup in the DexFile’s ‘resolved class’ table, so future references to ‘classIdx’ are faster.” (Id. at 18.) The dvmResolveClass function further contains a call to the dvmDexSetResolvedClass function, as identified in the ICs. (Id. at 21.) The comment to this call in the quoted source code explains that the called function stores the numerical reference (resClass, the pointer to the class object) to a resolved class. (Id. (“Add what we found to the list so we can skip the class search next time through.”).)

4

The Report tracks this second infringement theory by also quoting from the Resolve.c source file to show how the Dalvik virtual machine meets the “storing” limitation. (Report ¶¶ 265-69.) The Report explains that the dvmResolveClass function implemented in the Resolve.c source file resolves symbolic references such as class names to numerical references such as a pointer to the class object. (Id. ¶ 269.) The Report traces the dvmResolveClass function to a call to the dvmDexSetResolvedClass function. (Id. ¶¶ 269, 271.) Again, that called function is implemented in the DvmDex.h file. (See id. ¶ 271.) The Report quotes from the DvmDex.h file to explain that the called function “serves to store the resolved symbolic reference after the class name gets resolved . . . .” (Id.) Accordingly, the Report quotes from the DvmDex.h file to provide more explanation about how the Dalvik virtual machine meets the “storing” limitation.

Similarly, Oracle’s ICs identify calls in Resolve.c to functions for storing numerical references to methods (dvmDexSetResolvedMethod function, Peters Decl. Ex. 1 at 25, 28), fields (dvmDexSetResolvedField, id. at 30, 32), and strings (dvmDexSetResolvedString, id. at 33). All of those called functions are implemented in the DvmDex.h file. The Report discusses the Resolve.c source file and further explains the roles of the functions called in Resolve.c by quoting from the DvmDex.h file. (See Report ¶¶ 270, 271, 273, 277, 279, 282, 287, 289, 292, and 296.) So Google is overreaching in its motion—there is no cause to strike the discussion of Resolve.c in those Report paragraphs.

Oracle’s ICs gave Google detailed accounts of Oracle’s two Claim 11 infringement theories. That the ICs do not quote directly from the DvmDex.h file could not have “telegraphed an intention . . . not to rely on them.” (Mot. at 3.) The claim charts identified the functions that are implemented in the DvmDex.h file, mapped them to the “storing” limitation, and thereby clarified Oracle’s intent to rely on the DvmDex.h file for this limitation. Accordingly, the Report’s reference to the DvmDex.h file is consistent with the two infringement theories disclosed in Oracle’s ICs.

Google’s effort to limit the scope of the Report to the specific source code reproduced verbatim in Oracle’s ICs is unavailing. The decisions on which Google relies are inapposite. As

5

a preliminary matter, Vasudevan Software, Inc. v. Int’l Business Machines Corp., No. C09-05897 RS (HRL) (N.D. Cal. Feb. 18, 2011), is marked “NOT FOR CITATION” and should not have been cited to this Court. See Civ. L.R. 3-4(e). Genentech, Inc. v. Trustees of the Univ. of Pa., No. C 10-2037-LHK (PSG), 2010 U.S. Dist. LEXIS 142450 (N.D. Cal. Dec. 13, 2010), involved claims of infringement against a breast cancer therapeutic drug, not source code. The patentee there was ordered to provide “pinpoint citations” to the accused drug in the context of a motion to compel detailed infringement contentions. Id. at *7-11. All of the decisions on which Genentech relied for requiring “pinpoint citations” to the accused instrumentalities involved motions to compel detailed infringement contentions. See Big Baboon Corp. v. Dell, Inc., 723 F. Supp. 2d 1224, 1225 (C.D. Cal. 2010) (motion to compel adequate infringement contentions); Diagnostic Sys. Corp. v. Symantec Corp., Nos. SACV 06-1211 DOC (ANx), SACV 07-960 DOC (ANx), 2009 U.S. Dist. LEXIS 53916, at *7-8 (C.D. Cal. June 5, 2009) (motion to compel “a more definite infringement statement”); Am. Video Graphics, L.P. v. Elec. Arts, Inc., 359 F. Supp. 2d 558, 560-61 (E.D. Tex. 2005) (motion to supplement infringement “charts with specific references to the source code”). Requiring pinpoint citations to defendant’s source code may be appropriate if the defendant moves to compel such citations on the ground that the defendant does not understand the scope of the infringement contentions without them. See Big Baboon, 723 F. Supp. 2d at 1227-28. But these cases do not stand for the proposition that expert reports must be limited to the lines of source code identified in the infringement contentions.

Google’s actions demonstrate that Oracle’s ICs are sufficient. Google complained to the Court about the adequacy of Oracle’s initial ICs in February 2011. (ECF No. 79.) Although the initial ICs provided sufficient notice of Oracle’s infringement theories and accused instrumentalities, Oracle explained them in a response letter brief to this Court. (ECF No. 82.) In the resulting Court-directed meet-and-confer on the ICs, Oracle invited Google to pose any questions it wished if it had difficulty understanding Oracle’s ICs. (Peters Decl. ¶ 1.) Google never posed any queries that correspond to the complaints it makes in its current motion. (Id.) As the parties agreed, Oracle served second supplemental ICs in April 2011. Again Google never moved to compel Oracle to provide more detailed ICs or additional pinpoint citations to Android

6

source code, nor even asked informally for more details such as the ones in the Report it now complains of. The Court-imposed deadline for bringing discovery motions has passed. Google has thus waived its right to challenge the adequacy of Oracle’s ICs. See Orion IP, LLC v. Staples, Inc., 407 F. Supp. 2d 815, 818 (E.D. Tex. 2006) (“A defendant cannot lay behind the log until late in the case and then claim it lacks notice as to the scope of the case or the infringement contentions.”); see also Bowoto v. Chevron Corp., No. C 99-02506 SI, 2006 U.S. Dist. LEXIS 65139, at *5 (N.D. Cal. Aug. 29, 2006) (denying motion to compel additional discovery because defendants had “no good reason for the month-long delay in bringing their motion to compel”). After failing to move to compel supplemental ICs in a timely manner, Google cannot now disguise its discontent with Oracle’s ICs as a motion to strike portions of the Report. The ICs gave sufficient notice of Oracle’s infringement theories and the Report properly provides additional detail to explain those theories. There are no new infringement theories in the Report.

B. Response to Critique B: The Report on Infringement of Claim 1 of the ’702 Patent Is Supported by the ICs

The ’702 patent is directed to systems and methods for pre-processing and packaging class files by class removing duplicate information from them. (See Claim Construction Order at 8-11.) Claim 1 of the ’702 patent recites, inter alia, “removing said duplicated elements from said plurality of class files . . . .” (Francis Decl. Ex. D, ’702 patent col.51 ll.2-11 (emphasis added).)

Oracle’s ICs disclose that Android’s dx tool infringes Claim 1 when it transforms class files compiled by a Java language compiler into a .dex file. (Peters Decl. Ex. 2, ICs Ex. C.) Oracle’s ICs for the ’702 patent cite to Android source code, presentation slides entitled “Dalvik Virtual Machine Internals, Google I/O 2008,” which were presented by Dan Bornstein, the author of the dx tool, and other documentary evidence. (Id.) To show that the dx tool performs the “removing” limitation, Oracle chose to use Bornstein’s presentation slides, which were filled with admissions that the dx tool operates in a way that would infringe the ’702 patent, rather than quote from Android source code files. Specifically, Bornstein’s presentation slides on “Dex File Anatomy” illustrate how the dx tool removes duplicated constants from multiple class files to create a single constant pool table in a .dex file. (Id. at 13-16.) The presentation slides point out

7

that the resulting .dex file has five types of constant pools with no duplicated constants: string_ids, type_ids, proto_ids, field_ids, and method_ids. (Id.) The ICs identify other sections of the .dex file (the “class_defs” section and other data) as the reduced class files. (Id.)

Even though the slides provide sufficient notice of Oracle’s infringement theory, Oracle’s ICs also cite to the TypeIdsSection.java file as meeting the “removing” limitation of Claim 1. (Id. at 17.) TypeIdsSection, as its name suggests, corresponds to the type_ids constant pool. As Prof. Mitchell explained in a recent deposition, “these different sections [of the constant pool table] are all coded similarly.” (Peters Decl. Ex. 3 (9/6/2011 Mitchell Dep. 174:6-9).) Given the link between type_ids and the TypeIdsSection.java file, that citation constitutes sufficient notice to Google that other similarly named files are also relevant to this limitation—the StringIdsSection.java file for removing duplicate string_ids, the FieldIdsSection.java file for removing duplicate field_ids, and so on. All these sections are identified in the slides reproduced in the ICs.

The ICs provide further notice that the StringIdsSection.java and FieldIdsSection.java files are relevant. The ICs’ disclosure for “determining plurality of duplicated elements” provides an antecedent basis for “removing said duplicated elements . . . .” (Francis Decl. Ex. D, ’702 patent col.51 ll.2-11 (emphasis added).) The ICs quote from the DexFile.java file to show how the dx tool determines the duplicated constants. (Peters Decl. Ex. 2 at 4-9.) That file, in its toDex0 function, calls the “prepare” functions to create .dex file sections, including classDefs, methodIds, fieldIds, protoIds, typeIds, and stringIds. (Id. at 5-6.) In order to understand how the dx tool removes duplicated constants and obtains reduced class files as it prepares a .dex file, one would trace the called functions to the ClassDefsSection.java, StringsIdsSection.java, FieldIdsSection.java, and other similarly named files. Accordingly, the ICs provided ample notice to Google of which dx tool’s functionality meets the “removing” limitation of Claim 1.

The Report provides more description of the .dex file anatomy by citing to the ClassDefsSection.java file, because the ClassDefsSection “generally includes the Dalvik byte code associated with the input class files after the identified duplicates have been removed.” (Report ¶ 476; see also id. ¶¶ 478-479.) The Report also cites to the Section.java and

8

UniformItemSection.java files, simply because the ClassDefsSection.java file is a subclass of those two files and thus inherits some of their members and functions. (Id. ¶ 459.)

Moreover, the Report quotes from Android source code files to explain how the dx tool removes duplicated constants from class files in forming a single .dex file with a shared constant pool. The Report explains that the toDex0 function implemented in the DexFile.java file calls the “prepare” function for the sections of the class file. (Id. ¶¶ 458-59.) The Report explains the role of those called functions by tracing the calls to the StringIdsSection.java, FieldIdsSection.java, and other similarly named files, in which duplicated constants are removed. (Report ¶¶ 460, 461, 468.) The Report quotes from those files the source code for storing the determined constants in a TreeMap structure. (Id.) The Report explains that the TreeMap structure is designed to store a single copy of each constant, thereby necessarily removing any duplicate constants from each constant pool. (Id. ¶ 462.) Therefore, the Report further explains the Bornstein slides shown in the ICs by describing the accompanying Android source code.

The Report does not introduce a “new” infringement theory against the dx tool. Oracle has, all along, contended that the dx tool’s functionality for removing duplicated constants from multiple class files to create a shared constant pool and reduced class files in a single .dex file infringes the ’702 patent. Nothing about that theory has changed. Prof. Mitchell explained that in providing a narrative explanation of the infringement theories in his Report, he “ended up with . . . some different examples or following the call chain up and down a little bit to explain more fully. But it’s the same basic . . . infringement story, a reason why the system infringes as shown in the chart.” (Peters Decl. Ex. 3 (9/6/2011 Mitchell Dep. 177:18-178:2).) Therefore, the Report merely provides “additional information regarding the specific factual bases” for Oracle’s ICs by tracing through the identified functions. Sicurelli, 2005 U.S. Dist. LEXIS 42233, at *33.

Again, it is too late for Google to challenge Oracle’s ICs. In any event, Google’s own conduct shows it understood Oracle’s ’702 infringement theory from the ICs perfectly well. Based on the ICs, Google was able to serve Invalidity Contentions and respond to Oracle’s interrogatory seeking Google’s non-infringement position. (Peters Decl. Ex. 4 at 16-17.) In its interrogatory response, Google contended that the dx tool does not meet the “removing”

9

limitation because “there would be no intermediate step of removing duplicated elements from class files to obtain a plurality of reduced class files prior to forming a multi-class file.” (Id. at 16.) Prof. Parr, Google’s expert on non-infringement of the ’702 patent, also opined in his expert report that “there is no ‘remove’ step performed by the Android dx tool to create reduced class files.” (Peters Decl. Ex. 5 at 19.) Google would not have been able to assert this noninfringement position in its interrogatory response unless the ICs provided sufficient notice of Oracle’s infringement theories to Google. Also, that Google did not change its non-infringement position after reviewing the Report indicates that the Report tracks the infringement theories disclosed in the ICs. The Report explains those infringement theories by providing only additional explanation and evidence; it does not add new theories.

Accordingly, the Report is fully supported by Oracle’s ICs.

C. Response to Critique C: The Report on the Scope of the Accused Instrumentalities Is Supported by the ICs

Oracle’s ICs identify the following “Accused Instrumentalities” as infringing:

(i) “Android” or “the Android Platform”; (ii) Google devices running Android; and (iii) other mobile devices running Android. Representative examples of Google devices running Android include the Google Dev Phones, the Google Nexus One, and the Google Nexus S. Representative examples of other mobile devices running Android include HTC’s EVO 4G, HTC’s Droid Incredible, HTC’s G2, Motorola’s Droid, and Samsung’s Captivate.
(Francis Decl. Ex. F at 2.) Google complains that the Report includes three “additional” Android devices: LG Optimus, HTC Droid Incredible 2, and Motorola Atrix. However, all of those devices fall under the category of “other mobile devices running Android” and thus are within the scope of the ICs. In fact, Google does not dispute that the three Android devices are “mobile devices running Android.” The “other mobile devices” named in the foregoing section are specifically “representative examples,” not an exhaustive list.

Oracle’s contention is that all Android devices function in the same way with respect to the patented technology, and that contention was clearly made in the ICs. Google did not need to “guess” which Android devices are encompassed by Oracle’s ICs—they all are. To be sure, because Google gives away Android (and hence Oracle’s Java intellectual property) for free,

10

Android has been widely adopted. Oracle could not reasonably examine every Android device for direct proof that the manufacturer has deployed Android in an infringing way. Instead, Oracle will rely on a mix of direct and circumstantial evidence to prove its allegations. The record is replete with evidence that device manufacturers install the infringing elements of the Android platform on their Android devices. Publicly available examples of such evidence include the following:

  • Google’s Compatibility Definition Document (“CDD”), which specifies the requirements for a device to be Android-compatible, forbid device manufacturers from modifying aspects of Android that are copied from the Java platform: “[D]evice implementers MUST NOT make any prohibited modifications . . . to these package namespaces: java.*, javax.*, sun.*, android.*, com.android.*.” (Compatibility Definition Document for Android 2.2 at 8, available at http://source.android.com/compatibility/ android-2.2-cdd.pdf.) All CDDs impose the same restrictions.
  • Dan Morrill, who was formerly in charge of the CDDs, has stated: “Android is a chunk of software that you port to a device. For the most part, Android devices are running the same code.” (Dan Morrill, On Android Compatibility, available at: http://android-developers.blogspot.com/2010/ 05/on-android-compatibility.html (emphasis added).)
Despite overwhelming evidence that device manufacturers install Google’s infringing Android code as-is on their Android devices, Google continues to contend that it is not liable because its Android licensees might have made changes to the Android code before loading it onto their Android devices. To further investigate whether there was evidentiary support for Google’s non-infringement argument, Prof. Mitchell double-checked the Android code installed on LG Optimus, HTC Droid Incredible 2, and Motorola Atrix devices. Exactly as one would expect, he confirmed that these devices made no changes to the infringing elements. The Report references those Android devices as additional evidence that Android devices include the infringing elements as Google intended. Those devices are not “new” to this case. Google has been on notice since Oracle served the initial ICs in December 2010 that all Android devices are accused of infringing the patents-in-suit.

11

Google has no evidence to rebut Oracle’s contention that device manufacturers install the infringing elements of the Android platform on their Android devices. Google continues to represent that it does not know what source code is run on third-party Android devices. (See Mot. at 5-8; see also Peters Decl. Ex. 6 at 11 (Google’s Responses to Oracle’s Interrogatory No. 21) (“Google states that it has no direct, specific knowledge with regard to how third parties modify the accused Android source code and documentation.”).) Google’s position is disingenuous given its active role in ensuring that the devices are Android-compatible. Regardless, given its supposed lack of any relevant knowledge, Google cannot now challenge Oracle’s position that the ICs apply to all Android devices.

In its motion, Google again argues that Oracle’s ICs did not comply with the Patent Local Rules in identifying the scope of the Accused Instrumentalities. But this argument comes too late—Google has waived any claim that Oracle’s ICs were inadequate and cannot contest them now. See Fenner, 2010 U.S. Dist. LEXIS 17536, at *11-13 (“If Defendants were unclear as to the scope of the contentions, it was their responsibility to work with Plaintiff, informally or through motion practice, to clarify the issue.”).

Moreover, the ICs gave sufficient notice to Google as to the scope of Accused Instrumentalities. The ICs identify the Android elements that infringe each claim by referencing Android source code, presentations made by Android engineers, and other documentary evidence. From these, Google was on notice as to which components of Android devices it had to defend for some time. Moreover, because Google knew what Android devices were at issue, Google should not have had any difficulty in identifying the Accused Instrumentalities for the method claims and other claims that require physical components such as a computer processor or memory. As Oracle explained in its letter brief to this Court in February 2011, “[d]epending on whether the asserted claim is directed to a system, a method, or a computer software product, the accused instrumentalities are computers running Android or the Android development environment, the users of such computers (including application developers or end users), or the physical software medium itself (including Google’s servers).” (ECF No. 82 at 2.) Oracle’s ICs

12

also identified the categories of direct infringers, including manufacturers of Android products, application developers, service providers, and end users.

Although Google characterizes Oracle’s infringement theories disclosed in the ICs as “untenable,” this is not the appropriate time or vehicle to argue the merits of the case. Infringement contentions only need “to provide reasonable notice to the defendant why the plaintiff believes it has a ‘reasonable chance of proving infringement.’” Shared Memory Graphics, 2010 U.S. Dist. LEXIS 138868, at *10-11 (citation omitted). The ICs provided more than reasonable notice of the scope of Oracle’s infringement theories. At trial, Oracle will present evidence to show how these Accused Instrumentalities, including all Android-branded phones, infringe the asserted patent claims according to the infringement theories disclosed in the ICs.

IV. CONCLUSION

The ICs gave sufficient notice to Google of the Accused Instrumentalities and Oracle’s infringement theories. The Report is fully supported by the ICs. For the foregoing reasons, Oracle respectfully asks this Court to deny Google’s motion to strike portions of the Mitchell Patent Report.

Dated: September 15, 2011

MICHAEL A. JACOBS
MARC DAVID PETERS
DANIEL P. MUINO
MORRISON & FOERSTER LLP

By: /s/ Marc David Peters

Attorneys for Plaintiff
ORACLE AMERICA, INC.

13


436

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

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

ORACLE CORPORATION
DORIAN DALEY (Bar No. 129049)
[email]
DEBORAH K. MILLER (Bar No. 95527)
[email]
MATTHEW M. SARBORARIA (Bar No. 211600)
[email]
[address, phone, 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

DECLARATION OF MARC D. PETERS IN SUPPORT OF ORACLE AMERICA, INC.’S OPPOSITION TO GOOGLE
INC.’S MOTION TO STRIKE PORTIONS OF THE MITCHELL PATENT REPORT

Date: September 29, 2011
Time: 8:00 a.m.
Dept.: Courtroom 8, 19th Floor
Judge: Honorable William H. Alsup

I, Marc David Peters, declare as follows:

I am a partner at Morrison & Foerster LLP and am counsel of record to Plaintiff Oracle America, Inc. I have personal knowledge of the matters set forth herein and, if called to testify, could and would testify competently to the following.

  1. On February 9, 2011, I participated in a Court-directed meet-and-confer on Oracle’s initial Infringement Contentions, served December 2, 2010. We invited Google to pose any questions it wished if it had difficulty understanding Oracle’s Infringement Contentions. During the court hearing on February 9, 2011, my partner Michael Jacobs reported to the Court the parties’ agreement to engage better with each other in attempting to resolve discovery disputes. At no time afterward did Google pose any queries that correspond to the complaints it makes in its current motion, although its counsel did ask regarding other issues.
  2. Attached hereto as Exhibit 1 is a true and correct copy of relevant portions of Oracle’s Supplemental Infringement Contentions for the ’104 Patent, served April 1, 2011 (highlights added).
  3. Attached hereto as Exhibit 2 is a true and correct copy of relevant portions of Oracle’s Supplemental Infringement Contentions for the ’702 Patent, served April 1, 2011 (highlights added).
  4. Attached hereto as Exhibit 3 is a true and correct copy of relevant portions of the transcript of deposition of John C. Mitchell, Ph.D., taken on September 6, 2011 (highlights added). Protective Order designations have been withdrawn for the attached portions.
  5. Attached hereto as Exhibit 4 is a true and correct copy of relevant portions of Defendant Google Inc.’s Fourth Supplemental Responses to Plaintiff’s Interrogatories, Set One, No. 3 (highlights added).
  6. Attached hereto as Exhibit 5 is a true and correct copy of relevant portions of the Expert Report of Terence Parr, Ph.D. Regarding Non-Infringement of U.S. Patent No. 5,966,702 (highlights added). Protective Order designations have been withdrawn for the attached portions.
  7. 1

  8. Attached hereto as Exhibit 6 is a true and correct copy of relevant portions of Defendant Google Inc.’s Responses to Plaintiff’s Interrogatories, Set Four, No. 21 (highlights added).
I declare under penalty of perjury under the laws of the United States that to the best of my knowledge the foregoing is true and correct. Executed on September 15, 2011, in Palo Alto, California.

/s/ Marc David Peters

2

410(ExA):

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

GOOGLE’S MOTION TO STRIKE PORTIONS OF THE MITCHELL PATENT REPORT

CIV. NO. CV 10-03561-WHA

Exhibit A

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

______________________________

OPENING EXPERT REPORT OF JOHN C. MITCHELL
REGARDING PATENT INFRINGEMENT

SUBMITTED ON BEHALF OF PLAINTIFF
ORACLE AMERICA, INC.

191. Because it would take substantial effort and resources to make significant changes to core Android operating system functions that both outperformed the code that Google already provides and still conform to the CDD and pass the CTS, I would not expect any such changes to be made. To confirm, I reviewed source code for particular Android devices (the Nexus One, Nexus S, HTC Droid Incredible 2, LG Optimus, Samsung Captivate, and Motorola Atrix) that is made available by Android device manufacturers on their open source websites. Versions of source code files, discussed in this report with respect to my infringement analysis, from the OEM websites were compared to the "canonical" Google version from the Android git repository, and there were no changes to the OEM versions that would alter the infringement analysis of Google's canonical version. This supports my conclusion that Android-branded phones are running Google-authored software, at least with respect to the code that causes the infringement.

64

229. All of the analyses below concerning infringement are to be read together with the material in the claim chart of Exhibit A attached to Oracle's infringement contentions submitted to Google on April 1, 2011. I participated in the analysis and preparation of the Exhibit A chart. I agree with the conclusions of the chart and the evidence supporting those conclusions. While my report contains a narrative-style infringement analysis, this analysis is intended to accompany the additional information supplied in the charts that in some cases provides more details.

230. The infringement evidence illustrated below is exemplary and not exhaustive. The cited examples are taken from Android 2.2, 2.3, and Google's Android websites.3 My analysis applies to all versions of Android having similar or nearly identical code or documentation, including past and expected future releases. I understand that the publicly released versions of Android before version 2.2 operate as I describe below; I have not been given the opportunity to analyze versions of Android from 3.0 and beyond.

231. In my opinion, Google's Android literally infringes the asserted claims of the '104 patent.

232. The Android code cited below necessarily infringes when it runs because, for example, (1) "when a .dex files arrives on a device it will have symbolic references to methods and fields, but afterwards it might just be a simple, a simple integer vtable offset so that when, for invoking a method, instead of having to do say a string-based lookup, it can just simply index into a vtable" (Google I/O 2008 Video entitled "Dalvik Virtual Machine Internals," presented by Dan Bornstein (Google Android Project), available at http://developer.android.com/videos/ index.html#v=ptjedOZEXPM ("Dalvik Video")) and (2) "'constant pool' references" are "resolve[d]" "into pointers to VM structs" (e.g.,

81

dalvikvmooResolve.h). Moreover, much of the code cited below is executed not only as applications run, but every time a device running Android starts up.

233. For example, Google employee and Android developer Dan Bornstein all but admitted that Android infringes the '104 patent asserted claims when he stated "when a .dex files arrives on a device it will have symbolic references to methods and fields, but afterwards it might just be a simple, a simple integer vtable offset so that when, for invoking a method, instead of having to do say a string-based lookup, it can just simply index into a vtable." (Google I/O 2008 Video entitled "Dalvik Virtual Machine Internals," presented by Dan Bornstein (Google Android Project), available at http://developer.android.com/videos/ index.html#v=ptjedOZEXPM ("Dalvik Video").)

234. Google Android developers stated in Android code that Android resolves "symbolic references":

235. Google Android developers stated in Android code that Android "resolves" references:

236. The substance of the infringement evidence cited in Claim 11 applies to each asserted claim because the evidence is not limited to a particular form of accused infringement. Android infringes in at least two ways, which are both detailed below.

82

237. The preamble of claim 11 recites "An apparatus comprising." Devices that run Android or the Android SDK satisfy the preamble because any device that runs Android is an apparatus.

238. Limitation [11-a] of claim 11 recites "a memory containing intermediate form object code constituted by a set of instructions, certain of said instructions containing one or more symbolic references."

239. As demonstrated by multiple sources of evidence produced by Google concerning Android, a device that runs Android or the Android SDK satisfies this limitation because it has a memory containing intermediate form object code constituted by a set of instructions.

240. Google invited Android developers to program applications in Java. Google's own Android talks and documentation explain that the Java source code must first be compiled into Java bytecode, which in turn gets run through Google's Android dx tool to translate the Java bytecode into Dalvik bytecode (called .dex format where .dex stands for Dalvik Executable). Android's virtual machine called the Dalvik virtual machine optimizes the .dex format bytecode into optimized .dex bytecode (referred to as .odex).

241. The Dalvik bytecode contains intermediate object code constituted by a set of instructions. This is because Java source code constitutes a set of instructions. When the Java source code is compiled, the resulting Java bytecode contains intermediate object code constituted by a set of instructions that contain symbolic references. So, too, does a .dex file, which is just a translation of the Java bytecode albeit representing instructions for the Dalvik virtual machine instruction set rather than the Java virtual machine instruction set and as such also contains intermediate object code constituted by a set of instructions that contain symbolic references.

242. When the Dalvik bytecode is stored on, saved on, or loaded onto a device, it is contained in memory.

243. This is documented in Google's Android website, e.g.:

83

84

244. Google's Dalvik and .dex creator Dan Bornstein has also made statements demonstrating Android's satisfaction of claim limitation 11-a, e.g.:

85

86

87

88

89

90

91

245. Limitation [11-b] of claim 11 recites "and a processor configured to execute said instructions containing one or more symbolic references by determining a numerical reference corresponding to said symbolic reference, storing said numerical references, and obtaining data in accordance to said numerical references."

246. An Android device is configured to run the Dalvik virtual machine upon startup. (In fact, an Android device will run multiple instances of the Dalvik virtual machine.) The code implementing the Dalvik virtual machine configures the hardware processor on the Android device to execute the .dex formatted bytecode or the .odex formatted bytecode as discussed above. As such, Android meets the limitation of "a processor configured to execute said instructions containing one or more symbolic references."

247. The Android platform contains source code for resolving symbolic references, storing the resulting numeric references, and using the stored numeric references to obtain data. Both the dexopt component and the Dalvik bytecode interpreter resolve symbolic references and

92

store the resulting numeric references. The bytecode interpreter uses stored numeric references to obtain data.

248. The '104 patent is infringed because Android's dexopt optimizeMethod looks at every instruction in a method and tries to resolve symbolic references and determines, stores, or replaces symbolic references with corresponding numeric reference (i.e. Android quickens the instructions where Android can). (See 5/4/2011 McFadden Dep. 148:1-5, 153:17-154:17.) For the purpose of illustrating infringement by example, I focus on the OP_IGET (word-sized field fetch) instruction, but Android code handles other sizes of field fetches, field store, static field fetch and store, and various kinds of invocation.

249. The method optimizeMethod excerpted below "[o]ptimize[s] instructions in a method" and "does a single pass through the code, examining each instruction" as the Android developer comments indicate.

250. To be clear, Android Optimize.c line 196 identifies integer field fetch instructions in a switch statement and Android Optimize.c line 201 shows a decision to change the integer field fetch instruction to the corresponding quick instruction. In this process, a symbolic reference is resolved to a numerical reference. Android Optimize.c line 235 shows how instruction is changed by calling rewriteInstField. (The rest of the method handles integer field puts, static field gets and puts, and invoke instructions.)

93

94

95

251. The Android developers explain rewriteInstField, called in the code above, as follows:

96

252. Android Optimize.c line 643 resolves the field index in the constant pool to (among other things) a byte offset of the field in the object. Android Optimize.c lines 662-663 changes the opcode to the desired quick opcode, and the argument to the quick bytecode to the byte offset of the field.

253. dvmOptResolveInstField can resolve a field. It stores data about the resolved field (including the byte offset of the field) in a table of resolved fields, so the next time it is asked to resolve this field, it can look up the resolved information in the table. (Along the way, it calls dvmOptResolveClass which does the same form of determining, storing, and replacing for classes.)

97

254. In the code above, the first time the field has to be resolved, the test at Android Optimize.c line 484 fails and the field has to be resolved. Android Optimize.c line 493 resolves the class, possibly by finding it in the table of resolved classes, and then finds the field at Android Optimize.c line 501. Android Optimize.c line 524 saves the result of the resolution so the next time resolving this field will be faster.

255. Android’s dvmDexSetResolvedField and dvmDexGetResolvedField use a table indexed by the field index in the constant pool to write and read the resolved field information.

98

256. The calls to updateCode from Android Optimize.c lines 662 and 663 are fairly straightforward. One wrinkle is whether the page is read-write or read-only. If the page is read-only, the Android code changes the page to read-write for the write itself.

99

257. The Android virtual machine can execute non-quickened field read and write instructions. (For example, if dexopt did not rewrite these instructions.) For example, the x86 assembler interpreter for the OP_IGET instruction is:

258. Android InterpAsm-x86.S line 1984 tests the slot in the table built by dvmOptResolveInstField; if it's not set, Android branches to .LOP_IGET_resolve to resolve the field index:

259. dvmResolveInstField stores the result of symbolic reference resolution as detailed later after the explanation of how the bytecode interpreter executes quickened bytecodes. As

100

shown in line 6995, the interpreter jumps to .LOP_IGET_finish after the symbolic reference is resolved to a numeric reference.

260. Android InterpAsm-x86.S line 7006 extracts the field offset from the fieldInst structure (in contrast to the value that would have been written as the operand to the quick instruction at vm/analysis/Optimize.c#l663), and Android InterpAsm-x86.S line 7010 fetches the field of the object. Note that there are (at least) two paths to .LOP_IGET_finish: (1) if the field referenced as the operand to the non-quick instruction has been resolved by dexopt (1990), and (2) if the resolution has to be done at during interpretation.

261. If the OP_IGET had been rewritten by dexopt, then the Android execution sequence ends up in the OP_IGET_QUICK branch of the interpreter:

101

262. Android InterpAsm-x86.S line 5973 gets the offset of the field from the operand to the OP_IGET_QUICK instruction, and Android InterpAsm-x86.S line 5973 uses it to read the field from the object. E.g., "movl (%ecx,%eax,1),%eax is the actual field fetch."

263. Therefore, Android meets limitation [11-b] of claim 11 because symbolic references are resolved and stored in dexopt and used to access data in the bytecode interpreter.

264. There is a second way in which Android meets limitation [11-b] of claim 11. The Dalvik bytecode interpreter can also resolve symbolic references and store the resulting numeric references (again for later use by the bytecode interpreter). This functionality applies to bytecodes that have not been rewritten by dexopt. One case where dexopt appears inapplicable is that code in the class libraries that are preloaded by zygote (see the analysis of the '720 patent) may contain methods that receive objects as part of a method call. If an object passed to the class library comes from a Java class that is defined in the application, then the preloading process does not generally know the layout of the objects of this class. Therefore, it is logical for symbolic reference resolution to fall to the bytecode interpreter. A second example illustrating the benefit of symbolic resolution by the bytecode interpreter arises with applications that are packaged as more than one .dex file, with portions of the application loaded using runtime class loading. Further explanation of this scenario appears in a blog posting called Custom Class Loading in Dalvik (see http://m.mobilitybeat.com/site/ android-developers-blog/2/;
http://android-developers.blogspot.com/ 2011/07/custom-class-loading-in-dalvik.html).

265. Android's Dalvik virtual machine looks at instructions and resolves symbolic references: Resolve.c functions determine corresponding numerical references, stores those numerical references, and obtain data corresponding to the resolved numerical references. (See, e.g., 5/4/2011 McFadden Dep. 150:7-151:2.) The functions include:

dvmResolveClass
dvmResolveMethod
dvmResolveInterfaceMethod
dvmResolveInstField
dvmResolveStaticField
dvmResolveString

102

266. As comments from Android developers explain, the functions available in Resolve.c literally serve to resolve classes, methods, fields, and strings:

267. My best understanding is that "VM spec (v2 5.5)" refers to Sun Microsystems's (now Oracle's) Java virtual machine specification. Of note, Sun Microsystems's Java Virtual Machine Specification, Edition 2, Section 5.5, details:

103

268. This means that the virtual machine cannot initialize a class until it has been resolved. The Java virtual machine abides by this. The evidence indicates that the Dalvik virtual machine is designed to do the same.

269. The function "dvmResolveClass" determines or resolves symbolic references (class names) to numerical references (class indexes, "classIdx") and obtains data in accordance to the numerical reference (the class, "resClass"). (See also 5/4/2011 McFadden Dep. 144:3-145:9.) As the Android developers explain, "We cache a copy of the lookup in the DexFile's "resolved class" table, so future references to "classIdx" are faster." This refers to the method performed by Android that infringes the '104 asserted claims.

104

105

270. As shown in the excerpted code, the function dvmResolveClass invokes dvmDexGotResolvedClass at line 74 in Resolve.c. The function dvmDexGetResolvedClass is defined in DvmDex.h and serves to return the requested ClassObject if it has been "resolved":

271. As shown in the Resolve.c excerpted code, the function invokes at line 154 in Resolve.c. (See also 5/4/2011 McFadden Dep. 144:20-145:9.) The DvmDex.h file also has which serves to store the resolved symbolic reference after the class name gets resolved for the first time or needs to get resolved again for some reason. (See also id. at 146:12-147:5)

106

272. The function "dvmResolveMethod" determines or resolves symbolic references (method names) to numerical references ("methodRef" or "methodIdx") and obtains data in accordance to the numerical reference (the method, "resMethod"):

107

273. As shown in the Resolve.c excerpted code, the function dvmResolveMethod invokes dexGetMethodId at line 188 in Resolve.c. The function dexGetMethodId is defined in DexFile.h and

108

serves to return the numerical reference (MethodID with specified index) (shown below), which in turn is used to resolve the class in which the method being resolved belongs as shown in line Resolve.c's 188-190 above:

274. Then, dvmResolveMethod invokes one of the following three functions in Resolve.c at lines 215-219 to resolve the method:

275. The three functions are shown below, and each serves to resolve a method name to the resolved method:

109

276. In turn, findMethodInListByProto serves to find and return the method being resolved as indicated by Android developer comments and the source code shown below:

110

277. As shown in the Resolve.c excerpted code, the function dvmResolveMethod invokes at line 273 in Resolve.c. The DvmDex.h file contains the source code for dvmDexSetResolvedMethod the dvmDexSetResolvedMethod function, which serves to store the resolved symbolic reference when the method name gets resolved for the first time:

278. Likewise, the function "dvmResolveInterfaceMethod" determines or resolves symbolic references (interface method names) to numerical references ("pMethodId") and obtains data in accordance to the numerical reference (the method, "resMethod"):

111

112

279. As shown in the Resolve.c excerpted code, the function invokes at line 294. The function is defined in DexFile.h and serves to return the numerical reference (MethodID with specified index) (shown below), which in turn is used to resolve the class in which the method being resolved belongs as shown in line Resolve.c’s lines 294-296 above:

113

281. In turn, findMethodInListByProto is invoked and serves to find and return the method being resolved as indicated by Android developer comments and the source code shown below:

114

115

284. As shown in the excerpted code, the function invokes at line 408 in Resolve.c. The function is defined in DexFile.h and dexGetFieldId serves to return the numerical reference (FieldId with the specified index) (shown below), which

116

in turn is used to resolve the class in which the instance field being resolved belongs as shown in line Resolve.c’s 408-413 above:

117

287. As shown in the Resolve.c excerpted code, the function invokes at line 446. The DvmDex.h file contains which serves to store the resolved symbolic reference, and which gets called by Resolve.c’s (as shown at line 446) when the instance field gets resolved for the first time:

118

288. Likewise, the function "dvmResolveStaticField" determines or resolves symbolic references (static field) to numerical references ("pFieldId") and obtains data in accordance to the numerical reference (the method, "resField"):

119

120

121

dvmDexSetResolvedField which serves to store the resolved symbolic reference, and which gets called by Resolve.c’s (as shown at line 507) when the field gets resolved for the first time:

122

123

297. The Android virtual machine invokes the functions illustrated above when executing instructions. The following documentation provides context for the code examples discussed below:

124

298. For example, the x86 assembler interpreter has the following code showing invocation of the Resolve.c functions discussed above:

125

126

299. For another example, another x86 assembler interpreter has the following code:

300. For another example, the main interpreter entry point and support functions has the following code:

127

301. For the reasons described above, Android literally satisfies the limitations of Claim 11 and in at least two ways which I have dubbed the "dexopt" (Optimize.c) and "Resolve.c" modes of literal infringement, respectively.

302. Android meets the limitations of claim 12 in the same ways Android literally infringes claim 11 of the '104 patent.

303. Claim 12 recites "A computer-readable medium containing instructions for controlling a data processing system to perform a method for interpreting intermediate form object code comprised of instructions, certain of said instructions containing one or more symbolic references, said method comprising the steps of....", where the method that follows comprises the steps of interpreting and resolving. Android devices are data processing systems that include computer-readable mediums such as memories that contain the Android software (including the Dalvik virtual machine), which causes the system to perform the method set forth in claim 12. For the reasons described above and here, Android will perform the steps and substeps method set forth in claim 12 when in operation, and so any computer-readable medium storing a copy of Android will infringe claim 12. Such computer-readable mediums may be found in devices that that store, distribute, or run Android or the Android SDK, including websites, servers, host computers, and mobile devices.

304. Android infringes limitation [12-a] of claim 12, which recites "interpreting said instructions in accordance with a program execution control." The Dalvik virtual machine (which runs the routines in Resolve.c to resolve symbolic references) interprets intermediate form object code in accordance with a program execution control (for example, the Android operating system can switch between multiple active Dalvik VM instances).

305. Dexopt is also part of the bytecode interpretation process because it loads classes into the VM and runs over their bytecodes for verification and optimization purposes:

128

306. I have covered the reasons Android performs the resolving step, determining substep, and storing substep in my discussion of Android's infringement of claim 11.

307. Android literally infringes claim 15 in the same way that Android literally infringes claim 11 of the '104 patent.

308. Claim 15 is a method claim that depends on claim 13, whose preamble recites "A computer-implemented method for executing instructions, certain of said instructions containing one or more symbolic references, said method comprising the steps of." To the extent the preamble limits the scope of the claim, it is met by Android. Android's Dalvik VM will execute

129

instructions, some of which contain symbolic references, when it runs. I have covered the reasons Android performs the resolving step, determining substep, and storing substep of claim 13 in my discussion of Android's infringement of claim 11.

309. Next, claim 15 also recites "The method of claim [13], wherein said step of resolving said symbolic reference further comprises the substep of executing said instruction containing said symbolic reference using the stored numerical reference." The source code excerpted below is one example showing that virtual machine instructions containing the resolved symbolic references get executed, thereby showing that Android literally infringes claim 15, e.g.:

130

310. Android literally infringes claim 17 in the same ways Android literally infringes claim 11 of the '104 patent. Claim 17 is a method claim. The preamble of claim 17 recites "In a computer system comprising a program, a method for executing said program comprising the steps of." To the extent the preamble limits the scope of the claim, it is met by Android. Android executes programs in a computer system.

311. My discussion and analysis of the resolving step above apply equally to the converting step of claim 17. I have covered the resolving substep, storing substep, and obtaining substep in my discussion of Android's infringement of claims 11 and 15.

312. Android literally infringes claim 22 in the same ways Android literally infringes claim 11 of the '104 patent. Once a .dex file (containing intermediate form object code with symbolic data references in certain instructions) is loaded (received) onto an Android device, it is executed without being recompiled. Even versions of Android that include a JIT do not immediately compile code, but instead allow the code to be interpreted until a profiler determines that a portion of the code should be compiled.

313. Android literally infringes claim 27 in the same ways Android literally infringes claims 11, 15, and 17 of the '104 patent. To the extent the preamble limits the scope of the claim, it is met by Android. Android includes computer-implemented methods for performing the steps described in the claim.

314. Android literally infringes claim 29 in the same ways Android literally infringes claims 11, 15, and 17 of the '104 patent. To the extent the preamble limits the scope of the claim, it is met by Android. Storage media that contain Android source or binary code, which include Android devices, system images, the Android git repository server, and the Android SDK are computer program products containing instructions for causing a computer to perform the steps described in the claim.

131

315. Android literally infringes claim 38 in the same ways Android literally infringes claims 11, 15, and 17 of the '104 patent. To the extent the preamble limits the scope of the claim, it is met by Android. Storage media that contain Android source or binary code, which include Android devices, system images, the Android git repository server, and the Android SDK are computer program products containing instructions for causing a computer to perform the steps described in the claim.

316. Android literally infringes claim 39 in the same ways Android literally infringes claims 11, 15, and 17 of the '104 patent. To the extent the preamble limits the scope of the claim, it is met by Android. Android includes computer-implemented methods for performing the steps described in the claim.

317. Android literally infringes claim 40 in the same ways Android literally infringes claims 11, 15, and 17 of the '104 patent. To the extent the preamble limits the scope of the claim, it is met by Android. An Android device includes memory that stores dex and odex files containing intermediate form object code. The Android device runs code implementing the Dalvik virtual machine, thereby configuring the hardware processor on the Android device to execute the .dex formatted bytecode or the .odex formatted bytecode as discussed above.

318. Android literally infringes claim 41 in the same ways Android literally infringes claims 11, 15, and 17 of the '104 patent. To the extent the preamble limits the scope of the claim, it is met by Android. Storage media that contain Android source or binary code, which include Android devices, system images, the Android git repository server, and the Android SDK are computer program products containing instructions for causing a computer to perform the steps described in the claim.

132

443. The smaller size of the m-class file (relative to the plurality of class files before processing) results in the classes taking up less space on servers or storage devices, less network or file transfer time to read, less memory when loaded, and faster execution (in part, because shared constants are resolved at most once).

444. Multi-class files further consolidate the loading of required classes instead of loading the classes one by one. Using allocation information, only one dynamic memory allocation is needed instead of multiple allocation operations. This results in less fragmentation, less time spent in the allocator, and less waste of memory space. Because the class files are consolidated in a single multi-class file, only a single transaction is typically needed to perform a network or file system search, to set up a transfer session (e.g., HTTP), and to transfer the entire set of classes. This minimizes pauses in the execution that can result from such transactions and provides for deterministic execution, with no pauses for class loading during a program run. Also, once the multi-class file is loaded and parsed, there is no need for the computer executing the program to remain connected to the source of the classes.

445. I have illustrated these concepts in the animations that were shown or submitted to the Court for the April 6, 2011 Technology Tutorial. If called upon to testify, I intend to use these animations to explain the technology and state of the art involved in the '702 patent.

C. Detailed Infringement Analysis

446. I have compared Google's Android to the elements recited in claims 1, 6, 7, 12, 13, 15, and 16 of the '702 patent.

447. All of the analysis below concerning infringement should be read together with the material in the claim chart of Exhibit C attached to Oracle's infringement contentions submitted to Google on April 1, 2011. I participated in the analysis and preparation of the Exhibit C chart. I agree with the conclusions of those charts and the evidence supporting those conclusions. While my report contains a narrative-style infringement analysis, this analysis is intended to accompany the additional information supplied in the charts that in some cases provides more details.

196

448. The infringement evidence illustrated below is exemplary and not exhaustive. The cited examples are largely taken from Android 2.2, 2.3, and Google's Android websites. My analysis applies to all versions of Android having similar or nearly identical code or documentation, including past and expected future releases. I understand that the publicly released versions of Android before version 2.2 operate as I describe below; I have not been given the opportunity to analyze versions of Android from 3.0 and beyond.

449. In my opinion, Google's Android literally infringes the asserted claims of the '702 patent. As described in various sources from Google, and found directly in the Android code, Google's Android dx tool pre-processes class files according to claim 1, the process including determining a plurality of duplicated elements in a plurality of class files, forming a shared table comprising said plurality of duplicated elements, removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files, and forming a multi-class file comprising said plurality of reduced class files and said shared table. The dx tool is distributed as part of the Android SDK. The users of the dx tool include Google and device manufacturers, who use it to build Android system images and applications, as well as application developers, who use the Android SDK to develop applications by converting compiled .class files to Android .dex files. There is no good reason to think that anyone alters the dx tool so that it does not practice the patented method and many reasons to think that nobody alters the dx tool in any significant way.

450. Because the dx tool comprises computer readable program code for pre-processing class files, computer-usable media that contain the dx code make up computer program products that meet all the requirements of claim 7 and its asserted dependent claims. These products include websites, servers, and computers that host the Android SDK for download and computers that have downloaded the Android SDK from Google. The products also include Google's own internal versions of the dx tool that it uses for system builds and application development. Computers that have the dx tool installed, whether as part of the Android SDK or separately, include a processor and a memory. Before the dx tool is run to

197

create a .dex file, one or more class files are created by running a Java compiler such as that found in the JDK, which Google urges Android SDK users to download. (See "Installing the SDK," http://developer.android.com/sdk/ installing.html.) When the dx tool runs, is a process configured to form a multi-class file as described below. For these reasons, computers that have the dx tool installed will be reasonably capable of meeting all the requirements of claim 13 and its asserted dependent claims, and will in fact meet all those requirements when the dx tool is used for its intended purpose of converting .class files to a .dex file.

451. In reviewing the Android source code, I have summarized the process the dx tool follows to form .dex files from .class files. The process generally starts with the source code file Main.java in the com.android.dx.command.dexer package (path /src/com/android/dx/command/ dexer/Main.java), which contains code to process each input Java class in turn. Specifically, the run method called by main calls processAllFiles, which then calls processOne on each filename (line 220).

198

452. The processOne method processFileBytes which leads to method processClass when class files are processed. For each class, processClass creates a ClassDefItem created as the internal representation of the class (see lines 336-337) and puts the resulting information into an object representing the .dex “output file in-progress” (line 338).

453. Each ClassDefItem, created by method CfTranslator.translate defined in source code file, includes the fields, methods and annotations of the class. Each method includes the Dalvik byte code for the method, which is translated from the original Java byte code. In more

199

detail, file CfTranslator.java, at path dx/src/com/ android/dx/dex/cf/CfTranslator.java, defines a static method that turns a bytecode array containing Java classfiles into ClassDefItem instances (comment lines 58-59).

454. At line 82 in CfTranslator.java there is a method translate(), which turns a byte array containing a Java classfile into a corresponding ClassDefItem.

455. The ClassDefItem contains all of the fields, methods, annotations, and constants of the class. At this stage, each class is processed individually, a ClassDefItem being separately created for each input Java class without regard for potential duplication of constant pool entries.

456. Once the ClassDefItem is completely formed, it is added to an object of class DexFile by calling DexFile.add(). This call occurs in line 338 of Main.java.

200

457. The source code for DexFile appears in file dx/src/com/ android/dx/dex/file/DexFile.java. DexFile has a field classDefs (line 120) of class ClassDefsSection that accumulates the ClassDefItem objects (see lines 142-143).

458. After all of the input classes have been processed as described above there is a pass that causes all of the constant pool entries in the ClassDefItem objects to be interned. It is at this stage that the TreeMaps for the constant pool sections are populated and the duplicate removal takes place. For instance, at line 434 of x/src/com/android/ dx/command/dexer/Main.java there is a call to outputDex.toDex(). The implementation of toDex is at 196 of DexFile; method toDex() calls toDex0(), which is at line 476 of the same file.

201

202

459. The implementation of toDex0() calls a method called prepare() for the sections of the class file, e.g., lines 484-490 of Dexfile.java above. Considering classDefs.prepare(), the classDefs object is an instance of the ClassDefsSection class (e.g., line 120 of Dexfile). The class ClassDefsSection is a subclass of UniformItemSection, as shown in ClassDefsSection.java. UniformItemSection is defined in UniformItemSection.java as subclass of Section. The prepare() method is defined by Section in line 212 of dx/src/com/android/dx/dex/file/ Section.java. The prepare method calls another method prepare0(), which is abstract in Section, and is implemented at line 70 of dx/src/com/ android/dx/dex/file/ UniformItemSection.java. Method prepare0 iterates through each item in the ClassDefsSection calling a method called addContents() on each item.

460. Each kind of item in the class (e.g., method, field, annotation) is represented by a different class, all of which extend the base class Item. For example, a field is represented by an instance of the class EncodedField, found in dx/src/com/android/dx/dex/file/EncodedField.java. The addContents() method of this class is found in line 99 of that file. The addContents method is passed a reference to the DexFile so that it can fetch the FieldIdsSection from the file, and intern the constant for the field by calling the intern() method on FieldIdsSection.

203

461. The FieldIdsSection represents the aggregated FieldId constant pool entries for the whole .dex file (i.e. for all of the classes that are being included into the .dex file). The intern() method of class FieldIdsSection, for example, is defined in FieldIdsSection.java at lines 92-113. The intern() method calls FieldIds.put. As shown at the top of that file, e.g., line 45, FieldIds is an instance of class TreeMap. Thus, intern() uses a TreeMap, explained below, to hold the interned field constants. This is the step at which removal of duplicate constants is performed. The same process applies for methods, strings and types, which are represented in the ClassDefItem by other subclasses of Item.

204

462. TreeMap is part of a java collections framework. Therefore, when the Android SDK is built from source code this portion of the system is based on code provided by the JDK. Documentation for Java 2 Platform SE 5.0 is available at https://download.oracle.com/ javase/1.5.0/docs/api/java/util/ TreeMap.html. Java Class TreeMap extends the java.util.AbstractMap. Note that for any given key, a TreeMap stores at most one mapping for that key, as explained in the sentence “If the map previously contained a mapping for this key, the old value is replaced.”

463. With regard to specific claim elements, the preamble of claim 1 recites a “method of pre-processing class files.” The Android dx tool performs a method of pre-

205

processing .class files into a Dalvik executable format (.dex) file. For example, the dx tool is described as follows:

464. The pre-processing of class files performed by the dx tool into a .dex file that can be interpreted by the Dalvik Virtual Machine (Dalvik VM) is further explained in the Dalvik VM video presentation and related presentation from Google I/O 2008, dated 5/29/2008. (See Google I/O 2008 Video entitled "Dalvik Virtual Machine Internals," presented by Dan Bornstein, available at http://developer.android.com/ videos/index.html#v=ptjedOZEXPM ("Dalvik Video"), at 5:4510:45; see also Google I/O 2008 Presentation entitled "Dalvik Virtual Machine Internals" at Slides 11-22, presented by Dan Bornstein, available at http://sites.google.com/site/ io/dalvik-vm-internals/ 2008-05-29-Presentation-Of-Dalvik-VM- Internals.pdf?attredirects=0 ("Dalvik Presentation").)

465. Further, the Android source code performs preprocessing of class files, which can be found, for example, in the following packages, which are operable to preprocess class files:

"Classes for translating Java classfiles into Dalvik classes.
PACKAGES USED:
· com.android.dx.cf.code
· com.android.dx.cf.direct
· com.android.dx.cf.iface
· com.android.dx.dex.code
· com.android.dx.dex.file
· com.android.dx.rop.code
· com.android.dx.rop.cst
· com.android.dx.util"
dalvikdxsrccomandroiddxdexcfpackage.html.

206

466. The first element of claim 1, recites "determining a plurality of duplicated elements in a plurality of class files." The Android dx tool determines a plurality of duplicated elements in a plurality of class files as clearly illustrated and explained in the Dalvik Video at 7:50-8:45 and Dalvik Presentation, Slides 18-19. In particular, the Dalvik Presentation shows the determination of a plurality of duplicated elements (e.g., class signatures and string names) in a plurality of class files are determined:

207

467. In the Android source code, portions of the above features can be found in the dx.rop.type packages and dx.util package, as follows:

"Interfaces and implementation of things related to the constant pool.
PACKAGES USED:
* com.android.dx.rop.type
* com.android.dx.util"
dalvik/dx/src/com/android/dx/ rop/cst/package.html.

Additionally, the DexFile.java code indicates:

208

209

210

468. With reference to the discussion of how the dx tool uses TreeMap and by way of further explanation, the dx tool determines the duplicated elements (such as strings, field_ids, method_ids, and so forth) in a plurality of class files when it stores them in a TreeMap object, which determines whether the element is a duplicate of one already stored in the TreeMap. The TreeMap will not store more than one copy of a duplicated element. By way of example, the StringIdsSection.java code stores all the strings from the class files into a TreeMap object called “strings,” thereby determining the duplicate strings among the class files:

211

469. The second element of claim 1, recites "forming a shared table comprising said plurality of duplicated elements." The Android dx tool forms a shared table of the duplicated elements from the plurality of class files being preprocessed, in the manner discussed above and again here. This process is explained in the Dalvik Video at 7:209:25 and Dalvik Presentation, slides 15-20, where the recited shared table includes, e.g., one or more of the "string_ids constant pool," "type_ids constant pool," "proto_ids constant pool," "field_ids constant pool," and "method_ids constant pool."

470. The Dalvik Presentation shows the elements of the class files combining into a shared constant pool (shared tables) in the .dex file.

471. In the illustration above, each of "string_ids," "type_ids" and "method_ids" are examples of the shared tables (or, equivalently, a collective shared table). (See also 5/16/2011 Bornstein Dep. 91:6-21.) In addition, the discussion of the "Shared Constant Pool" in the Dalvik Video explains that the duplicated elements in the class files are consolidated into the shared constant pool (shared table) of the .dex file. (See Dalvik Presentation, Slides 15-21.) For example, slide 19 of the Dalvik Presentation shows the separate class files having duplicated elements.

212

472. Next, slide 20 of the Dalvik Presentation shows a representation of the class files after being processed into a single .dex file, with the duplicate elements removed; the elements are then stored in a shared constant pool (shared table):

213

The processes described above and recited by claim 1 can also be found directly in the Android source code. For example, they are described in:

"Interfaces and implementation of things related to the constant pool.
PACKAGES USED:
* com.android.dx.rop.type
* com.android.dx.util"
dalvik/dx/src/com/android/dx/rop/cst/package.html.

473. In the source code, the dx tool's execution begins at dx/src/com/android/dx/command/dexer/Main.java

(http://android.git.kernel.org/?p=platform/ dalvik.git;a=blob;f=dx/src/com/android/dx/command/ dexer/Main.java). Android developers explain this code as "Main class for the class file translator," where I understand "class file translator" to refer to the dx tool. Through Main.java, the dx tool each input Java class is processed in turn

474. As described above, for each input Java class, the class file is processed and a ClassDefItem created as the internal representation of the class. The ClassDefItem includes all fields, methods and annotations of the class. Each method includes the Dalvik byte code for the

214

method, which is translated from the original Java byte code. When the ClassDefItem is completely formed, it is added to an object of class DexFile by calling DexFile.add(). DexFile has an instance variable of class ClassDefsSection that accumulates the ClassDefItem objects. ClassDefsSection checks that there are no duplicate class names, but does no other processing of the ClassDefItem objects at the time when they are added. After all of the input classes have been processed as above there is a pass that causes all of the constant pool entries in the ClassDefItem objects to be interned to a shared table. It is at this stage that the TreeMaps for the constant pool sections are populated and the duplicate removal takes place, as described above

475. Each of the TreeMaps used to store the elements for the "string_ids constant pool," "type_ids constant pool," "proto_ids constant pool," "field_ids constant pool," and "method_ids constant pool" are a shared table comprising the duplicated elements and become the shared tables comprising the duplicated elements that are ultimately stored in the .dex file, as recited in the claim language.

476. The third element of claim 1, recites "removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files." The Android dx tool removes the duplicated elements from the plurality of class files (e.g., as part of the process of forming the .dex file multiple copies of the duplicated elements are not added to the tables that will be used to form the .dex file) and obtains a plurality of reduced class files in the form of the ClassDefSection (the ClassDefSection including a subset of the code and data contained in the class files) in the manner discussed above and again here. In particular, and as described above in the Android code, as class files are processed to form a .dex file, TreeMap is used to identify and remove duplicate elements from ClassDefSection (which generally includes the Dalvik byte code associated with the input class files after the identified duplicates have been removed). Note that removing or interning of the duplicated elements happens at the same time as forming the shared table. This process, and contents of the reduced class file, is clearly explained and illustrated in the Dalvik Video at 7:209:25 and Dalvik Presentation, Slides 15-20. The Dalvik Presentation shows the class files combining into a shared constant pool (shared table) in the .dex

215

file, whereby duplicated elements are removed from the class files when using a subset of the code and data contained in the class files, i.e., the reduced class files, to form the .dex file.

477. The original class files are combined into a single .dex file, which includes a plurality of reduced class files (i.e., a subset of code and data of the class files, with duplicates removed). This is also illustrated in slide 11 of the Dalvik presentation, which shows the anatomy of a .dex file:

216

478. The information in the ClassDefsSection and the data as shown in the slide form the reduced class files. Consider again the .class file format:

479. A .dex file's class_defs section contains information for each class, including the class (this class 307), access flags (306), superclass (308), an index to interface information (310), the source file name, and so on, as can be seen in the ClassDefItem.writeTo method. The .dex file's wordData, typeLists, stringData, byteData, classData sections also contain information for each class in a similar fashion. This is the information that remains after the constant pool

217

information, which contains one or more duplicated elements, have been removed and stored separately in the shared tables. Put another way, a .dex file comprises stringIds, typeIds, protoIds, fieldIds, methodIds, classDefs, wordData, typeLists, stringData, byteData, and classData sections. The information making up these sections come from the set of class files processed by the dx tool. The stringIds, typeIds, protoIds, fieldIds, methodIds sections are shared tables containing nonduplicated constant pool elements from the class files. The classDefs, wordData, typeLists, stringData, byteData, classData contain remaining information from the original class files (including Dalvik bytecode translated from Java bytecode).

480. The fourth element of claim 1, recites "forming a multi-class file comprising said plurality of reduced class files and said shared table." As explained above, the Android dx tool forms a multi-class file -- the .dex file -- comprising the reduced class files (e.g., the classDefs section mentioned above, which contains a class definition for each class file processed by dx) and a shared constant pool (shared table) (e.g., "string_ids constant pool," "type_ids constant pool," "proto_ids constant pool," "field_ids constant pool," and "method_ids constant pool.") from which duplicated elements have been removed. This process is explained in the Dalvik Video at 7:209:25 and Dalvik Presentation, Slides 11 and 15-20. The reduced class files include a subset of the code and data of the original class files, e.g., "class_defs" and "data" illustrated in slide 11 and the "other data" illustrated in slide 15, and the recited shared table includes, e.g., one or more of the "string_ids constant pool," "type_ids constant pool," "proto_ids constant pool," "field_ids constant pool," and "method_ids constant pool."

481. The Dalvik Presentation shows the original class files being combined into a .dex file (multi-class file) comprising the plurality of reduced class files and the shared constant pool (shared table):

218

XIII. CONCLUSION

767. For the foregoing reasons, it is my opinion that Android infringes:

  • Claims 11, 12, 15, 17, 22, 27, 29, 38, 39, 40, and 41 of United States Patent No. RE38,104;

  • Claims 1, 2, 3, and 8 of United States Patent No. 6,910,205;

  • Claims 1, 6, 7, 12, 13, 15, and 16 of United States Patent No. 5,966,702;

  • Claims 1, 4, 8, 12, 14, and 20 of United States Patent No. 6,061,520;

  • Claims 1, 4, 6, 10, 13, 19, 21, and 22 of United States Patent No. 7,426,720;

  • Claims 10 and 11 of United States Patent No. 6,125,447; and

  • Claims 13, 14, and 15 of United States Patent No. 6,192,476

It is also my opinion that Google is liable for direct and indirect infringement in the manner described above.

768. For the forgoing reasons, it is my opinion that the patents-in-suit form the basis for consumer demand for Android by developers and end-users.

769. For the forgoing reasons, it is my opinion that once Google decided to adopt the Java execution model in Android, the patents-in-suit became necessary to Android achieving satisfactory performance and security.

Dated: August 8, 2011

[signature]
John C. Mitchell

____________________

3 The cited source code examples are taken from http://android.git.kernel.org/. The citations are shortened and mirror the file paths shown in http://android.git.kernel.org/. For example, "dalvikvmnativeInternalNative.c" maps to "[platform/dalvik.git] / vm / native / InternalNative.c" (accessible at http://android.git.kernel.org/?p=platform/ dalvik.git;a=blob;f=vm/native/InternalNative.c). Google has apparently made modifications to certain source code files since Oracle's Preliminary Infringement Contentions were served on December 2, 2010. As such, file paths may refer to earlier versions of Android than what is immediately available at http://android.git.kernel.org/.

384


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )