Oracle America, Inc. v. Google Inc.

Filing 128

TENTATIVE CLAIM-CONSTRUCTION ORDER AND REQUEST FOR CRITIQUE re-filed with signature re #127 Order. Signed by Judge Alsup on April 27, 2011. (whalc1, COURT STAFF) (Filed on 4/28/2011)

1
2
3
4
5

IN THE UNITED STATES DISTRICT COURT

6
FOR THE NORTHERN DISTRICT OF CALIFORNIA
7
8
9

ORACLE AMERICA, INC.,

11
For the Northern District of California

United States District Court

10

12
13

No. C 10-03561 WHA

Plaintiff,
TENTATIVE CLAIMCONSTRUCTION ORDER AND
REQUEST FOR CRITIQUE

v.
GOOGLE INC.,
Defendant.
/

14
15

INTRODUCTION

16

In this patent and copyright infringement action involving computer technology, the

17

parties seek construction of six terms found in six of the seven asserted patents. Five of the six

18

terms are construed below. The sixth term, which is really at least three separate terms, will not

19

be construed at this time. The parties have until NOON ON MAY 6, 2011, to submit a five-page

20

critique (double-spaced, 12-point Times New Roman font, no footnotes, and no attachments)

21

limited to points of critical concern. This will be an opportunity for the parties to focus solely on

22

their most cogent critique, not to rehash every point made in the briefs and at the hearing.

23
24

STATEMENT
The Java software platform is central to this action. The patents at issue claim

25

improvements to the Java technology, so a basic understanding of Java is a necessary foundation

26

for construing the disputed patent terms. The Java concepts explained in this portion of the order

27

are not part of the claimed inventions of any asserted patents; rather, they constitute the prior art

28

upon which those inventions built.

1

Java was (and is) a technology that enabled software developers to write programs that

2

were able to run on a variety of different types of computer hardware without having to rewrite

3

the programs for each different type of computer hardware or “machine.” Java was not the first

4

“write once, run anywhere” solution, but it has become one of the most popular

5

software platforms.

6

Computer programs were written in human-readable programming languages, such as C

by computer hardware. Only “machine code,” which was much simpler, could be used by

9

computers. Most machine code was in a binary language, meaning it consisted entirely of 0s and

10

1s. Thus, a program had to be converted from source code into machine code before it could be

11
For the Northern District of California

and C++. Code written in these human-readable languages — “source code” — was not readable

8

United States District Court

7

run, or “executed.” This conversion traditionally was performed by a “compiler,” which

12

converted an entire program in one step and produced an output file of machine code which then

13

could be executed. The conversion also could be performed by an “interpreter,” which converted

14

portions of the program in different steps, as needed, while the program was being executed. No

15

matter how source code was converted to machine code, however, the source code had to be

16

written specifically for the hardware architecture that ultimately would run the machine code. For

17

example, word processing software written for an Apple Mac would not run on an IBM PC, and

18

vice versa.

19

Java used a “virtual machine” to make software programs more portable. A virtual

20

machine was itself a software program that emulated a particular hardware architecture. Java

21

virtual machines were written for different types of computer hardware (such as Macs and PCs),

22

but they all could read the same type of Java “bytecode.” Bytecode was an intermediate form of

23

code that was simpler than source code but not as simple as machine code. Source code for a

24

particular program could be compiled into bytecode instead of machine code, and then the

25

bytecode could be distributed to virtual machines running on top of various types of computer

26

hardware. The virtual machines then could run the program, translating the bytecode into

27

machine code compatible with the particular hardware architecture on which the virtual machine

28

was implemented. Thus, a program written for the Java virtual machine could be run on any
2

1

computer with a Java virtual machine, regardless of that computer’s underlying

2

hardware architecture.

3

The public Java tutorials represent this process as follows:

4
The Java Technology
5
6
7
8

source code was stored in files with the “.java” extension. After the source code was compiled

11
For the Northern District of California

As depicted above, Java source code was written in the Java programming language, and Java

10

United States District Court

9

into bytecode, Java bytecode was stored in files with the “.class” extension. The Java virtual

12

machine (“VM”) could read the .class files and send instructions to computer hardware in

13

machine-readable binary code. The class files that made up the Java bytecode are important to

14

several of the asserted patents. A basic understanding of object-oriented programming is a

15

prerequisite to understanding Java class files.

16

Object-oriented programming was a new paradigm that differed from the traditional,

17

“procedural” approach to computer programming. Under the procedural approach, a program

18

typically consisted of a list of commands. The list could be stored in one executable file. Under

19

the object-oriented approach, on the other hand, a program was distributed among various

20

“objects.” An object was an encapsulated set of methods and data fields on which the methods

21

could act. Objects could work with one another through defined interfaces. Objects, however,

22

were not files. Objects were structures that existed only while a program was running. For

23

purposes of this order, a more detailed description of objects is not necessary; it suffices that

24

objects were the basic components of a running program that was written in an object-oriented

25

programming language.

26

Objects are relevant, however, in that they are closely related to class files in the Java

27

prior art. In Java, an object was instantiated, or called into being while a program was running,

28

from a single class file. Indeed, multiple objects could be instantiated from the same class file.
3

1

This was possible because each Java class file contained the definition of a single class, and each

2

class was a blueprint or prototype from which objects could be created. As noted, Java class files

3

were the files in which the Java bytecode comprising a program was stored. Java class files

4

conformed to the Java class file format, which specified that each class file contained sixteen

5

different portions called “structures” or “items.” Each item contained a different type of data or

6

methods. Of the sixteen items that made up a Java class file, only two are relevant to this order:

7

the constant pool table and the methods. The “constant pool” portion of a class file contained a

8

