Oracle Corporationv.Thought, Inc.

Patent Trial and Appeal Board

Apr 23, 2015

10386011 (P.T.A.B. Apr. 23, 2015)

Trials@uspto.gov Paper 45
571-272-7822 Entered: April 23, 2015

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

ORACLE CORPORATION,
Petitioner,
v.
THOUGHT, INC.,
Patent Owner.
____________

Case IPR2014-00119
Patent 7,167,862 B2
____________

Before KARL D. EASTHOM, BARBARA A. BENOIT, and
STACEY G. WHITE, Administrative Patent Judges.

BENOIT, Administrative Patent Judge.

FINAL WRITTEN DECISION
35 U.S.C. § 318(a) and 37 C.F.R. § 42.73

IPR2014-00119
Patent 7,167,862 B2

2
I. INTRODUCTION
We have jurisdiction to hear this inter partes review under 35 U.S.C.
§ 6(c). This Final Written Decision is issued pursuant to 35 U.S.C. § 318(a)
and 37 C.F.R. § 42.73. For the reasons that follow, we determine that Petitioner
has shown by a preponderance of the evidence that claims 1, 2, 4, and 5 of
U.S. Patent No. 7,167,862 B2 (Ex. 1001; “the ’862 patent”) are unpatentable.
A. Procedural History
Oracle Corporation (“Petitioner”) filed an amended Petition (“Pet.”;
Paper 5) for an inter partes review of claims 1–17. Patent Owner,
Thought, Inc., did not file a preliminary response opposing institution of a
review. On April 25, 2014, pursuant to 35 U.S.C. § 314(a), we instituted an
inter partes review for claims 1, 2, 4, and 51 of the ’862 patent as unpatentable
under 35 U.S.C. § 103(a) for obviousness over Demuth2 and Kurniawan3 and
for obviousness over Demuth, Kurniawan, and Chow.4 Paper 18 (“Inst. Dec.”).
Subsequent to institution, Patent Owner filed a Patent Owner Response
(Paper 31; “PO Resp.”), and Petitioner filed a Reply (Paper 36; “Reply”).

1 Prior to institution, Petitioner filed an unopposed motion to withdraw its
alleged grounds of unpatentability against all claims except 1, 2, 4, and 5.
Paper 16. We granted Petitioner’s motion and therefore, we considered only
challenges leveled against claims 1, 2, 4, and 5. Inst. Dec. 3–4.
2 U.S. Patent Pub. No. 2003/0212987, published Nov. 13, 2003, filed on
Feb. 28, 2002 (Ex. 1006) (“Demuth”).
3 BUDI KURNIAWAN, JAVA FOR THE WEB WITH SERVLETS, JSP, AND EJB,
Apr. 2002 (Ex. 1009) (“Kurniawan”).
4 U.S. Patent Pub. No. 2003/0149689, published Aug. 7, 2003, filed on Jan. 15,
2003 (Ex. 1008) (“Chow”).
IPR2014-00119
Patent 7,167,862 B2

3
Patent Owner filed observations on the cross-examination of Petitioner’s
declarant (Paper 39), to which Petitioner filed a response (Paper 42).
An oral hearing was held on November 18, 2014.5
B. Related Matters
Petitioner represents that the ’862 patent was asserted against it in
Thought, Inc. v. Oracle Corp., No. 3:12-05601 (N.D. Cal.). Pet. 1; see Paper
11, 1 (Patent Owner’s Mandatory Notice). Petitioner also represents that the
district court proceeding includes another patent related6 to the ’862 patent and
for which Petitioner also requested inter partes review—U.S. Patent
No. 7,103,600 B2 (Case IPR2014-00118). Pet. 1.
C. The ’862 Patent
The ’862 patent, titled “Session Bean Implementation of a System,
Method and Software for Creating or Maintaining Distributed Transparent
Persistence of Complex Data Objects and Their Data Relationships,” issued on
January 23, 2007, from an application filed March 10, 2003. It makes no
priority claim. The ’862 patent generally relates to storing and accessing data
used by a computer system according to a particular computer programming

5 This proceeding and IPR2014-00118 involve the same parties and some
similar issues. The oral arguments for both reviews were merged and
conducted at the same time. A transcript of the oral hearing is included in the
record as Paper 44.
6 Neither the ’862 patent challenged here nor U.S. Patent No. 7,103,600 B2
challenged in IPR2014-00118 make a priority claim. Petitioner represents the
patents overlap in subject matter and claim language.
IPR2014-00119
Patent 7,167,862 B2

4
paradigm—object-oriented programming. 7 Ex. 1001, col. 1, ll. 12–14; see id.
at col. 1, ll. 30–31, col. 4, ll. 1–18. Petitioner, supported by the testimony of
Dr. Antony L. Hosking as set forth in his declaration (Ex. 1011), explains that
some computer systems use the notion of “objects” to help a computer
programmer develop a computer system. Pet. 6 (citing Ex. 1011 ¶ 8.1.2). As
an illustration, Petitioner describes a flight reservation system that has objects
representing airports, planes, and seats on particular flights. Id. at 6–7. This
aids computer programmers to develop a computer system, because
programmers are able to think “in terms of the properties and functions of a
relevant object (e.g., does this plane, for this flight, have any unsold seats),”
rather than being concerned with “lower-level technical details about how the
program works.” Id. at 7 (citing Ex. 1011 ¶ 8.1.2). Patent Owner’s declarant
Sam Malek, Ph.D. similarly testifies regarding objects in object-oriented
programming. Ex. 2001 ¶ 23; see also PO Resp. 10–11 (summary of the ’862
patent).
Specifically, the ’862 patent relates to “a system, methods and software
for creating or maintaining distributed transparent persistence of complex data
objects and associated data stores.” Ex. 1001, col. 1, ll. 14–17. The ’862 patent
addresses the problem of “persisting” data used by object-oriented programs in

7 MICROSOFT COMPUTER DICTIONARY 373 (5th ed. 2002) (defining “object-
oriented programming” as “[a] programming paradigm in which a program is
viewed as a collection of discrete objects that are self-contained collections of
data structures and routines that interact with other objects”); see also Ex. 1011
¶ 4.1 (Declaration of Antony L. Hosking); Ex. 2001 ¶ 23 (Declaration of Sam
Malek, Ph.D.).
IPR2014-00119
Patent 7,167,862 B2

5
a distributed computer environment in which information needed to persist, or
store, the data objects may be found in different computer systems. See id. at
col. 1, ll. 46–51.
D. Illustrative Claim of the ’862 Patent
Claim 1 of the ’862 patent is the only challenged independent claim and
recites the following:
1. A system for creating or maintaining transparent
persistence of a member selected from the group consisting of a
data object, an object graph model and a portion of an object graph
model when a user of the system is creating, maintaining,
accessing or navigating complex data objects as a complex data
object graph model, comprising:
a) a set of definitions for the relationships between a data
source schema and objects capable of storing data for an object
language application, wherein the set of definitions is stored in a
repository;
b) a set of definitions for the relationships between objects
for an object language application, wherein the set of definitions is
part of an object application navigation model;
c) a list of objects, or a set of objects that are to be persisted,
wherein the list of objects or set of objects is part of an object
application navigation model;
d) an object or set of objects as part of a computer
implemented method that contains the computer logic capable of
persisting an indicated object or set of objects;
e) an input method to provide the computer logic of d) with
data corresponding to the location of information related to a), b)
and c), and
f) at least one data source to in which persisted data may be
stored,
wherein said system further comprises a compiled or programming
language software logic object code routine or set of object code
IPR2014-00119
Patent 7,167,862 B2

6
routines stored in a permanent medium or in a computer system
memory for a computer implemented method providing a user the
[sic] with the ability and method to query against an object graph,
a complex data object graph or a portion thereof using an object
query facility or syntax.
Id. at col. 37, ll. 2–34.
II. ANALYSIS
A. Claim Construction
In an inter partes review, claim terms in an unexpired patent are
interpreted according to their broadest reasonable construction in light of the
specification of the patent in which they appear. 37 C.F.R. § 42.100(b); see
Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14,
2012); In re Cuozzo Speed Techs., LLC, 778 F.3d 1271, 1279–82 (Fed.
Cir. 2015). Under the broadest reasonable construction standard, claim terms
are presumed to be given their ordinary and customary meaning as would be
understood by one of ordinary skill in the art in the context of the entire
disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007).
An inventor may provide a meaning for a term that is different from its ordinary
meaning by defining the term in the specification with reasonable clarity,
deliberateness, and precision. In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir.
1994).
We construe the claim language below in accordance with these
principles. No other terms require express construction.
IPR2014-00119
Patent 7,167,862 B2

