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:
- 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;
- 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;
- 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:
- 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.
- 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.
- Attached to this declaration as Exhibit B is a true and correct copy of U.S. Patent
No. RE 38,104 (“the ‘104 patent”).
- 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.
- Attached to this declaration as Exhibit D is a true and correct copy of U.S. Patent
No. 5,966,702 (“the ‘702 patent”)
- 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.
- 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.
- 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.
- 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).
- 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).
- 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.
- 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).
- 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.
1
- 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
|