table of constants that were referred to within the class. The “methods” portion of a class file

9

contained a table of all methods declared by the class.
The foregoing discussion sets forth the prior art concepts upon which the asserted patents

11
For the Northern District of California

United States District Court

10

built. Because bytecode was not as simple as machine code, running bytecode was a more

12

cumbersome task — it consumed more processor time and memory space, both of which were

13

scarce computing resources. Most of the patents Oracle asserts relate to improving the efficiency

14

of this process. Two of the patents relate to improving its security.

15

Java was developed by Sun Microsystems, Inc. in the 1990s. Oracle Corporation acquired

16

Sun Microsystems and renamed it Oracle America, Inc. in January 2010. Seven months later,

17

Oracle America filed this action claiming infringement of its patents and copyrighted works

18

related to Java improvements. The accused products employ Android, a software platform that

19

was designed for mobile computing devices and that competes with Java in that market. Both

20

Java and Android are complex software platforms. Only part of Java and part of Android are

21

relevant to this action.

22

One hundred thirty-two claims from the following seven United States patents currently

23

are at issue in this clash of the mobile-computing titans: (1) No. 5,966,702; (2) No. 6,061,520;

24

(3) No. 6,125,447; (4) No. 6,192,476; (5) No. RE38,104; (6) No. 6,910,205; and

25

(7) No. 7,426,720. The parties seek construction of terms and phrases appearing in six of these

26

seven patents. The five terms construed by this order appear in three of them. Overviews of

27

these patents, the disputed terms, and the associated claims are covered in detail in the

28

analysis below.
4

1
2

ANALYSIS
Courts must determine the meaning of disputed claim terms from the perspective of one of

3

ordinary skill in the pertinent art at the time the patent was filed. Chamberlain Group, Inc. v.

4

Lear Corp., 516 F.3d 1331, 1335 (Fed. Cir. 2008). While claim terms “are generally given their

5

ordinary and customary meaning,” the “claims themselves provide substantial guidance as to the

6

meaning of particular claim terms.” As such, other claims of the patent can be “valuable sources

7

of enlightenment as to the meaning of a claim term.” Critically, a patent’s specification “is

8

always highly relevant to the claim construction analysis.” Phillips v. AWH Corp., 415 F.3d

9

1303, 1312–15 (Fed. Cir. 2005) (en banc) (internal quotations omitted). Indeed, claims “must be
read in view of the specification, of which they are a part.” Markman v. Westview Instruments,

11
For the Northern District of California

United States District Court

10

Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc), aff’d, 517 U.S. 370 (1996). Finally, courts also

12

should consider the patent’s prosecution history, which “can often inform the meaning of the

13

claim language by demonstrating how the inventor understood the invention and whether the

14

inventor limited the invention in the course of prosecution, making the claim scope narrower than

15

it would otherwise be.” These components of the intrinsic record are the primary resources in

16

properly construing claim terms. Although courts have discretion to consider extrinsic evidence,

17

including dictionaries, scientific treatises, and testimony from experts and inventors, such

18

evidence is “less significant than the intrinsic record in determining the legally operative meaning

19

of claim language.” Phillips, 415 F.3d at 1317–18 (internal quotations omitted).

20

While this order acknowledges that the parties have a right to the construction of all

21

disputed claim terms by the time the jury instructions are settled, the Court will reserve the

22

authority, on its own motion, to modify the constructions in this order if further evidence —

23

intrinsic or extrinsic — warrants such a modification. Given that claim construction is not a

24

purely legal matter, but is (as the Supreme Court describes it) a “mongrel practice” with

25

“evidentiary underpinnings,” it is entirely appropriate for the Court to adjust its construction of

26

claims prior to trial if the evidence compels an alternative construction. Markman, 517 U.S.

27

at 378, 390. The parties should be aware, however, that they are not invited to ask for

28
5

1

reconsideration of the constructions herein. Motions for reconsideration may be made only in

2

strict accordance with the rules of procedure, if at all.
THE ’702 PATENT

3

1.

4

The ’702 patent, entitled “Method and Apparatus for Pre-Processing and Packaging Class

5

Files,” was issued on October 12, 1999. Sun Microsystems is the assignee of the ’702 patent; as

6

explained, plaintiff Oracle is the successor to Sun. Nine claims from the ’702 patent are asserted

7

in this litigation: independent claims 1, 7, and 13, and dependent claims 5, 6, 11, 12, 15, and 16,

8

which refer to them. One term construed by this order is found in the ’720 patent. It is italicized

9

in the claims below.

11
For the Northern District of California

United States District Court

10

12

Claim 1 covers (col. 51:2–12):
1.

A method of pre-processing class files comprising:
determining plurality of duplicated elements in a plurality
of class files;

13
14

forming a shared table comprising said plurality of
duplicated elements;

15

removing said duplicated elements from said plurality of
class files to obtain a plurality of reduced class files; and

16
17

forming a multi-class file comprising said plurality of
reduced class files and said shared table.

18
19
20
21
22
23
24
25
26
27
28
6

1
2

Claims 7 covers (col. 51:43–59):
7.

3

a computer usable medium having computer readable
program code embodied therein for pre-processing class
files, said computer program product comprising:

4
5

computer readable program code configured to
cause a computer to determine a plurality of
duplicated elements in a plurality of class files;

6
7

computer readable program code configured to
cause a computer to form a shared table comprising
said plurality of duplicated elements;

8
9

computer readable program code configured to
cause a computer to remove said duplicated
elements from said plurality of class files to obtain a
plurality of reduced class files; and

10
11
For the Northern District of California

United States District Court

A computer program product comprising:

computer readable program code configured to
cause a computer to form a multi-class file
comprising said plurality of reduced class files and
said shared table.