7
1. “transparent persistence”
A central dispute between the parties concerns “transparent persistence,”
despite the fact that none of the elements in the body of any of the challenged
claims recite that term. Although the inventor did not provide a definition of
transparent persistence, the inventor provided a definition of distributed
transparent persistence in the Specification of the ’862 patent. See Ex. 1001,
col. 3, ll. 43–49 (indicating each defined term is to be given the meaning
ascribed to it in the list of definitions), col. 5, ll. 40–46 (defining distributed
transparent persistence). Distributed transparent persistence is defined as “a
term employed herein as an abstraction referring to the concept of providing
persistence for a member selected from the group consisting of a data object, a
data object graph, associated data and data object relationships in a distributed
environment without the need for the insertion of byte code or data objects in an
object model or schema.” Ex. 1001, col. 5, ll. 40–46 (emphasis added). The
inventor provided a meaning for distributed transparent persistence with
sufficient clarify, deliberateness, and precision to define the term. See Paulsen,
30 F.3d at 1480. Other than being required to be within a distributed
environment, it follows that transparent persistence would mean the same thing
as distributed transparent persistence.
As Patent Owner indicates, the Specification of the ’862 patent
consistently references the invention as providing transparent persistence—and
often, distributed transparent persistence—including in the title of the ’862
patent, the “Field of the Invention” section, the “Summary of the Invention”
section, and the Abstract. See Ex. 1001, Title, col. 1, ll. 14–17 (stating “the
IPR2014-00119
Patent 7,167,862 B2

8
present invention relates to a system, methods and software for creating or
maintaining distributed transparent persistence of complex data objects and
associated data stores”), col. 6, ll. 59–62 (stating “[a]n object of the present
invention is to provide a system for creating or maintaining transparent
persistence of a complex data object” or graph), Abstract (indicating the
“invention provides systems, methods and software for creating or maintaining
distributed transparent persistence of complex data objects and associated data
stores”).
On this basis, Patent Owner contends that the recitation of “transparent
persistence” in the preamble is a limiting element of the claims. PO Resp. 14–
15. Petitioner disagrees. Reply 1–2.
“In general, a preamble limits the invention if it recites essential structure
or steps, or if it is ‘necessary to give life, meaning, and vitality’ to the claim.”
Catalina Mktg. Int’l, Inc. v. Coolsavings.com, Inc., 289 F.3d 801, 808 (Fed. Cir.
2002). A preamble, however, “generally is not limiting when the claim body
describes a structurally complete invention such that deletion of the preamble
phrase does not affect the structure or steps of the claimed invention.” Id. at
809. One guidepost for determining the effect of a preamble on claim scope is
whether the preamble language provides antecedent basis for any limitation in
the body of the claim. Id. at 808. Moreover, a preamble describing the purpose
or intended use of an invention generally does not limit the claim. Id. at 809.
The elements recited in the body of claim 1—three sets of information in
elements (a), (b), and (c); a computer-implemented method in element (d); an
input method in element (e); a data source in element (f); and a software logic
IPR2014-00119
Patent 7,167,862 B2

9
object code routine—do not rely on the preamble language as an antecedent
basis for any limitation in the body of the claim. Few of the recited elements of
the system use antecedent basis to create connections between the recited
elements. For example, none of the information recited in elements (a), (b), and
(c) use antecedent basis to describe relationships with other information recited
in the elements (a), (b), or (c), or use antecedent basis to describe relationships
with the object (or set of objects) recited in element (d). Nor does claim 1
require any of the objects, which are in the list of objects (or set of objects) to
be persisted (recited in element (c)), to be related to any of the objects capable
of storing data identified in the definitions for relationships (recited in
element (a)), the data source to which persisted data may be stored (recited in
element (f)), or the software logic object code for providing a user with the
ability to query.
Further, claim 1 does not require the object (or set of objects) as part of a
computer-implemented method that contains the computer logic capable of
persisting an indicated object or set of objects (as recited in element d), to be
capable of persisting a particular type of object, such as an object capable of
storing data for an object language application (as recited in element (a)). In
another example, the object application navigation models recited in
elements (b) and (c) are not necessarily the same object application navigation
model because elements (b) and (c) each recite “an object application
navigation model” (emphasis added). The input method recited in element (e),
however, provides the computer logic of element (d) with the locations of the
information recited in other elements of claim 1. Even so, because claim 1 does
IPR2014-00119
Patent 7,167,862 B2

10
not define relationships among many of the information and objects recited in
the claim, the scope of claim 1 is broader than it would be if the claim recited
such relationships.
Turning again to whether the preamble is limiting, the intended use of the
invention “for creating or maintaining transparent persistence of a member
selected from the group consisting of a data object, an object graph model and a
portion of an object graph model when a user of the system is creating,
maintaining, accessing or navigating complex data objects as a complex data
object graph model” does not recite essential structure to complete the invention
recited in elements (a)–(f) or the software logic object code routine recited in
the wherein clause of claim 1. See Pitney Bowes, Inc. v. Hewlett-Packard Co.,
182 F.3d 1298, 1305 (Fed. Cir. 1999) (if the body of the claim fully and
intrinsically sets forth all the limitations of the claimed invention, and the
preamble merely states, for example, the purpose or intended use of the
invention, then the preamble is not considered a limitation and is of no
significance to claim construction). Rather, the preamble describes an intended
use (i.e., “creating or maintaining transparent persistence”) under certain
conditions (i.e., “when a user of the system is creating, maintaining, accessing
or navigating complex data objects as a complex data object graph model”).
The centrality of transparent persistence to the invention provides
evidence that the scope of the claims as a whole relates to transparent
persistence. Cf. Trading Techs. Int’l, Inc. v. eSpeed, Inc., 595 F.3d 1340, 1353–
54 (Fed. Cir. 2010) (concluding that specification’s “reference to ‘the present
invention’ strongly suggests” that the claim carries the same meaning).
IPR2014-00119
Patent 7,167,862 B2

11
Moreover, claims in an unexpired patent are construed according to their
broadest reasonable construction in light of the specification of the patent in
which they appear. 37 C.F.R. § 42.100(b); Cuozzo, 778 F.3d at 1279–82.
Although the elements in the body of claim 1 do not recite expressly
“transparent persistence,” claim 1 requires storing, in a repository, definitions
for the relationships between a data source schema and objects capable of
storing data, which is “an essential requirement for achieving transparent
persistence,” according to Patent Owner’s declarant Dr. Malek (Ex. 2001 ¶ 48);
see Ex. 1001, col. 37, ll. 8–11 (claim 1, element (a)). Second, claim 1 twice
recites an object application navigation model, which is another important
element in transparent persistence. See Ex. 2001 ¶ 49 (Dr. Malek testifying that
the invention discloses an object application navigation model used to
determine the list of objects that should be persisted to a database); Ex. 1001,
col. 37, ll. 15–16, 18 (claim 1, elements (b), (c)). Because aspects of
transparent persistence are recited expressly in the body of claim 1, the concept
of transparent persistence is present in the claim body; therefore, the preamble
is not “necessary to give life, meaning, and vitality” to the claim.
Moreover, the general concept of creating or maintaining transparent
persistence was known at least as early as November 2001, sixteen months
before the effective filing date of the application that issued as the ’862 patent.
An article by Sun Microsystems described one of Patent Owner’s CocoBase
products in November 2001 as providing “dynamic transparent persistence” to
allow a software programmer “to persist relational data with a simple, non-
invasive . . . object” and “[w]ithout any byte code or object model intrusion.”
IPR2014-00119
Patent 7,167,862 B2

12
Ex. 1016, 2. The article further indicates that “the object is unaware of the data
structure used to persist it.” Id. This further supports our determination that the
preamble is not “necessary to give life, meaning, and vitality” to the claim.
Reading the claim as a whole and applying the broadest reasonable
construction of the claim language in light of the Specification, we conclude
that the “creating or maintaining transparent persistence” language in the
preamble of claim 1 is not a limitation. Accordingly, we hold that claim 1 does
not preclude the insertion of byte code or data objects in an object model or
schema, which are features of transparent persistence. Notably, claim 5, which
depends from claim 1, additionally recites that the system “does not require any
modifications to an object model or the inclusion of any persistence byte code
in the object model in order to provide persistence for all or a portion of the
complex data object graph model or to permit object querying thereof.”
2. “object”
Independent claim 1 recites “objects capable of storing data for an object
language application,” “objects for an object language application,” “objects
that are to be persisted,” “objects [that are] part of an object application
navigation model,” and “objects [that are] part of [a certain type of] a computer
implemented method.” The ’862 patent sets forth a definition for an “object”:
“Object” as used in the context of this document is a general
term referring to a logic unit in a computer application or a
computer software program where the application or program is
based upon an object[-]oriented programming language (e.g.,
Java). The term “object” may ordinarily be used interchangeably
with the term “class” as a template or as an instance depending on
the context.
IPR2014-00119
Patent 7,167,862 B2

13
Ex. 1001, col. 3, l. 63–col. 4, l. 2; see also id. at col. 3, l. 43–col. 6, l. 55
(section titled “Definitions”). Dr. Hosking explains the difference between an
object class and an object instance in an object-oriented application for a flight
reservation system:
Using object-oriented programming languages, programmers
create[] “classes[,]” which are templates for real world entities
such as “planes” or “people.” From these classes, programmers
could create particular “objects,” such as “a plane with serial
number ‘123’ belonging to [a particular] airline”. . . or “a person
with a [particular name] and [telephone number].”
[A] Plane class may define . . . all instances of that class (the various
plane objects) . . . .
Ex. 1011 ¶¶ 4.1–4.2.
Based on the definition in the Specification and supported by
Dr. Hosking’s testimony, Petitioner proposes that the term “object” should be
construed as “either a template or an instance.” Pet. 8 (citing Ex. 1011 ¶ 8.5.3).
Although we agree that an object, by its definition in the Specification, can be a
class as a template or an instance, Petitioner’s proposed construction places
insufficient weight on other aspects of the definition of “object” in the
Specification.
For these reasons, in the Decision to Institute, we construed “object” as
“a logic unit in a computer application or a computer software program based
on an object-oriented programming language (e.g., Java) in which, depending
on context, the logic unit refers either to an instance or to a class as a template.”
Inst. Dec. 9–11. Patent Owner agrees with this construction. PO Resp. 12.
Petitioner does not challenge this construction. See generally Reply 1–3.
IPR2014-00119
Patent 7,167,862 B2

