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
, 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 method. The preloader reads
5
any found method against memory to see what would happen if the 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 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 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
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
Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.
Why Is My Information Online?