12
13
14
15

Claim 13 covers (col. 52:39–53):
13.

An apparatus comprising:

16

a processor;

17

a memory coupled to said processor;

18

a plurality of class files stored in said memory;

19

a process executing on said processor, said process
configured to form a multi-class file comprising:

20

22

a plurality of reduced class files obtained from said
plurality of class files by removing one or more
elements that are duplicated between two or more
of said plurality of class files; and

23

a shared table comprising said duplicated elements.

21

24
The essence of the invention claimed by the ’702 patent is the “multi-class file” format,
25
which is a package containing a set of reduced class files and other related items. One
26
embodiment of the multi-class file format is depicted as follows (col. 9:66–67):
27
28
7

1

Figure 5 from the ’702 Patent: A Multi-Class File

2
3
4
5
6
7
8
9

11
For the Northern District of California

United States District Court

10

12
13
14
15
16

A.

“reduced class file”

17

The parties dispute the phrase “reduced class file.” The parties define this term

18

differently, but only Google seeks a construction to clarify it for the jury. The parties’ proposed

19

constructions are shown below.

20
21
22
23

ORACLE’S PROPOSED
CONSTRUCTION

GOOGLE’S PROPOSED
CONSTRUCTION

No construction necessary. A “reduced
class file” contains a subset of the code
and data contained in a class file.

“a class file containing a subset of the
data and instructions contained in a
corresponding original class file”

24

The construction of this phrase is relevant to the parties’ infringement arguments. Oracle and

25

Google agree that a “reduced class file” contains a subset of the contents of a “class file,” though

26

they characterize the contents differently — “code and data” versus “data and instructions.” The

27

main dispute regarding this term, however, is whether a “reduced class file” is a “class file.” This

28

order does not find good cause for adopting such a limitation.

8

1

The parties disagree as to what a “class file” is, but they did not select that phrase for

2

construction and did not brief the issue. The patent specification uses the phrase “class file” to

3

refer to the Java class file format (cols. 7:23, 11:25). In the prior art, Java compilers compiled

4

Java source code into Java bytecode, which was made up of Java class files. Each Java class

5

file stored the definition of one class (col. 7:31–32). The ’702 patent specification

6

incorporated a detailed description of the Java class file format and illustrated it graphically in

7

Figure 3 (col. 7:53).

8
Figure 3 from the ’702 patent: A Java Class File
9

11
For the Northern District of California

United States District Court

10

12
13
14
15
16
17
18
19
20

As shown in Figure 3, a Java class file contained a set of sixteen “structures” or “items,” such as

21

the constant pool table (col. 11:48–49). Each item contained a different type of data or methods.

22

As a group, the sixteen items of a Java class file contained information defining a single class. A

23

“class” was a general concept from the object-oriented style of computer programming, as

24

explained previously. On the other hand, a Java class file (which defined a class) had to comply

25

with strict format requirements. The patent specification and the Java literature set forth detailed

26

descriptions of how a Java class file and each of its items must be expressed in order to work with

27

the rest of the Java platform (cols. 7–43). Having described what a class file generally is in the

28
9

1

context of the ’702 patent, this order turns to the question of whether a reduced class file must be

2

a class file.

3

The most that can be gleaned about reduced class files from the claims themselves is that

(col. 51:7–8, 54–56). Thus, the patent teaches that if one starts with a class file, and performs

6

certain operations on that class file, then one is left with a “reduced class file.” The before-item is

7

a class file. The after-item is a reduced class file. The after-item is different from the before-

8

item. There is no indication in the claims, specification, or prosecution history that the after-item

9

must meet the detailed format requirements for Java class files. The after-item is simply whatever

10

is left after the before-item has been “reduced.” Presumably, it may or may not qualify as a class

11
For the Northern District of California

reduced class files are obtained by removing duplicated elements from a plurality of class files

5

United States District Court

4

file, depending on what specific changes it underwent.

12

Google argues that the claim language and specification show that a reduced class file is a

13

class file. First, Google notes that the phrase “reduced class file” contains the phrase “class file.”

14

According to Google, this observation implies that a reduced class file is a class file, just as a

15

green house is a house. Second, Google notes that the specification refers to reduced class files as

16

simply “class files” or “classes” in some circumstances (e.g., cols. 4:64–5:5, Fig. 4). According

17

to Google, this second observation implies that the after-item produced by reducing a class file is

18

something that still qualifies as a class file (Google Br. 12–13). This order disagrees with Google

19

on both accounts. The fact that the patent uses the phrases “reduced class file” and “class file” to

20

refer to the after-item that is obtained by reducing a class file is simply an artifact of the drafting

21

process. These phrases indicate the provenance of the item produced by the reduction operation.

22

They do not indicate that the essential features of that item are identical to those of the item from

23

which it was produced.

24

By way of analogy, one might start with a document and then shred the document to

25

produced a shredded document. One might go on to describe sweeping up and disposing of “the

26

shredded document” or “the document” even though the item produced by the shredding process

27

might not be considered a document on its own terms. So too here. Just as a document is

28

shredded to produce a shredded document, a class file is reduced to produce a reduced class file.
10

1

The use of such convenient terminology is not strong enough evidence to support a finding that

2

the reduced class files disclosed in the ’702 patent must satisfy all the format requirements for

3

Java class files.

4

Because the specification does not define the phrase “reduced class file,” this order will

5

construe the phrase in accordance with the limited elaboration provided in the claim language.

6

Independent claims one, seven, and thirteen state that reduced class files are obtained by

7

removing one or more duplicated elements from a plurality of class files that contain the same

8

element or elements. Accordingly, the term “reduced class file” shall be construed as “what

9