14
Having considered whether the construction set forth in the Decision to
Institute should be changed in light of evidence introduced during trial, we are
not persuaded that any modification is necessary. Therefore, we maintain the
construction of “object” as “a logic unit in a computer application or a computer
software program based on an object-oriented programming language (e.g.,
Java) in which, depending on context, the logic unit refers either to an instance
or to a class as a template.”
3. “data source schema”
Independent claim 1 recites “a set of definitions for the relationships
between a data source schema and objects capable of storing data for an object
language application.” In its Description of the Invention section, the ’862
patent substantially repeats the claim language and also indicates definitions
may be created for “the relationships between a data source schema and its
stored data to objects in a[n] object language application.” Ex. 1001, col. 10,
ll. 32–35, col. 11, ll. 11–13. Nor does the ’862 patent set forth a definition of
“data source schema.” The ’862 patent, however, does set forth a definition for
an “object schema”:
“Object schema” is a term employed herein as an abstraction
referring to the set of data object classes that describe the possible
data objects that can be created, modified or maintained in an
application, or describing an instance of a set of data object classes
in an application.
IPR2014-00119
Patent 7,167,862 B2

15
Ex. 1001, col. 5, ll. 35–39. The ordinary meaning of the term “schema” is “[a]
logical description of the data in a database, including definitions and
relationships of data.”8
In the Decision to Institute, we construed “a data source schema,” in light
of the Specification and the ordinary meaning of the term “schema,” as “an
abstraction describing data in a database used as a source of data in an
application.” Dec. Inst. 11–12. Patent Owner agrees with this construction.
PO Resp. 17. Petitioner does not challenge this construction. See generally
Reply 1–3.
Having considered whether the construction set forth in the Decision to
Institute should be changed in light of evidence introduced during trial, we are
not persuaded that any modification is necessary. Therefore, we maintain the
construction of “a data source schema” as “an abstraction describing data in a
database used as a source of data in an application.”
4. “object application navigation model”
Independent claim 1 recites “the set of definitions is part of an object
application navigation model” in element (b) and “the list of objects or set of
objects is part of an object application navigation model” in element (c). Thus,
claim 1 only indicates expressly an object application navigation model
includes information specified in elements (b) and (c). Further, by reciting “an
object application navigation model” in each element (b) and (c), claim 1 does

8 MCGRAW-HILL DICTIONARY OF SCIENTIFIC AND TECHNICAL TERMS 1864 (6th
ed. 2003).
IPR2014-00119
Patent 7,167,862 B2

16
not require the set of definitions in element (b) and the list of objects or set of
objects in element (c) necessarily are part of the same object application
navigation model.
The ’862 patent does not define the precise term “object application
navigation model.” The Specification, however, defines a “navigation model”:
a special type of application model that is applied specifically to a
description (or other representation) of how objects can relate to
each other and what might be the expected behavior when a
[complex data object graph] is navigated for a certain purpose.
Ex. 1001, col. 5, ll. 30–34. According to the ’862 patent, a “complex data
object graph” is “an abstraction to logically represent a set of complex data
objects and a set of their corresponding relationships.” Ex. 1001, col. 4, ll. 57–
60. In turn, the ’862 patent defines a “complex data object”:
a data object that has at least one or more relationships with itself,
or at least one or more relationships with one or more other data
object(s). In a given instance of a [complex data object] at least
one relationship is populated as a link, as defined below. A
[complex data object] may have a multiplicity of different
relationships with itself or with one or more additional [complex
data objects].
Ex. 1001, col. 4, ll. 14–21. The ’862 patent, in turn, defines “link” in the
context of a complex data object:
identif[ying] a particular occurrence of a relationship between a
[complex data object] and itself, between a [complex data object]
and another [complex data object]. The occurrence of at least one
populated link results in an instance of a [complex data object].
This may be considered as a synonym for a ‘relationship’ between
two objects.
Id. at col. 4, ll. 41–46.
IPR2014-00119
Patent 7,167,862 B2

17
According to the ’862 patent, then, a “navigation model” is a model
describing how objects relate to one another and the expected behavior when a
complex data object graph is navigated for a certain purpose; “a complex data
object graph” is an abstraction of an object that has one or more relationships
with itself or another object; and a “relationship” is populated as a link between
two objects or an object with itself.
For these reasons, in the Decision to Institute, we construed an “object
application navigation model” as “a model describing how two objects in an
application relate to themselves or one another, and the expected behavior when
relationships, populated as a link between the objects or as a link with itself, are
navigated for a certain purpose.” Dec. Inst. 12–13.
Petitioner does not challenge this construction. See generally Reply 1–3.
Based on Dr. Malek’s testimony, Patent Owner, although agreeing that this
construction is correct, further contends that an object application navigation
model also is distinct from a data object graph that “shows data objects as the
edges and relationships as the nodes.” PO Resp. 15–16 (citing Ex. 2001 ¶¶ 67,
68, 70). Patent Owner contends that claim 1 precludes an object application
navigation model to be a data object graph because claim 1 recites “the
expected behavior when relationships . . . are navigated for a certain purpose.”
Id.
Contrary to Patent Owner’s arguments, an object application navigation
model does not have to be distinct from a graph that shows objects as the edges
and relationships as the nodes and that holds application data. See PO
Resp. 15–16 (arguing a graph of the data objects that hold application data is
IPR2014-00119
Patent 7,167,862 B2

18
not an object application navigation model); Ex. 2001 ¶ 68 (testifying “the
object application navigation model is distinct from a graph of data objects that
hold the data within an application”). A navigation model by the
Specification’s express definition is a model describing how two objects relate
to one another. A graph showing objects as the edges and relationships as the
nodes is one way to describe how objects relate to one another and, therefore,
should not be excluded. The express definition does not preclude objects that
hold application data.
Moreover, Patent Owner’s contention does not explain sufficiently how
an “object application navigation model” recited in the claims (emphasis
added) is different from the “navigation model” defined in the Specification
(Ex. 1001, col. 5, ll. 30–34). Patent Owner’s contention does not place
sufficient weight on “object application” in the term “object application
navigation model.” Moreover, claim 1 itself recites “a set of objects is part of
an object application navigation model,” which indicates objects may be
included as part of an object application navigation model. In requiring a set of
objects, claim 1 expressly allows object instances to be part of an object
application navigation model, in view of the construction of “object” as
referring either to an instance or a class depending on context, which further
undermines Patent Owner’s contentions that an object application navigation
model is distinct from “a graph of data objects that hold data within an
application.” See § II.A.2 (construction of object).
Nor are we persuaded by Patent Owner’s reliance on examples from the
Specification that disclose multiple navigation models may be provided for the
IPR2014-00119
Patent 7,167,862 B2

19
same complex data object graph (PO Resp. 16 (citing Ex. 1001, col. 12, ll. 47–
54, col. 13, ll. 46–47)). The Specification’s examples are from particular
implementations—the CDOG Navigator API and the CocoNavigator API.
See Ex. 1001, col. 12, ll. 47–54 (“Each CDOG (or CDOG model) managed by
the CDOG Navigator API (or CBFacade) can be associated by the CDOG
Navigator API (or CBFacade) with a CDOG descriptor (such as a file) that may
be utilized to represent all or part of a ‘navigation model’.”); id. at col. 13,
ll. 42–52 (“Some preferred features provided by the CocoNavigator API . . . are
as follows: . . . [a] preferred embodiment of the CocoNavigator API or an
associated program module is configured to allow many navigation models to
be used with the same set of java classes and CocoBase maps that are
associated with a CDOG model.”).
We decline to read limitations into a claim even from a preferred
embodiment described in the Specification. See In re Am. Acad. of Sci. Tech
Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). Moreover, the examples refer to
“the navigation model,” rather than the recited “object application navigation
model.”
Weighing Dr. Malek’s testimony supporting Patent Owner’s contention
that an object application navigation model also is distinct from a data object
graph that “shows data objects as the edges and relationships as the nodes” (PO
Resp. 16 (citing Ex. 2001 ¶¶ 67, 68, 70)) against the evidence of the written
description and claim 1, we do not agree that an object application navigation
model necessarily must be separate from a data object graph. It is within our
discretion to assign the appropriate weight to the testimony offered by
IPR2014-00119
Patent 7,167,862 B2