remains after one or more duplicated elements have been removed from a class file.” This order
neither requires nor prohibits reduced class files from qualifying as Java class files.
THE ’520 PATENT

11
For the Northern District of California

United States District Court

10

2.

12

The ’520 patent, entitled “Method and System for Performing Static Initialization,” was

13

issued on May 9, 2000. Sun Microsystems is the assignee of the ’520 patent, and plaintiff Oracle

14

is the successor to Sun. Twenty-two claims from this patent are asserted in this litigation:

15

independent claims 1, 6, 12, and 18, and dependent claims 2–4, 7–11, 13–17, and 19–23. One of

16

the disputed terms construed by this order is found in the ’520 patent. It appears only in

17

dependent claims 3 and 4. It is italicized in the claims below.

18
19

Claim 1 covers (col. 9:47–62):
1.
A method in a data processing system for statically
initializing an array, comprising the steps of:

20

22

compiling source code containing the array with static
values to generate a class fie with a clinit method
containing byte codes to statically initialize the array to the
static values;

23

receiving the class file into a preloader;

24

simulating execution of the byte codes of the clinit method
against a memory without executing the byte codes to
identify the static initialization of the array by the
preloader;

21

25
26
27

storing into an output file an instruction requesting the
static initialization of the array; and

28

interpreting the instruction by a virtual machine to perform
the static initialization of the array.
11

1
2

Claim 3 covers (cols. 9:66–10:5):
3.
The method of claim 1 wherein the play executing step
includes the steps of:

3
allocating a stack;
4
5

reading a byte code from the clinit method that manipulates
the stack; and

6

performing the stack manipulation on the allocated stack.

7
8

Claim 4 covers (col. 10:6–12):
4.
The method of claim 1 wherein the play executing step
includes the steps of:

9
allocating variables;
11
For the Northern District of California

United States District Court

10
reading a byte code from the clinit method that manipulates
local variables of the clinit method; and

12

performing the manipulation of the local variables on the
allocated variables.

13
14

The ’520 patent, issued seven months after the ’702 patent, provided another way to

15

improve the efficiency of the Java system. Recall that in the basic Java setup, Java source code

16

was compiled by a Java compiler into Java bytecode. The bytecode was contained in class files

17

with the .class extension. The invention of the ’702 patent provided a way to compress the class

18

files and package a group of them into a multi-class (.mclass) file. A Java virtual machine then

19

could run the .mclass file more efficiently than it could have run the set of .class files from which

20

it was made if the .class files had not been pre-processed. A “preloader” performed this pre-

21

processing and packaging of .class files into .mclass files. The invention claimed in

22

the ’520 patent is another pre-processing task to be performed by the preloader, which makes the

23

ultimate task of running the .mclass file on the virtual machine even more efficient.

24

Whereas the ’702 patent provided a way to compress some of the data stored in class files,

25

the ’520 patent provided a way to compress some of the method instructions, also stored in class

26

files, that operate on that data. Specifically, the invention of the ’520 patent provided “an

27

improved system for initializing static arrays in the Java programming environment”

28

(col. 3:44–45). Essentially, it “reduc[es] the amount of code executed by the virtual machine to
12

1

statically initialize an array” (col. 2:62–64). The Java compiler generated a special method,

2

<clinit>, to perform class initialization, including initialization of static arrays (col. 1:59–61).

3

Under the invention of the ’520 patent, when a preloader is consolidating a set of .class files into

4

an .mclass file, the preloader scans the class files for any <clinit> method. The preloader reads

5

any found <clinit> method against memory to see what would happen if the <clinit> method

6

actually were executed, and reduces the result into a set of shorthand instructions, which it stores

7

in the .mclass file as a replacement for the bulkier <clinit> method code (cols. 2:61–3:29,

8

3:43–4:11). Thus, less code must be loaded and executed by the virtual machine in order to

9

initialize the classes in the multi-class file.

11
For the Northern District of California

United States District Court

10

12
13
14
15
16

A.

“the play executing step”

The parties dispute the term “the play executing step” in dependent claims three and four
of the ’520 patent. The parties’ proposed constructions are shown below.
ORACLE’S PROPOSED
CONSTRUCTION

GOOGLE’S PROPOSED
CONSTRUCTION

“The play executing step” in claims 3
and 4 is a reference to the “simulating
execution” step in claim 1.

Indefinite — cannot be construed.

17

The construction of this term is relevant to the parties’ invalidity arguments. Google argues that

18

the term “the play executing step” in dependent claims three and four is indefinite for lack of an

19

antecedent basis in claim one. Oracle disagrees, arguing instead that the term refers to the

20

“simulating execution” step of claim one. This order agrees with Oracle. Play executing and

21

simulating execution of code are synonymous terms in the ’520 patent.

22

The specification of the ’520 patent explicitly defines “simulates executing” and “play

23

executes” as synonyms. Both the summary of the invention and the detailed description of the

24

invention state that the preloader “simulates executing (‘play executes’)” the <clinit> methods it

25

finds (cols. 2:65–67, 3:59–60). The detailed description further explains: “When play executing,

26

discussed below, the preloader simulates execution of the byte codes contained in the <clinit>

27

method by the virtual machine.” (col. 4:64–66). In other portions of the specification, the terms

28

are used interchangeably (cols. 3:12, 3:25, 4:38–39, 6:26–27). In light of the specification, a

13

1

person of ordinary skill in the art at the time of the invention would have understood “the play

2

executing step” of claim one to be “simulating executing of the byte codes of the clinit method

3

against a memory without executing the byte codes to identify the static initialization of the array

4

by the preloader.”

5

The prosecution history of the ’520 patent helps explain why the first set of claims

6