20
Dr. Malek. See, e.g., Yorkey v. Diab, 601 F.3d 1279, 1284 (Fed. Cir. 2010)
(holding the Board has discretion to give more weight to one item of evidence
over another “unless no reasonable trier of fact could have done so”); Am. Acad.
of Sci. Tech Ctr., 367 F.3d at 1368 (“[T]he Board is entitled to weigh the
declarations and conclude that the lack of factual corroboration warrants
discounting the opinions expressed in the declarations.”).
Thus, we have insufficient evidence before us that one of ordinary skill in
the art would consider “an object application navigation model” to be distinct
from a data object graph. Likewise, neither claim 1 nor the written description
of the ’862 patent clearly requires “an object application navigation model” to
be distinct from a data object graph. Accordingly, we maintain the construction
of an “object application navigation model” as “a model describing how objects
in an application relate to themselves or one another, and the expected behavior
when relationships, populated as a link between the objects or as a link with
itself, are navigated for a certain purpose.”
5. “byte code”
Claim 5, which depends from claim 1, recites “does not require . . . the
inclusion of any persistence byte code in the object model.” The ’862 patent
does not set forth a definition of the term “byte code.”
One of ordinary skill in the art at the time of the invention would have
understood the term “byte code” to mean compiled Java programs that can be
IPR2014-00119
Patent 7,167,862 B2

21
transferred across a network and executed by the Java virtual machine.9 The
’862 patent’s use of “byte code” is consistent with its ordinary meaning. For
example, the ’862 patent indicates an aspect of the invention is an object model
that does not include a certain type of “byte code.” See Ex. 1001, col. 1, ll. 42–
46, col. 3, ll. 22–26, col. 5, ll. 40–46 (distributed transparent persistence of data
objects provided without inserting any byte code), col. 18, ll. 46–48 (distributed
transparent persistence of data objects provided without byte code
modification).
For these reasons, in the Decision to Institute, we construed “byte code”
as “a compiled Java program that can be transferred across a network and
executed by the Java virtual machine.” Dec. Inst. 13–14. Patent Owner agrees
with this construction. PO Resp. 12. Petitioner does not challenge this
construction. See generally Reply 1–3. Having considered whether the
construction set forth in the Decision to Institute should be changed in light of
evidence introduced during trial, we are not persuaded that any modification is
necessary. Therefore, we maintain the construction of “byte code” as “a
compiled Java program that can be transferred across a network and executed
by the Java virtual machine.”
B. Principles of Law
To prevail in challenging claims 1, 2, 4, and 5 of the ’862 patent,
Petitioner must demonstrate by a preponderance of the evidence that the claims

9 MCGRAW-HILL DICTIONARY OF SCIENTIFIC AND TECHNICAL TERMS 305 (6th
ed. 2003) (defining “byte code”).
IPR2014-00119
Patent 7,167,862 B2

22
are unpatentable. 35 U.S.C. § 316(e); 37 C.F.R. § 42.1(d). A claim is
unpatentable under 35 U.S.C. § 103(a) if the differences between the claimed
subject matter and the prior art are such that the subject matter, as a whole,
would have been obvious at the time the invention was made to a person having
ordinary skill in the art to which said subject matter pertains. KSR Int’l Co. v.
Teleflex Inc., 550 U.S. 398, 406 (2007). The question of obviousness is
resolved on the basis of underlying factual determinations including the
following: (1) the scope and content of the prior art; (2) any differences
between the claimed subject matter and the prior art; (3) the level of ordinary
skill in the art; and (4) objective evidence of nonobviousness. Graham v. John
Deere Co., 383 U.S. 1, 17–18 (1966).
C. Level of Ordinary Skill in the Art
The level of ordinary skill in the art is relevant to the governing standards
we apply in the rest of our analysis. The person of ordinary skill in the art is a
hypothetical person who is presumed to have known the relevant art at the time
of the invention. In re GPAC, Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995).
Factors that may be considered in determining the level of ordinary skill in the
art include, but are not limited to, the types of problems encountered in the art,
the sophistication of the technology, and educational level of active workers in
the field. Id. In a given case, one or more factors may predominate. Id.
Relying on the testimony of Dr. Hosking, Petitioner contends a person of
ordinary skill in the art would have been a person with a Master of Science
degree in computer science, electrical engineering, or a related field, and at least
IPR2014-00119
Patent 7,167,862 B2

23
three years of working experience in software development, database design, or
a related technology. Pet. 7 (citing Ex. 1011 ¶ 8.3.2).
Relying on the testimony of Dr. Malek, Patent Owner contends a person
of ordinary skill in the art would have been a person with a Bachelor of Science
degree in computer science or a related field, and at least two or three years of
experience working in software development, distributed systems, database
design, or a related technology. PO Resp. 12 (citing Ex. 2001 ¶ 42). Patent
Owner also contends that working experience could be substituted for formal
university training. PO Resp. 12.
The parties propose similar levels of ordinary skill in the art and do not
directly challenge the other’s proposal. We consider the level of ordinary skill
in the art to be reflected by the prior art of record. See Okajima v. Bourdeau,
261 F.3d 1350, 1355 (Fed. Cir. 2001). The prior art references, like the
Specification of the ’862 patent, relate to object oriented and Java
programming. See Ex. 1001, col. 19, l. 20–col. 23, l. 36 (including various
example code excerpts); Ex. 1006 Abstract (describing invention as a Java
application); Ex. 1007 Title, xxvi (A programming guide for developing web
applications in Java titled “Java for the Web with . . . EJB”).
In general, we agree with the areas of agreement in the parties’ proposals.
Petitioner has not explained sufficiently why a graduate degree would be
necessary, and so we adopt Patent Owner’s proposed level of a Bachelor of
Science, which comports with the level of ordinary skill in the art reflected in
the prior art of record. We determine that a person of ordinary skill would have
possessed a Bachelor of Science degree in computer science (or related field,
IPR2014-00119
Patent 7,167,862 B2

24
including electrical engineering) and at least two years of experience working in
software development or database design (or a related technology, including
distributed systems), and allowing additional commensurate work experience to
substitute for formal academic training.
D. Obviousness over Demuth and Kurniawan
Petitioner contends claims 1, 2, 4, and 5 are unpatentable under
35 U.S.C. § 103(a) as obvious over the combination of Demuth and Kurniawan,
relying on declaration testimony of Dr. Hosking. Pet. 37–40 (citing Ex. 1011).
Patent Owner responds, relying on declaration testimony of Dr. Malek. PO
Resp. 20–49 (citing Ex. 2001). Having considered the parties’ contentions and
supporting evidence, we determine that Petitioner has demonstrated by a
preponderance of evidence that claims 1, 2, 4, and 5 are unpatentable for
obviousness over Demuth.
1. Summary of Demuth
Demuth describes techniques for minimizing the cost of developing
object-oriented computer applications, for instance, by using software
“containers” as computer application building blocks. Ex. 1006, Abstract,
¶¶ 2, 4. Demuth’s techniques address the problem of developing object-
oriented computer applications to run on a user’s computer. Id. at Abstract,
¶¶ 2, 19. Demuth’s solution takes advantage of computer logic available from
the application components on the server computer—specifically, on the
computer logic available from Enterprise JavaBeans (“EJB”) hosted computer
applications. Id. at Abstract. To do so, Demuth describes a “client container”
IPR2014-00119
Patent 7,167,862 B2

25
that is software that provides a web browser access to a subset of data and
programming logic that otherwise is available from an EJB application. Id. at
¶¶ 2, 5, 8. The EJB application logic provides web pages for display on a user’s
computer and provides a variety of programming infrastructure, including
handling persistence. Id.
More particularly, Demuth’s “client container” software “transparently
localizes” parts of a server-based computer application (i.e., an EJB application
running on a server computer) so that the specified portions of the application
can be accessed by the user’s computer (“client computer”) and “later re-
persisted [from the client container] to the hosting EJB container.” Id. at
Abstract; see id. at ¶ 20. The “client container” software handles the
“programming tasks associated with managing state locality for persistent
objects [and] object access” and “hand-coding” is not required. Id. at ¶ 26.
Demuth also explains that the content and structure of the object-oriented
computer application is composed, in part, of a “domain object model.” Id. at
¶ 56. Demuth notes that a domain object model is “familiar” to any person who
develops object-oriented computer applications. Id. at ¶ 68. A domain object
model is made up of multiple “enterprise java beans” or “EJBs” in an “object
graph.” Id. at ¶ 56. Demuth indicates a “domain object graph” is a giant web,
or graph, with graph nodes representing objects and with graph edges (or lines
connecting the nodes) as “navigable relations” between objects. Id.
2. Summary of Kurniawan
In general, Kurniawan’s book is a guide to Java web programming that
describes technologies for programming web applications in Java. Ex. 1007,
IPR2014-00119
Patent 7,167,862 B2

26
Title. Among other technologies, Kurniawan describes JavaServer Pages (JSP),
Enterprise JavaBeans (EJB), and the EJB Query Language (EJB QL). See Ex.
1007 at 245–350 (JSP),10 667–753 (EJB), 757–67 (EJB QL); see also id. at viii–
xiii (Table of Contents).
Kurniawan indicates that the EJB Query Language is needed for a certain
type of entity bean in which the container provides “automatic persistence.” Id.
at 757. These container-managed persistence (CMP) entity beans free the
software developers from “worry[ing] about how the entity bean’s data is
persisted.” Id. Software developers can use the EJB Query Language to select
entity objects for a query. Id. at 758.
3. Independent Claim 1
Independent claim 1 is a system claim that requires various types of
information recited in elements (a)–(d); a computer-implemented method that
includes an object (or set of objects) and computer logic for persisting an
indicated object (or set of objects); an input method to provide the computer
logic specified in the computer-implemented method with the location of
recited information; a data source in which persisted data may be stored; and
software logic object code routine for providing a user with the ability to query
using an object query facility or syntax.
In general, Petitioner asserts that Demuth’s transparent localization of
EJB container logic in the “client container” software teaches or suggests many