contains this mismatched language. (By contrast, independent claim six and all of its dependent

7

claims refer to “play executing,” and independent claim eighteen and all of its dependent claims

8

refer to “simulating execution of” code.) In the original patent application, the third method step

9

of the first claim was drafted as “play executing the byte codes of the clinit method against a
memory to identify the static initialization of the array by the preloader” (Peters Supp. Exh. 11

11
For the Northern District of California

United States District Court

10

at ’520 Application). Claims one and three were rejected as anticipated by a publication that the

12

examiner found to disclose a similar method, including the step of “compar[ing] the execution of

13

byte codes of the clinit method against memory to identify the static initialization of an array by

14

the preloader” (id. at Office Action, July 21, 1999). The examiner also objected to claims two,

15

four, and five as dependent upon a rejected base claim.

16

In response to the rejection of claims one and three, the applicants amended claim one.

17

The phrase “without executing the byte codes” was added, and “play executing” was replaced

18

with “simulating execution of” (id. at Response, Oct. 18, 1999). During a telephone interview,

19

the examiner agreed that this amendment to claim one rendered all of the pending claims

20

allowable over the cited art. The examiner’s summary of that interview stated that the “general

21

background of the invention was discussed” but that “[n]o prior art was discussed.” The

22

examiner wrote: “In particular, the disclosure of the ‘pre-loader’ and ‘simulation’ function as

23

disclosed in claims 1, 6 and 12.. [sic] Narrowing the claims to make clear the functions of these

24

elements were [sic] also discussed.” (id. at Interview Summary, Oct. 13, 1999). The claims

25

ultimately were allowed with a finding that the prior art “fails to anticipate or render obvious the

26

simulation of execution with respect to class initialization, without executing byte codes.” In

27

particular, the examiner found that the reference that prompted the amendment “teaches of

28
14

1

comparing the execution of byte codes, but fails to address the issue of simulating the process

2

without execution” (id. at Notice of Allowability).

3

Thus, the key distinction was that the method step claimed as part of the ’520 patent

4

invention did not involve actually executing the code. Changing “play executing” to “simulating

5

executing of” may have helped clarify this point, but adding the phrase “without executing the

6

byte codes” is what explicitly narrowed the claim to avoid the prior art. The prior art addressed

7

“comparing execution” but did not use the phrase or concept of “play executing” (id. at Notice of

8

Allowability; M. Cierniak, and Wei Li, Briki: An Optimizing Java Compiler, proceedings of

9

Compcon conference, Feb. 23–26, 1997). Moreover, the examiner’s characterization of
application claims one, six, and twelve as each containing a “simulation” function shows that he,

11
For the Northern District of California

United States District Court

10

too, viewed “play executing” and “simulating execution of” as the same thing; each of those

12

claims recited “play executing,” and none of them used any form of the word “simulation.”

13

Despite Google’s best efforts to show otherwise, there is no evidence in the prosecution history

14

that the applicant surrendered the position that “play executing” and “simulating execution of” are

15

equivalent. The third method step of claim one was reworded from “play executing” to

16

“simulating execution of,” and the dependent claims referring “play executing” were not also

17

reworded to match. That is all.

18

The “play executing” reference in claims three and four may be sloppy, but it is not

19

insolubly indefinite. See Exxon Research and Eng’g Co. v. United States, 265 F.3d 1371, 1375

20

(Fed. Cir. 2001). The specification makes plain that “play executing” is “simulating execution

21

of,” and the prosecution history does not compel a contrary interpretation. Indeed, if the

22

examiner believed there was an important difference between “play executing” and “simulating

23

execution of,” the patent would not have issued as is. Google’s arguments that the disputed term

24

is indefinite and that the prosecution history shows a difference of meaning between “play

25

executing” and “simulating execution of” are refuted by the foregoing analysis. Furthermore,

26

adopting Oracle’s proposed construction of “play executing,” which is simply a recognition that it

27

refers to the “simulating execution” step of claim one, would not rise to the level of judicial

28
15

1

correction of a claim-drafting error, as Google suggests. See Novo Indus., L.P. v. Micro Molds

2

Corp., 350 F.3d 1348, 1354 (Fed. Cir. 2003).

3

Having fully considered the parties’ arguments, the ’520 patent, and its prosecution

4

history, this order adopts Oracle’s construction of “the play executing step.” Google’s vigorous

5

hand-waiving simply does not get around the specification’s explicit definition of “play

6

executing” and “simulating execution of” as synonyms. Accordingly, the “the play executing

7

step” in claims three and four will be construed as a reference to the “simulating execution”

8

method step of claim one.

9

THE ’104 PATENT

The ’104 patent, entitled “Method and Apparatus for Resolving Data References in

11
For the Northern District of California

United States District Court

10

3.

Generated Code,” was issued on April 29, 2003. It is a continuation of U.S. Patent No.

12

RE36,204, which in turn claims priority from U.S. Patent No. 5,367,685, issued on November 22,

13

1994. Sun Microsystems is the assignee of the ’104 patent, and plaintiff Oracle is the successor

14

to Sun. Thirty-one claims from this patent are asserted in this litigation: independent

15

claims 11–13 and 17–41, and dependent claims 14–16. Three of the disputed terms construed by

16

this order are found in the ’520 patent. Each of these terms appears in most of the asserted

17

claims. The terms are italicized in the claim below, which is provided as a

18

representative example.

19
20
21
22
23

Claim 12 covers (col. 7:14–27):
12.
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:
interpreting said instructions in accordance with a program
execution control; and

24
25

resolving a symbolic reference in an instruction being
interpreted, said step of resolving said symbolic reference
including the substeps of:

26
27

determining a numerical reference corresponding to
said symbolic reference, and

28

storing said numerical reference in a memory.
16

1