10 Citations to Ex. 1007 refer to page numbers in the original book, not the
exhibit page numbers added by Petitioner.
IPR2014-00119
Patent 7,167,862 B2

27
of the elements of claim 1. Pet. 37; see id. at 20–27, 30–33. Petitioner also
relies on Kurniawan’s description of the EJB Query Language and presents
reasons why one skilled in the art would have combined the references. Id. at
37–38.
The parties do not dispute that Demuth discloses lightweight
representations of an object model and lightweight objects are transported from
a server to a client, and that “changes to lightweight objects are reconciled back
to a domain object graph on the EJB server.” PO Resp. 21; see, e.g., Ex. 1006
¶ 22 (Demuth’s description of the “client container” software). Patent Owner
contends that Demuth does not teach a system for “creating or maintaining
transparent persistence” (PO Resp. 21–22, 34, 37–39) and “is directed towards
a server to client relationship” with reconciliation to a server rather than
persistence to a database (id. at 21).
For the reasons explained in more detail below, we are persuaded that
Demuth’s “client container” software that provides localization of lightweight
objects and object models with persistence of changed objects back to the
server, in combination with Kurniawan’s description of the EJB Query
Language, teaches or suggests the subject matter of claim 1 as a whole. This is
the pertinent question under 35 U.S.C. § 103(a)—whether the claimed subject
matter as a whole would have been obvious to one of ordinary skill in the art in
view of Demuth and Kurniawan, not merely whether Demuth or Kurniawan
discloses the subject matter of each element of claim 1 individually. See
In re Keller, 642 F.2d 413, 425 (CCPA 1981) (“the test [for obviousness] is
IPR2014-00119
Patent 7,167,862 B2

28
what the combined teachings of the references would have suggested to those of
ordinary skill in the art”).
Patent Owner’s contentions regarding Demuth unduly focus on specific,
isolated capabilities described in Demuth without addressing what those
capabilities would have suggested to one of ordinary skill in the art at the time
of the invention of the ’862 patent or what the combination of Demuth and
Kurniawan would have suggested to one of ordinary skill in the art at the time
of the invention of the ’862 patent. Further, Patent Owner’s contentions in
large measure amount to attacks on the individual elements of claim 1, without
sufficient consideration of what the disclosure of Demuth would have suggested
to one of ordinary skill in the art regarding the claimed subject matter as a
whole, which is an approach we find unpersuasive. Indeed, many of Patent
Owner’s contentions are more appropriate to a ground of anticipation, which
requires a prior art reference to disclose, expressly or inherently, every
limitation of the claim as arranged in the claim, Net MoneyIN, Inc. v.
VeriSign, Inc., 545 F.3d 1359, 1369 (Fed. Cir. 2001), rather than a ground of
obviousness, which requires an analysis of whether the differences between the
claimed subject matter and the prior art are such that the subject matter, as a
whole, would have been obvious at the time the invention was made to a person
having ordinary skill in the art to which said subject matter pertains, 35 U.S.C.
§ 103(a). Notably, we instituted on Petitioner’s asserted ground of obviousness
over Demuth, not on Petitioner’s asserted ground of anticipation by Demuth.
Inst. Dec. 8 (identifying anticipation by Demuth as an asserted ground), 27
(Order instituting inter partes review for claims 1, 2, 4, and 5 based on
IPR2014-00119
Patent 7,167,862 B2

29
obviousness over Demuth and Kurniawan and based on obviousness over
Demuth, Kurniawan, and Chow). Further, the challenged claims, when
properly construed, do not require creating or maintaining transparent
persistence, for the reasons explained in § II.A.1 or a database for the reasons
explained below.
Accordingly, we find that Petitioner has shown by a preponderance of
evidence that the combination of Demuth and Kurniawan teaches or suggests all
the claim elements and has articulated sufficient reasoning for the conclusion of
obviousness. For the reasons explained below, we are not persuaded by Patent
Owner’s arguments to the contrary. See PO Resp. 20–49.
Element (a)—a set of definitions for the relationships between a data source
schema and objects capable of storing data for an object language application,
wherein the set of definitions is stored in a repository
The combination of Demuth and Kurniawan teaches or suggests
element (a)—“a set of definitions for the relationships between a data source
schema and objects capable of storing data for an object language application,
wherein the set of definitions is stored in a repository.” Pet. 20–22, 31
(Petitioner asserting the same). Demuth describes an EJB container that
includes application logic and data access logic. Ex. 1006 ¶ 47. In particular,
Demuth describes “data objects responsible for accessing data and presenting a
view of the data,” which are called “entity beans.” Id. at ¶ 48. “The EJB
container loads the appropriate entity beans [and] maps the entity beans to the
database” using various enumerated techniques. Id. at ¶ 51.
IPR2014-00119
Patent 7,167,862 B2

30
Demuth’s mapping of an entity bean (which is an object responsible for
accessing data and presenting a view of the data) to a database discloses “a set
of definitions for the relationships between a data source schema and objects
capable of storing data for an object language application,” as recited in
claim 1. Pet. 22. We also credit the testimony of Petitioner’s declarant,
Dr. Hosking, that the mapping of an entity bean to a database in Demuth
discloses a set of definitions for the relationships between a data source schema
and objects capable of storing data. Id. (citing Ex. 1011 ¶ 10.3.2.2.2).
Being mindful of the constructions of “a data source schema” as “an
abstraction describing data in a database used as a source of data in an
application” and the construction of “object” as “a logic unit in a computer
application or a computer software program based on an object-oriented
programming language (e.g., Java) in which, depending on context, the logic
unit refers either to an instance or to a class as a template,” we determine
Demuth’s mapping of an entity bean to a database teaches or suggests “a set of
definitions for the relationships between a data source schema and objects
capable of storing data for an object language application,” as recited in
claim 1.
Relying on Dr. Hosking’s testimony, Petitioner also contends that storing
Demuth’s definitions in a repository, as required by claim 1, would have been
obvious to one of ordinary skill in the art, who would have done so to enable
the relationships to be retrieved later. Pet. 31 (citing Ex. 1011 ¶ 10.3.3.3.2).
Patent Owner, challenging Petitioner’s position, contends that Demuth’s set of
definitions for the relationships between a data source schema and objects are
IPR2014-00119
Patent 7,167,862 B2

31
stored within the EJBs or objects, rather than being stored within a repository,
and contends storing the relationships in a repository would not have been
obvious. PO Resp. 24–26 (citing Ex. 2001 ¶¶ 89–90). Patent Owner’s
declarant Dr. Malek testifies that “[n]othing in Demuth suggests departing from
storing the connection information in the EJBs.” Ex. 2001 ¶ 90.
We credit Dr. Hosking’s testimony over that of Dr. Malek, because
Dr. Malek does not address persuasively Dr. Hosking’s testimony that storing
Demuth’s definitions in a repository to enable the relationships to be retrieved
later would have been obvious. It is within our discretion to assign the
appropriate weight to the testimony offered by Dr. Malek and Dr. Hosking.
See, e.g., Yorkey, 601 F.3d at 1284; Am. Acad. of Sci. Tech Ctr., 367 F.3d at
1368.
Moreover, Demuth plainly teaches software (i.e., the EJB container) that
maps entity beans to a database, which teaches the recited relationships to be
stored in a repository. Patent Owner has not provided persuasive evidence how
a person of ordinary skill in the art would understand the term “repository” to
be a particular type of storage that would preclude storage of the relationships
in Demuth’s software container, as Demuth teaches. Further, Petitioner’s
combination that stores relationships in a repository would predictably use
known elements (i.e., a repository) according to established functions (i.e., to
store data), rendering a predictable result of storing the relationships in a
repository, rather than in Demuth’s software container. See KSR, 550 U.S. at
416 (“The combination of familiar elements according to known methods is
likely to be obvious when it does no more than yield predictable results.”);
IPR2014-00119
Patent 7,167,862 B2

32
Ex. 1013 ¶ 6.3.3 (Dr. Hosking testifying that storing definitions in a repository
applies a known technique to yield predictable results).
Although Patent Owner contends Demuth does not teach element (a),
Patent Owner does not address adequately the question of what the storage of
Demuth’s relationships in a software container would have suggested to one of
ordinary skill in the art. Cf. Keller, 642 F.2d at 425. For these reasons, we
determine that the combination of Demuth and Kurniawan teaches or suggests
element (a).
Element (b)— a set of definitions for the relationships between objects for an
object language application, wherein the set of definitions is part of an object
application navigation model; Element (c)— a list of objects, or a set of objects
that are to be persisted, wherein the list of objects or set of objects is part of an
object application navigation model
Turning to elements (b) and (c) recited in claim 1, according to Petitioner
with support from Dr. Hosking, the relationships between objects in Demuth’s
domain object graph also teach the recited object application navigation models.
Pet. 22–24 (citing Ex. 1011 ¶¶ 10.3.2.3.2, 10.3.2.4.2). More particularly,
according to Petitioner and Dr. Hosking, Demuth’s subset of a domain object
graph discloses “a set of objects that are to be persisted, wherein the . . . set of
objects is part of an object application navigation model.” Pet. 23 (citing
Ex. 1006 ¶ 70). As noted previously, Demuth’s domain object graph includes
edges which represent relationships between objects, and Demuth’s edges are
“navigable.” Ex. 1006 ¶ 68. Demuth further provides an example of “a subset
of the domain object graph” that includes all objects needed for a user to
perform a function of the computer application, such as a user changing the tax
IPR2014-00119
Patent 7,167,862 B2