The claimed invention is “a hybrid compiler-interpreter” “for generating executable code

2

and resolving data references in the generated code” (abstract; cols. 2:27–28, 3:33–34). Under

3

the claimed invention, a compiler compiles source code into an intermediate form of code, and

4

then an interpreter translates the intermediate form code for execution. The intermediate form

5

code contains both numeric and symbolic data references, so the interpreter must employ a

6

different subroutine to handle each type of reference while translating the intermediate form code.

7

Specifically, a static field reference routine is used for numeric references, and a dynamic field

8

reference routine is used for symbolic references (cols. 2:27–59, 3:33–5:57).

9

“intermediate form code” and “intermediate form object code”

The parties agree that “intermediate form code” and “intermediate form object code” are

11
For the Northern District of California

United States District Court

10

A.

the same thing in the context of the ’104 patent, but they disagree as to what these terms mean.

12

These disputed terms appear in about two-thirds of the thirty-one asserted claims of the ’104

13

patent. The parties’ proposed constructions are shown below.

14
15
16
17

ORACLE’S PROPOSED
CONSTRUCTION

GOOGLE’S PROPOSED
CONSTRUCTION

“executable code that is generated by
compiling source code and is
independent of any computer
instruction set”

“code that is generated by compiling
source code and is independent of any
computer instruction set”

18

The construction of these terms is relevant to the parties’ invalidity arguments. The parties agree

19

that “intermediate form code” and “intermediate form object code” are “code that is generated by

20

compiling source code and is independent of any computer instruction set.” The parties’ sole

21

disagreement with respect to these terms is whether the intermediate code must be executable.

22

This order finds that it does. Most persuasive is the following statement, which appears twice in

23

the specification, introducing both the summary of the invention and the detailed description of

24

presently preferred and alternate embodiments: “A method and apparatus for generating

25

executable code and resolving data references in the generated code is disclosed” (cols. 2:27–29,

26

3:33–35). That is, executable code is generated, and data references in the generated excutable

27

code are resolved. In every claimed embodiment of the invention that uses the disputed terms, the

28

“intermediate form code” or “intermediate form object code” is the code that has been generated
17

1

by a compiler and that contains data references which are then resolved by an interpreter. Hence,

2

the “intermediate form code” or “intermediate form object code” in these claims is the “generated

3

code” of the invention, which the specification explicitly states is executable.

4

Other intrinsic evidence supports this conclusion as well. For example, the specification

5

notes that “generated coded [sic] are in intermediate form” (col. 4:38–39). This statement

6

confirms that the “intermediate form code” and “intermediate form object code” in the claims are

7

the “generated code” that the specification describes as executable. The specification also refers

8

to the “execution performance” of “the ‘compiled’ intermediate form object code” of the

9

invention, suggesting not only that it is executable, but also that it can be executed as efficiently
as “traditional compiled object code” while maintaining greater flexibility (col. 5:41–49).

11
For the Northern District of California

United States District Court

10

Furthermore, the background portion of the specification lays the foundation that a “program in

12

intermediate form is executed by” an interpreter (cols. 1:67–2:2) (emphasis added).

13

The claims themselves also refer to the intermediate code as executable. Asserted

14

independent claim eleven, for example, claims “intermediate form object code constituted by a set

15

of instructions, certain of said instructions containing one or more symbolic references,” as well

16

as “a processor configured to execute said instructions containing one or more symbolic

17

references” (col. 7:6–10) (emphasis added). Google protests that the processor of claim eleven

18

executes “instructions” rather than “intermediate form object code,” but the plain language of the

19

claim explains that these instructions are the intermediate form object code. The other asserted

20

claims have similar references to execution.

21

Independent claims one and six, which were not re-issued, specifically claim “generating

22

executable code in an intermediate form” (cols. 5:63, 6:36–37). Oracle views this claim language

23

as further support for the position that code in intermediate form is executable. Google, on the

24

other hand, views the exclusion of these claims from the re-issued ’104 patent as proof of “the

25

patentee’s express intent to claim ‘intermediate form [object] code’ that is not necessarily

26

executable” (Google Resp. Br. 16). Google, however, does not point to any evidence from the

27

prosecution history that would support this inference of patentee intent.

28
18

1

Having reviewed the prosecution history of the ’104 patent, this order finds no support for

2

such an inference. The applicant explained that he sought re-issuance because the original patent

3

claimed less than he had a right to claim in three respects, none of which had anything to do with

4

expanding the scope of the claims to include intermediate form code that is not executable.

5

Rather, the expansions of the claims were intended to cover the following three areas:

6

(1) complimentary compilers and interpreters that could be sold separately rather than packaged

7

into a single product; (2) more specific “handling of numerical values corresponding to symbolic

8

references”; and (3) Beauregard-type “claims more specifically directed to computer program

9

code devices.” (Peters Supp. Exh. 11 at ’104 Gosling Decl., Nov. 21, 1996). Moreover, the ’104
patent was issued after the applicant overcame a series of rejections, but all the rejections were

11
For the Northern District of California

United States District Court

10

based on procedural defects, not prior art. The applicant never narrowed the scope of the claims

12

to avoid prior art, nor did he affirmatively disclaim intermediate form code that was or was not

13

executable (see id. at ’104 office actions and responses).

14

Google also argues for its inference of patentee intent as a matter of law. Since claims one

15

and six refer to the intermediate code as “executable” but the other claims do not, Google infers

16

that the property of being executable is not a limitation of the intermediate code in the other

17

claims. See Philips, 415 F.3d at 1314. Drawing this inference may be proper as a matter of law,

18

but the inference is overcome by the strong countervailing evidence from the specification

19

discussed above.

20