33
withholding for an employee in a Human Resources system. Ex. 1006 ¶ 70.
This teaches an example of Demuth’s domain object graph being navigated for
a certain purpose—changing the tax withholding for an employee.
Further, as Petitioner recognizes, Demuth discloses a set of objects that
are to be persisted as part of an object application navigation model, as required
by element (c). Pet. 23–24, Reply 10–12. First, Demuth discloses that the set
of objects themselves can be sent back to the server as part of persisting the EJB
container on the server. Reply 11 (citing Ex. 1013 ¶ 6.5). Demuth’s
lightweight object graph is a subset of Demuth’s domain object graph, which
discloses the recited object application navigation model, for the reasons noted
previously. Thus, we determine that Demuth teaches or suggests a set of
objects to be persisted (i.e., Demuth’s lightweight objects) that is part of the
object application navigation model (i.e., Demuth’s domain object graph), as
required by element (c).
Regarding elements (b) and (c), Patent Owner contends that Demuth does
not teach the recited object application navigation model for several reasons.
PO Resp. 27–34. First, Patent Owner contends that Demuth’s domain object
graph is a graph of the data objects that hold application data, and so does not
include a description of expected behaviors when object relationships are
navigated. Id. at 27–30. Therefore, according to Patent Owner, Demuth’s
domain object graph does not teach or suggest the recited object application
navigation model. Id. Rather, Patent Owner contends that Demuth’s domain
object graph corresponds to the complex data object graph (CDOG) described
in the Specification of the ’862 patent and so is not distinct from the CDOG as
IPR2014-00119
Patent 7,167,862 B2

34
required in order for Demuth’s domain object graph to render obvious the
claimed object application navigation model. Id. at 30–31. The fact that
Demuth’s domain object graph also may disclose the complex data object graph
described by the ’862 patent is not germane to whether Demuth’s domain object
graph discloses the recited object application navigation model. For the reasons
explained previously in § II.A.4, the recited object application navigation model
need not necessarily be separate from a data object graph and so it does not
preclude Demuth’s domain object graph from disclosing both the recited object
application navigation model and the complex data object described in the
Specification of the ’862 patent.
Patent Owner also contends that Demuth does not disclose a list of
objects or a set of objects that is part of an object application navigation model
because Demuth’s subset of a data object graph includes all of the data objects
needed to perform a particular function and is not limited to only changed
objects, as purportedly required by claim 1. PO Resp. 32. Patent Owner
acknowledges that Demuth sends back to the server for synchronization only
the objects changed on the client. Id. (citing Ex. 1006 ¶ 90). Demuth’s
changed objects are part of the subset of a data object graph, which teaches or
suggests objects being a part of an object application navigation model.
Demuth’s changed objects are sent to the server to be synchronized, which
teaches or suggests the changed objects are a set of objects to be persisted.
Accordingly, Demuth’s description that changed objects sent to the server for
synchronization teaches or suggests “a set of objects that are to be persisted
[and] the set of objects is part of an object application navigation model.”
IPR2014-00119
Patent 7,167,862 B2

35
For these reasons, we determine the combination of Demuth and
Kurniawan teaches or suggests elements (b) and (c) recited in claim 1.
Element (d)—an object or set of objects as part of a computer implemented
method that contains the computer logic capable of persisting an indicated
object or set of objects
Claim 1 also recites “an object or set of objects as part of a computer
implemented method that contains the computer logic capable of persisting an
indicated object or set of objects,” as element (d). As such, claim 1 recites two
disjunctive phrases—(i) an object or set of objects and (ii) persisting an
indicated object or set of objects. Notably, element (d) does not use antecedent
basis to connect any of the objects (or sets of objects) or the computer
implemented method to any other element recited in claim 1.
Demuth teaches or suggests element (d) recited in claim 1. Petitioner
contends Demuth’s “client container” software that “transparently localizes”
aspects of the object-oriented application on the server that are “later re-
persisted” to the server teaches or suggests the “object or set of objects,” recited
in element (d). Ex. 1006, Abstract (describing “client container” software); Pet.
23–24; Reply 12–13. Petitioner, with support from Dr. Hosking, contends
Demuth’s “client container” teaches or suggests the recited persisting computer
logic. Pet. 23–24.
Demuth’s “client container” software includes “lightweight object
models . . . created as a subset of the main domain model construed as EJBs on
the server.” Ex. 1006 ¶ 22. Figure 5 of Demuth shows a client container 512
and is set forth below:
IPR2014-00119
Patent 7,167,862 B2

36

As shown in Figure 5, Demuth’s client container 512 includes lightweight
object model 513 having lightweight objects 514, 515, 516. Id. at ¶¶ 56–57.
“The client container [software] provides lifecycle management of the
lightweight object model by providing . . . delta tracking” of changes. Id. at
¶ 22. After the lightweight object model is modified by the user, the “client
container” software “resolves back” the modified lightweight object model
“into the heavyweight object model on the server.” Id.
Thus, Demuth describes “client container” software that includes
computer logic capable of persisting a lightweight object model to the
corresponding object model on the server. Accordingly, we agree with
Petitioner that Demuth teaches or suggests an object or objects (i.e., lightweight
object models) as part of a computer implemented method (i.e., client
container) that contains computer logic capable of persisting an indicated object
or set of objects (i.e., lightweight objects). See, e.g., id. at Fig. 5.
IPR2014-00119
Patent 7,167,862 B2

37
Patent Owner contends that Demuth’s “client container” software does
not disclose the recited persisting computer logic. PO Resp. 35–37. According
to Patent Owner, Demuth’s “client container” software is not an object. Id.
at 35. Patent Owner interprets element (d) as requiring an object (or set of
objects) to contain the computer logic. Patent Owner’s narrow reading ignores
“as part of a computer method” that immediately precedes “that contains the
computer logic.” Dr. Malek’s testimony indicates an object, in object-oriented
programming, “provides encapsulation of data and operations possible on the
data.” Ex. 2001 ¶ 23. Thus, Dr. Malek’s testimony further supports the
interpretation that element (d) requires the recited “computer implemented
method” to contain the recited computer logic, which describes operations to be
performed by the method. Thus, element (d) requires the recited “computer
implemented method” to contain computer logic.
Moreover, even if element (d) requires the “object or set of objects” that
are part of the computer-implemented method to contain the computer logic,
based on Dr. Hosking’s testimony (Ex. 1013 (Rebuttal Declaration of
Dr. Hosking) ¶ 6.6.2), we find that the “client container” software containing
computer logic at least suggests an object because the “client container” is a
programming construct in an object-oriented programming paradigm. See
Reply 13 (citing Ex. 1013 ¶ 6.6).
Nor are we persuaded by Patent Owner’s contention that the computer
logic in Demuth’s “client container” software, which expressly is described as
re-persisting objects to the server, is not the persisting computer logic required
by element (d) because, according to Patent Owner, the “client container”
IPR2014-00119
Patent 7,167,862 B2

38
software “only persists objects back to the EJB container on the server” and not
to the database, as required by the claim. PO Resp. 37. As acknowledged by
Patent Owner, persisted data may be stored to a database. See, e.g., PO Resp.
40–41 (stating “one of ordinary skill in the art would understand that the
persisting computer logic refers to computer logic that stores the changed state
values back to the primary storage, i.e., the database”).
Further, Patent Owner’s arguments unduly focus on specific, isolated
capabilities described in Demuth without addressing what those capabilities
would have suggested to one of ordinary skill in the art at the time of the
invention of the ’862 patent. 35 U.S.C. § 103(a) (indicating the obviousness
inquiry is whether the claimed subject matter as a whole would have been
obvious to one of ordinary skill in the art in view of the applied prior art); cf.
Keller, 642 F.2d at 425.
For these reasons, we determine the combination of Demuth and
Kurniawan teaches or suggests element (d).
Element (e)— an input method to provide the computer logic of d) with data
corresponding to the location of information related to a), b) and c)
Claim 1 recites “an input method to provide the computer logic of d) with
data corresponding to the location of information related to a), b) and c)” as
element (e). Petitioner acknowledges that Demuth does not disclose expressly
the recited input method. Petitioner contends, however, relying on
Dr. Hosking’s testimony, that one of ordinary skill in the art would understand
that an input method would be needed to allow a user to modify Demuth’s
objects or relationships. Pet. 24–25 (citing Ex. 1011 ¶ 10.3.2.6.2–3). We find
IPR2014-00119
Patent 7,167,862 B2