Google’s remaining arguments are unpersuasive as well. The critique that Oracle’s

21

proposed construction “would limit the term to code that is not an ‘intermediate representation’”

22

(Google Resp. Br. 17) raises no concern at all, because the patent claims and specification

23

repeatedly make clear that “intemediate form code” and “intermediate representations” of code

24

are two different things (e.g., col. 4:21–23; Figs. 4–5; clm. 21). Similarly, the fact that the

25

limitation “executable” could encompass both execution directly by a computer processor

26

(hardware) and execution by a virtual machine (software) is neither confusing nor problematic.

27
28

Although the limitation that “intermediate form code” and “intermediate form object
code” must be executable is not explicitly called out in the asserted claims, this order finds that
19

1

the limitation would be implicit to a person of ordinary skill in the art reading the claims in light

2

of the surrounding claim language and specification. Accordingly, Oracle’s proposed

3

construction of these terms will be adopted. Both “intermediate form code” and “intermediate

4

form object code” will be construed to mean “executable code that is generated by compiling

5

source code and is independent of any computer instruction set.”

6

B.

“symbolic reference”

7

The parties disagree both as to whether the term “symbolic reference” requires

8

construction, and, if so, how it should be construed. This disputed term appears in each of the

9

thirty-one asserted claims of the ’104 patent. The parties’ proposed constructions are

11
For the Northern District of California

United States District Court

10

12
13
14

shown below.
ORACLE’S PROPOSED
CONSTRUCTION

GOOGLE’S PROPOSED
CONSTRUCTION

No construction necessary. The
ordinary meaning is “a reference
by name.”

“a dynamic reference to data that is
string- or character-based”

15

The construction of this term is relevant to the parties’ infringement arguments. Oracle asserts

16

that the ordinary meaning of “symbolic reference” is “a reference by name,” whereas Google

17

would construe “symbolic reference” to mean a data reference that is dynamic and is string- or

18

character-based. A person of ordinary skill in the art might find both parties’ proposed

19

constructions to be technically accurate, but they rely heavily on extrinsic evidence and would not

20

be particularly helpful to a jury. Instead of choosing between them, this order steers a middle

21

course guided by the intrinsic evidence of the ’104 patent itself.

22

The ’104 patent teaches two different types of data references: numeric references and

23

symbolic references. The claimed invention includes an interpreter with two different sub-

24

routines: “a static field reference routine for handling numeric references and a dynamic field

25

reference routine for handling symbolic references” (col. 2:42–44). Computers stored data in

26

memory locations defined by numeric addresses. A numeric data reference was one that

27

identified data directly by its memory-location address. For example, the command “load the

28

data stored in memory slot 2” contains a numeric reference to the data stored in slot 2 (col.

20

1

1:26–41). The claimed invention would use a static subroutine to interpret this numeric data

2

reference — all it would have to do is go get whatever data is stored in slot 2. The data stored in

3

slot 2 might turn out to be, for example, “17” (col. 5:24–31).

4

A symbolic data reference, on the other hand, did not identify data directly by its memory-

(col. 1:64–67). For example, the command “load the data called y” contains a symbolic reference

7

to the data called y. The claimed invention would use a dynamic subroutine to interpret this

8

symbolic reference — it would have to figure out that “y” means “17” or that “y” means “the data

9

stored in memory slot 2,” and then get the data called y (col. 5:13–19). Figure 8 depicts the step

10

of rewriting a symbolic reference as a numeric reference, which is included in some embodiments

11
For the Northern District of California

location address. Instead, a symbolic reference identified data by a “symbolic name”

6

United States District Court

5

of the invention.

12
13

Figure 8 from the ’104 Patent:
Rewriting a Symbolic Reference as a Numeric Reference

14
15
16
17
18
19
20
21
22
23
24
25
26
27

This contrast between symbolic references and numeric references pervades the asserted
claims. Claim twelve, which is reproduced above, discloses “resolving a symbolic reference” to
include the substeps of “determining a numerical reference corresponding to said symbolic
reference, and storing said numerical reference in a memory” (col. 7:33–37). Many of the other
claims contain similar language.

28
21

1

The numeric and symbolic references discussed in the ’104 patent are references to data.

2

The patent discloses these two types of data references in opposition to one another, and the

3

specification refers to symbolic data references as references made by a “symbolic name.” These

4

observations from the intrinsic record shall guide construction of the disputed term. The patent’s

5

distinction that symbolic references are resolved in a dynamic manner, whereas numeric

6

references are resolved in a static manner, provides a further gloss that would be useful to a jury.

7

On the other hand, delving into extrinsic dictionaries to construe the term “symbolic reference” is

8

unnecessary. Google’s proposed modifier “string- or character-based” does not correspond to any

9

terms or concepts appearing in the intrinsic record and will not be read in from the proffered
extrinsic sources. The term “symbolic reference” shall be construed as “a reference that identifies

11
For the Northern District of California

United States District Court

10

data by a name other than the numeric memory location of the data, and that is resolved

12

dynamically rather than statically.”

13
14

C.

“resolve” and “resolving”

As with the term “symbolic reference,” the parties disagree both as to whether the term

15

“resolve” or “resolving” requires construction, and, if so, how it should be construed. This

16

disputed term appears in the vast majority of the thirty-one asserted claims of the ’104 patent.

17

The parties’ proposed constructions are shown below.

18
19
20
21

ORACLE’S PROPOSED
CONSTRUCTION

GOOGLE’S PROPOSED
CONSTRUCTION

No construction necessary.
“Resolving” a symbolic reference is
determining its corresponding
numerical reference.

“replace/replacing at least for the life
of the process”

22

The construction of this term is relevant to the parties’ infringement arguments. The parties

23

disagree substantially, both as to what sort of action resolving is (i.e., determining versus

24

replacing) and whether this action carries any temporal limitation within the context of the ’104

25

patent. Again, this order finds that Google’s attempt to pile on limitations is not supported by the

26

intrinsic evidence.

27
28

The asserted claims disclose resolving symbolic data references. As an initial matter, this
order notes that the term “resolve” is used only in conjunction with symbolic references in
22

1

the ’104 patent; numeric references are not “resolved.” Accordingly, the term “resolve” shall be

2

construed within the limited context of resolving symbolic data references for purposes of

3

the ’104 patent. Some asserted claims provide that resolving a symbolic reference is

4

accomplished “by determining a numerical reference corresponding to said symbolic reference,

5

and storing said numerical reference in a memory” (e.g., clm. 19). Other asserted claims define

6

resolving a symbolic reference to include “obtaining data in accordance to said stored numerical

7

reference” as well (e.g., clm. 18). Sill other asserted claims refer to “resolving said symbolic

8

references to corresponding numerical references” or “resolv[ing] the symbolic data reference”

9

without any further explanation (clms. 17, 24). Such claims, however, also generally refer to “a

11
For the Northern District of California

United States District Court

10

numeric reference resulting from the resolution of the symbolic reference.”
Based on the extensive usage of “resolve” in the asserted claims, this order concludes that

12

“resolving” a symbolic data reference requires at least identifying the corresponding numeric

13

reference by which the data can be referenced. Resolving a symbolic reference does not,

14

however, require replacing the symbolic reference. Specifically, the fact that a symbolic

15

reference may be resolved “by determining a numerical reference corresponding to said symbolic

16

reference, and storing said numerical reference in a memory” (emphasis added) makes plain that

17

the resolution process can be completed for a symbolic reference without writing over the

18

symbolic reference. Furthermore, some claims use the words “resolve” and “replace” to refer to

19

two different steps. For example, claim 30 recites “replacing” instructions containing symbolic

20

references “with a new instruction containing a numeric reference resulting from invocation of a

21

dynamic field reference routine to resolve the symbolic data reference” (col. 10:9–13). Similarly,

22

claims one and six (which were not reissued) disclose “replacing said symbolic references with

23

their corresponding numeric references” as a separate step to be performed after the step of

24

“resolving said symbolic references to corresponding numeric references” is complete

25

(col. 6:3–5, 44–47).

26

The specification and the prosecution history are consistent with this claims-based

27

interpretation. Google leans heavily on the aspect of the invention that contemplates resolving

28

each symbolic reference only once per execution run (Google Br. 17–21). This improvement,
23

advantage could be achieved instead by storing the corresponding numeric references in another

3

convenient location. Indeed, the patent claims both approaches (e.g., clms. 13 (storing), 30

4

(replacing)). The storage or replacement also need not persist “for the life of the process” as

5

Google suggests. Nothing in the intrinsic record addresses a temporal aspect of “resolving.”

6

Even to practice the single-resolution improvement on which Google relies, the particulars of the

7

process in question would dictate the length of time the resolution of a particular symbolic

8

reference would need to last. Conceivably, if a lengthy process utilized a particular symbolic

9

reference only early on, it might be beneficial to store the corresponding numeric reference in

10

memory during the first part of the process but then empty and re-use that memory space as the

11
For the Northern District of California

however, does not require the resolution of symbolic references to include replacing them. The

2

United States District Court

1

process continues to run. The ’104 patent does not foreclose this possibility. The term “resolve”

12

should not be so limited. Having considered the parties’ arguments in the context of the intrinsic

13

record, this order holds that “resolving” a symbolic reference shall be construed to mean “at least

14

determining the numerical memory-location reference that corresponds to the

15

symbolic reference.”

16

4.

17

In an attempt to engineer a three-for-one deal or better, the parties seek construction of the

18

following set of terms: “computer-usable medium,” which appears in the ’702 patent, “computer-

19

readable storage medium,” which appears in the ’720 patent, and “computer-readable medium,”

20

which appears in the ’104, ’520, ’447, and ’476 patents. These three terms come from six

21

different patents whose issue dates span a decade and whose subject matter ranges from security

22

and access protections to loading and processing techniques.

23

REMAINING TERMS AND PATENTS

Claim terms are to be construed from the perspective of one of ordinary skill in the

24

pertinent art at the time of filing. Chamberlain, 516 F.3d at 1335. These six patents relate to

25

different specialized arts within the field of computer science — a field that is known for rapid

26

change. Construing these terms properly would require individualized attention to the intrinsic

27

evidence and prosecution history of each of the six patents from which they hail.

28
24

1

The parties were instructed to isolate no more than six disputed terms for construction by

2

way of the Markman proceedings (Dkt. No. 56 ¶ 5). This order already has construed five. The

3

request for construction of this last set of terms, which is equivalent to at least three and as many

4

as six additional terms, is too much. No more terms will be construed at this time.

5

CONCLUSION

6

The constructions set forth above will apply in this dispute. The Court will reserve the

7

authority, on its own motion, to modify these constructions if further evidence warrants such a

8

modification. Additionally, by NOON ON MAY 6, 2011, each side may file a five-page critique

9

(double-spaced, 12-point Times New Roman font, no footnotes, and no attachments) limited to
points of critical concern. This is an opportunity for the parties to focus solely on their most

11
For the Northern District of California

United States District Court

10

cogent critique, not to rehash every point made in the briefs and at the hearing. No

12

replies, please.

13
14

IT IS SO ORDERED.

15
16

Dated: April 27, 2010.

WILLIAM ALSUP
UNITED STATES DISTRICT JUDGE

17
18
19
20
21
22
23
24
25
26
27
28
25