39
Dr. Hosking’s testimony credible. It is within our discretion to assign the
appropriate weight to the offered testimony. See, e.g., Yorkey, 601 F.3d at
1284.
Patent Owner contends that Demuth does not disclose element (e)
because Demuth does not disclose the computer logic of element (d), which is
required by element (e). PO Resp. 39–43. For the reasons described
previously, we determine that Demuth teaches or suggests computer logic of
element (d) and so are not persuaded by Patent Owner’s contentions.
Accordingly, we determine the combination of Demuth and Kurniawan
teaches or suggests element (e).
Element (f)— at least one data source to in which persisted data may be stored
Claim 1 recites “at least one data source to in which persisted data may
be stored” as element (f). Petitioner contends Demuth teaches or suggests
element (f) because Demuth discloses the server’s EJB container may access a
database and provides persistence logic. Pet. 25–26 (citing Ex. 1009 ¶¶ 41, 51).
As acknowledged by Patent Owner, persisted data may be stored to a database.
See, e.g., PO Resp. 40–41 (stating “one of ordinary skill in the art would
understand that the persisting computer logic refers to computer logic that
stores the changed state values back to the primary storage, i.e., the database”).
Notably, element (f) does not use antecedent basis to require any of its
features to be related to any other element recited by claim 1. For instance, in
Demuth, the data source need not necessarily be a database for storing data
changed by the “client container” software.
IPR2014-00119
Patent 7,167,862 B2

40
For the foregoing reasons, we determine Demuth’s description of a server
container that accesses a database and provides persistence logic teaches or
suggests a data source to in which persisted data may be stored; therefore, the
combination of Demuth and Kurniawan teaches or suggests element (f).
a software logic object code routine providing a user . . .with the ability . . . to
query against an object graph, a complex data object graph or a portion
thereof using an object query facility or syntax
Claim 1 also recites “a software logic object code routine. . . providing a
user . . . with the ability . . . to query against an object graph, a complex data
object graph or a portion thereof using an object query facility or syntax.”
Petitioner contends that the combination of Demuth and Kurniawan teaches or
suggests the recited software logic object code routine. Pet. 38. Petitioner
specifically relies on Kurniawan’s description of the EJB Query Language and
its use by software developers discloses the routine or routines “providing a
user . . . with the ability . . . to query against an object graph, a complex data
object graph or a portion thereof using an object query facility or syntax.” Id.
Relying on Dr. Hosking’s testimony, Petitioner additionally contends that a
person of ordinary skill in the art would have used the EJB Query Language
described by Kurniawan to query against Demuth’s object graph “to at least
allow for efficient access of information from a data store.” Id. (citing Ex. 1011
¶ 10.3.4.9.2).
Kurniawan’s description of the EJB Query Language, which is used by
software developers to query against entity objects, discloses providing a user
(i.e., a software developer) an ability to query against a portion of a complex
IPR2014-00119
Patent 7,167,862 B2

41
data object graph (i.e., entity objects). We are persuaded by Dr. Hosking’s
testimony that Petitioner’s proposed combination of Kurniawan’s description of
the EJB Query Language with Demuth’s transparent localization technology
would have taught or suggested to a person of ordinary skill in the art the
recited software logic object code routine for providing the recited querying
ability. We also determine that Petitioner has articulated sufficient reasoning
with some rational underpinning to support that legal conclusion. See KSR, 550
U.S. at 418.
Accordingly, regarding the subject matter of claim 1 as a whole, we
conclude that the teachings of Demuth and Kurniawan in combination would
have suggested the subject matter of claim 1 as a whole to one of ordinary skill
in the art. We also determine that Petitioner has articulated sufficient reasoning
with some rational underpinning to support the legal conclusion that the subject
matter of claim 1 would have been obvious to one of ordinary skill in the art in
view of the teachings of Demuth and Kurniawan as combined in the manner
proposed by Petitioner. See KSR, 550 U.S. at 418.
4. Dependent Claim 2
Claim 2 depends from independent claim 1 and recites the system “the
object query facility utilizes EJB-QL query syntax or logically similar query
syntax.” For this additional limitation, Petitioner relies on Kurniawan’s
disclosure of using EJB-QL to select data. Pet. 39 (citing Ex. 1007, 758); see
also Ex. 1007, 759–67 (Chapter 31, titled “EJB Query Language”).
For the reasons discussed above regarding the recited object query
facility and because Kurniawan discloses using EJB-QL as a query facility, we
IPR2014-00119
Patent 7,167,862 B2

42
determine that the combination of Demuth and Kurniawan teaches or suggests
the additional limitation recited in claim 2.
5. Dependent Claim 4
Claim 4 depends from independent claim 1 and recites the system “the
object query facility similar to a EJB-QL query syntax and including expanded
functions not provided by EJB-QL querying” (emphasis added). Petitioner,
with support from Dr. Hosking, contends it would have been obvious to use a
syntax similar to an EJB-QL query syntax and include expanded functions not
provided by EJB-QL for efficient retrieval of data from a data store. Pet. 38
(citing Ex. 1011 ¶ 10.3.4.10.2). We are persuaded and note, as Petitioner
indicates (Pet. 39), that Kurniawan describes EJB-QL as being a language
similar to Structured Query Language (SQL). Kurniawan’s description of using
a query language (i.e., EJB-QL) that is similar to another query language (i.e.,
SQL), further supports Dr. Hosking’s position that it would have been obvious
to use a query facility with syntax similar to EJB-QL having expanded
functions.
Accordingly, we determine that the combination of Demuth and
Kurniawan teaches or suggests the additional limitation recited in claim 4.
6. Dependent Claim 5
Claim 5 depends from independent claim 1 and additionally recites the
system “does not require any modifications to an object model or the inclusion
of any persistence byte code in the object model in order to provide persistence
IPR2014-00119
Patent 7,167,862 B2

43
for all or a portion of the complex data object graph model or to permit object
querying thereof.”
For these additional limitations, Petitioner relies on the combination of
Demuth’s description that “[a]ll of the infrastructure programming tasks
associated with managing state locality for persistent objects, decoupling of
state and behavior, object access and so on, are managed by the [client]
container and do not require hand-coding” (Pet. 27–28, 39) and Kurniawan’s
description of using EJB-QL (Pet. 37–39).
Demuth’s client container software expressly manages, without hand-
coding, infrastructure tasks associated with managing state locality for
persistent objects teaches or suggests providing persistence without requiring
modifications to an object model or including of byte code in the object model,
which would require hand coding. As such, Demuth teaches or suggests the
transparent persistence required by claim 5. See § II.A (construing transparent
persistence and byte code).
Patent Owner contends that Demuth does not teach transparent
persistence, relying on Dr. Malek’s testimony. PO Resp. 46–48 (citing
Ex. 2001 ¶¶ 28, 141). Rather, according to Patent Owner, Demuth concerns “a
server to client relationship, without disclosing a means for persisting to a
database” and describes perceived shortcomings of the EJB container. Id. at 47.
We are not persuaded because Demuth’s client container software, not
the EJB container on the server, teaches or suggests transparent persistence for
the reasons discussed previously. Further, Patent Owner does not address what
IPR2014-00119
Patent 7,167,862 B2

44
these disclosures in Demuth would have suggested to one of ordinary skill in
the art.
For the foregoing reasons and the reasons discussed with regard to
claims 1, 2, and 4, we determine that the combination of Demuth and
Kurniawan teaches or suggests the additional limitations recited in claim 5.
7. Secondary Considerations
Although we have determined the combination of Demuth and
Kurniawan teaches or suggests the subject matter recited in claims 1, 2, 4,
and 5, our inquiry continues because evidence of secondary considerations,
when present, must always be considered as part of an obviousness inquiry.
Transocean Offshore Deepwater Drilling, Inc. v. Maersk Drilling USA, Inc.,
699 F.3d 1340, 1349 (Fed. Cir. 2012).
Factual inquiries for an obviousness determination include secondary
considerations based on evaluation and crediting of objective evidence of
nonobviousness. Graham v. John Deere Co., 383 U.S. 1, 17 (1966).
Notwithstanding what the teachings of the prior art would have suggested to
one with ordinary skill in the art at the time of the ’862 patent’s invention, the
totality of the evidence submitted, including objective evidence of
nonobviousness, may lead to a conclusion that the challenged claims would not
have been obvious to one with ordinary skill in the art. In re Piasecki, 745 F.2d
1468, 1471–72 (Fed. Cir. 1984). Secondary considerations may include any of
the following: long-felt but unsolved need, failure of others, unexpected
results, commercial success, copying, licensing, and praise. See Graham, 383
IPR2014-00119
Patent 7,167,862 B2

45
U.S. at 17; Leapfrog Enters., Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 1162
(Fed. Cir. 2007).
To be relevant, evidence of nonobviousness must be reasonably
commensurate in scope with the claimed invention. In re Kao, 639 F.3d 1057,
1068 (Fed. Cir. 2011) (citing In re Tiffin, 448 F.2d 791, 792 (CCPA 1971)); In
re Hiniker Co., 150 F.3d 1362, 1369 (Fed. Cir. 1998). More fundamentally, to
be accorded substantial weight, there must be a nexus between the merits of the
claimed invention and the evidence of secondary considerations. GPAC, 57
F.3d at 1580. “Nexus” is a legally and factually sufficient connection between
the objective evidence and the claimed invention, such that the objective
evidence should be considered in determining nonobviousness. Demaco Corp.
v. F. Von Langsdorff Licensing Ltd., 851 F.2d 1387, 1392 (Fed. Cir. 1988). The
burden of showing that there is a nexus lies with the Patent Owner. Id.; see
Paulsen, 30 F.3d at 1482.
Patent Owner alleges its CocoBase product embodies the features of
claim 111 and “has received widespread industry recognition and awards for its
advancements relating to transparent persistence.” PO Resp. 44. In particular,
Patent Owner identifies a WebSphere Advisor Editors’ Choice Award was
awarded to CocoBase in 2003 “specifically [for] the transparent persistence
present in claim 1.” PO Resp. 45 (citing Ex. 2004, 4). Patent Owner also

11 Although Patent Owner only contends that secondary considerations guide
against a finding that claim 1 would have been obvious over Demuth and
Kurniawan (PO Resp. 44–46), we consider Patent Owner’s objective evidence
in view of the subject matter of all challenged claims.
IPR2014-00119
Patent 7,167,862 B2

46
indicates CocoBase in 2003 was named the “Best of the Net” by About.com in
a particular category because “CocoBase does not require EJB, JDBC, or SQL
coding.” PO Resp. 45 (citing Ex. 2005, 1).
Patent Owner, however, fails to establish a nexus between the merits of
the claimed invention and the evidence of secondary considerations. Patent
Owner’s broad contentions about “transparent persistence,” which is not
required by claim 1, do not provide a sufficient connection between objective
evidence and the claimed invention, and so do not establish the requisite nexus
between the merits of the claimed invention and the evidence of secondary
considerations. Moreover, as noted previously, the general concept of creating
or maintaining transparent persistence was known at least as early as November
2001, sixteen months before the effective filing date of the application that
issued as the ’862 patent. See Ex. 1016, 2 (Sun Microsystem article describing
CocoBase in November 2001 as providing “dynamic transparent persistence” to
allow a software programmer “to persist relational data with a simple, non-
invasive . . . object” and “[w]ithout any byte code or object model intrusion.”).
See Ormco Corp. v. Align Tech., Inc., 463 F.3d 1299, 1311–12 (Fed. Cir. 2006)
(“[I]f the commercial success is due to an unclaimed feature of the device, the
commercial success is irrelevant. So too if the feature that creates the
commercial success was known in the prior art, the success is not pertinent.”);
J.T. Eaton & Co. v. Atl. Paste & Glue Co., 106 F.3d 1563, 1571 (Fed. Cir.
1997) (“asserted commercial success of the product must be due to the merits of
the claimed invention beyond what was readily available in the prior art”).
IPR2014-00119
Patent 7,167,862 B2

47
Claim 5 recites a system that “does not require any modifications to an
object model or the inclusion of any persistence byte code in the object model
in order to provide persistence for all or a portion of the complex data object
graph model.” These limitations are features of transparent persistence. The
objective evidence provided by Patent Owner, however, does not provide a
sufficient connection between objective evidence and the claimed invention—
the limitations recited in claim 5.
Patent Owner does not provide sufficient evidence that awards address
the features recited by claim 5 and, therefore, does not established the required
nexus. Accordingly, Patent Owner fails to provide sufficient credible evidence
to support its allegations of nonobviousness based on secondary considerations.
Balancing Petitioner’s evidence of obviousness against Patent Owner’s
asserted objective evidence of nonobviousness, we determine that a
preponderance of the evidence supports Petitioner’s position that claims 1, 2, 4,
and 5 would have been obvious over Demuth and Kurniawan.
8. Conclusion Regarding Obviousness of
Claims 1, 2, 4, and 5 in view of Demuth and Kurniawan
For the foregoing reasons, we determine that the subject matter recited in
each of claims 1, 2, 4, and 5 as a whole would have been obvious to one of
ordinary skill in the art in view of Demuth and Kurniawan. See 35 U.S.C.
§ 103(a). Patent Owner’s arguments in large measure amount to attacks on
Demuth’s disclosure of individual elements recited in the claims, without
sufficient consideration of whether the subject matter as a whole would have
been obvious in view of the disclosure of Demuth, what the disclosure of
IPR2014-00119
Patent 7,167,862 B2

48
Demuth suggested to one of ordinary skill in the art at the time of the invention
of the ’862 patent, and what the combined teachings of Demuth and Kurniawan
would have suggested to one of ordinary skill in the art. We have resolved the
question of obviousness based on factual determinations of (1) the scope and
content of Demuth and Kurniawan; (2) differences between the subject matter
of claims 1, 2, 4, and 5 and the teachings of Demuth and Kurniawan; (3) the
level of ordinary skill in the art; and (4) objective evidence of nonobviousness.
Graham, 383 U.S. at 17–18. We determined Petitioner’s articulated reasoning,
supported by Dr. Hosking’s testimony, why it would have been obvious to
combine Demuth and Kurniawan in the manner proposed has some rational
underpinning to support the legal conclusion of obviousness. See KSR, 550
U.S. at 418. Therefore, we determine that Petitioner has shown by a
preponderance of the evidence that the subject matter of claims 1, 2, 4, and 5 of
the ’862 patent would have been obvious to a person of ordinary skill in the art
in view of the teachings of Demuth and Kurniawan.
E. Obviousness over Demuth, Kurniawan, and Chow
Petitioner contends claims 1, 2, 4, and 5 are unpatentable under
35 U.S.C. § 103(a) as obvious over Demuth, Kurniawan, and Chow, relying on
declaration testimony of Dr. Hosking. Pet. 41–44 (citing Ex. 1011). Patent
Owner responds, relying on declaration testimony of Dr. Malek. PO Resp. 48–
53 (citing Ex. 2001). Having considered the parties’ contentions and supporting
evidence, we determine that Petitioner has demonstrated by a preponderance of
evidence that claims 1, 2, 4, and 5 are unpatentable for obviousness over
Demuth, Kurniawan, and Chow.
IPR2014-00119
Patent 7,167,862 B2

49
In general, Petitioner augments its arguments that the combination
Demuth and Kurniawan teaches or suggests the subject matter of claims 1, 2, 4,
and 5, as discussed previously, with Chow’s description of enhancements to the
EJB Query Language. Pet. 41–44. Similarly, Patent Owner relies on similar
arguments that Demuth and Kurniawan do not teach or suggest the subject
matter of claims 1, 2, 4, and 5, which we do not find persuasive for the reasons
given previously. PO Resp. 48–53.
Chow describes “a set of enhancements to the standard [EJB] Query
Language [that] further increase the overall usefulness of the Query Language.”
Ex. 1008 ¶ 9; see id. at Abstract. More particularly, Chow’s EJB Query
Language extensions reduce the number of operations needed to access a
database. See id. at ¶ 8, Abstract. According to Chow, the standard EJB Query
Language required using separate operations first to retrieve a set of EJBs, each
of which satisfies search criteria in a standard EJB Query Language query, and
then separately retrieve data fields from each retrieved EJB. See id. at ¶ 7.
Chow’s EJB Query Language extensions enable a single-step operation to
retrieve data from a data store using EJBs. Id. at Abstract. Chow’s EJB Query
Language extensions express queries in terms of “object relational constructs”
defined in an EJB deployment. Id. The queries then retrieve “data from a
[d]atabase expressed in terms of relationships defined in that EJB deployment.”
Id. Further, Chow indicates the enhancements provide efficient access to
databases and efficient retrieval of data from databases. Id.
Petitioner, with support of Dr. Hosking’s testimony, contends a reason
one skilled in the art would have combined Chow’s enhancements with the
IPR2014-00119
Patent 7,167,862 B2

50
EJB-QL query syntax (or similar syntax) “to at least allow for efficient access
of information from a data store” and “for efficient retrieval of data from
database.” Pet. 42 (citing Ex. 1011 ¶ 10.3.5.9.3); Pet. 43 (citing Ex. 1011
¶ 10.3.5.10.4). In view of Dr. Hosking’s testimony and Chow’s disclosure that
the query enhancements provide efficient access to databases and efficient
retrieval of data from databases (Ex. 1008, Abstract), we are persuaded that
Petitioner has articulated a sufficient reason with rational underpinning to
support a conclusion of obviousness in view of Petitioner’s combination of
Demuth, Kurniawan, and Chow.
Therefore, we determine that Petitioner has shown by a preponderance of
the evidence that the subject matter of claims 1, 2, 4, and 5 of the ’862 patent
would have been obvious to a person of ordinary skill in the art in view of the
teachings of Demuth, Kurniawan, and Chow.
III. CONCLUSION
Petitioner has proven by a preponderance of the evidence that claims 1, 2,
4, and 5 of the ’862 patent are unpatentable under 35 U.S.C. § 103(a) as
obvious over Demuth and Kurniawan and are unpatentable as obvious over
Demuth, Kurniawan, and Chow.
IPR2014-00119
Patent 7,167,862 B2

51
IV. ORDER
Accordingly, it is hereby
ORDERED that, based on a preponderance of the evidence, claims 1, 2,
4, and 5 of U.S. Patent No. 7,103,862 B2 are unpatentable; and
FURTHER ORDERED that, because this is a Final Written Decision, the
parties to the proceeding seeking judicial review of the decision must comply
with the notice and service requirements of 37 C.F.R. § 90.2.

For PETITIONER:
Vaibhav P. Kadaba
Steven D. Moore
Kilpatrick Townsend & Stockton LLP
wkadaba@kilpatricktownsend.com
smoore@kilpatricktownsend.com

For PATENT OWNER:
J. Warren Lytle, Jr.
Brian K. Shelton
SUGHRUE MION PLLC
jlytle@sughrue.com
bshelton@sughrue.com