Ricoh Americas Corporationv.MPHJ Technology Investments, Inc.

Patent Trial and Appeal Board

Nov 19, 2014

12328104 (P.T.A.B. Nov. 19, 2014)

Trials@uspto.gov Paper 52
Tel: 571-272-7822 Entered: November 19, 2014

UNITED STATES PATENT AND TRADEMARK OFFICE
_______________
BEFORE THE PATENT TRIAL AND APPEAL BOARD
_______________
RICOH AMERICAS CORPORATION and XEROX CORPORATION,
Petitioner,

v.

MPHJ TECHNOLOGY INVESTMENTS, LLC,
Patent Owner.
_______________
Case IPR2013-00302
Patent 7,986,426 B1
_______________

Before MICHAEL P. TIERNEY, KARL D. EASTHOM, and
GREGG I. ANDERSON, Administrative Patent Judges.

EASTHOM, Administrative Patent Judge.

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

IPR2013-00302
Patent 7,986,426 B1

2

I. INTRODUCTION
Petitioner, Ricoh Americas Corporation and Xerox Corporation, filed a
Petition requesting an inter partes review of claims 1–11 of U.S. Patent No.
7,986,426 B1 (“’426 Patent”). Paper 1 (“Pet.”). Patent Owner, MPHJ Technology
Investments, LLC, did not file a Preliminary Response, and we instituted inter
partes review of claims 1–11, on two grounds of unpatentability, as listed below.
See Paper 8 (“Dec. on Inst.”).
Subsequent to institution, Patent Owner filed a Substitute Patent Owner
Response (Paper 30, “PO Resp.”), and Petitioner filed a Reply (Paper 39, “Pet.
Reply”). Substantively, Petitioner relies on a declaration by Dr. Roger Melen
(Ex. 1008), and Patent Owner relies on a declaration by Mr. Glenn E. Weadock
(Ex. 2002). The parties requested and appeared at an oral hearing before the panel,
which transpired on August 18, 2014. The record includes a transcript of the
hearing. Paper 51 (“Tr.”).
We have jurisdiction under 35 U.S.C. § 6(c). This Final Written Decision,
issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73, addresses issues and
arguments raised during trial.
For the reasons that follow, we determine that Petitioner has met its burden
of proving, by a preponderance of the evidence, that claims 1–5 and 7–11of the
’426 Patent are unpatentable. Petitioner, however, has not demonstrated by a
preponderance of the evidence that claim 6 of the ’426 Patent is unpatentable.
A. Related Proceedings
According to Petitioner, the ’426 Patent is involved in a declaratory
judgment action, Engineering & Inspection Services, LLC v. IntPar, LLC, No. 13-
0801 (E.D. La., Oct. 10, 2013), and, with related patents, is also the subject of a
consumer protection lawsuit, Vermont v. MPHJ Tech. Investments LLC, No. 282-5-
IPR2013-00302
Patent 7,986,426 B1

3

13 (Ver. Sup. Ct., May 2013) (MPHJ filing notice of removal to D. Vt., June 7,
2013 (No. 2:13-cv-00170)). See Pet. 3. The ’426 Patent is related to U.S. Patent
No. 6,771,381, which is also the subject of an inter partes review. See Hewlett-
Packard, Co. v. MPHU Tech. Invs., LLC, Case IPR2013-00309 (PTAB) (“’309
IPR”).
B. The ’426 Patent
The ’426 Patent describes a “Virtual Copier” (VC) system. The system
enables a user to scan paper from a first device and copy an electronic version of it
to another remote device, or integrate that electronic version with a computer
application in the network. See Ex. 1001, Abstract.
According to the ’426 Patent, “VC can be viewed as a copier. Like a copier,
VC takes paper in, and produces paper going out. The only difference is that VC
does not distinguish between electronic and physical paper.” Id. at col. 70, ll. 37–
39.
VC extends from “its simplest form” to its “more sophisticated form”:
In its simplest form it extends the notion of copying from a process
that involves paper going through a conventional copier device, to a
process that involves paper being scanned from a device at one
location and copied to a device at another location. In its more
sophisticated form, VC can copy paper from a device at one location
directly into a business application residing on a network or on the
Internet, or [vice] versa.
Id. at col. 5, ll. 48–55.
The VC includes “five essential modules”: input module, output module,
process module, client module, and server module. “Each module is a counterpart
to an aspect that is found on a conventional copier.” Id. at col. 70, ll. 41–43.
Notwithstanding that the latter sentence refers to each module, the ’426 Patent
ambiguously states that “[t]here is no counterpart to VC’s Server Module on a
IPR2013-00302
Patent 7,986,426 B1

4

conventional copier.” Id. at col. 71, ll. 26–27. In any event, the other four
modules have “counterparts” on “conventional” copiers: “The Input Module
manages paper or electronic paper entering VC. . . . The counterpart to VC’s Input
Module on a conventional copier is the scanner subsystem.” Id. at col. 70, ll. 47–
53. “The Output Module manages paper or electronic paper exiting VC. . . . The
counterpart to VC’s Output Module on a conventional copier is the printer or fax
subsystem.” Id. at ll. 54–61. “The Process Module applies processing to the
electronic paper as it is being copied. . . . The counterpart to VC’s Process Module
on a conventional copier is the controller.” Id. at l. 61–col. 71, l. 3. “The Client
Module presents the electronic paper as it is being copied, and any relevant
information related to the input or output functions. . . . The counterpart to VC’s
Client Module on a conventional copier is the panel.” Id. at col. 71, ll. 4–12.
“Unlike conventional copiers, VC’s Server Module is a unique subsystem that can
communicate with the other modules as well as third-party applications.” Id. at
ll. 13–15.
Figure 28 of the ’426 Patent follows:

IPR2013-00302
Patent 7,986,426 B1

5

Figure 28 depicts various peripheral devices networked with a VC. See id.
at Abstract.
C. Illustrative Claims
Of the challenged claims, claims 1–5 and 9–11 are independent. Challenged
claims 1, 5, and 10 follow:
1. A computer data management system including at least one
of an electronic image, graphics and document management system
capable of transmitting at least one of an electronic image, electronic
graphics and electronic document to a plurality of external
destinations including one or more of external devices and
applications responsively connectable to at least one of locally and via
Internet, comprising:

at least one scanner, digital copier or other multifunction
peripheral capable of rendering at least one of said electronic image,
electronic graphics and electronic document;

at least one memory storing a plurality of interface
protocols for interfacing and communicating;

at least one processor responsively connectable to said at
least one memory, and implementing the plurality of interface
protocols as a software application for interfacing and communicating
with the plurality of external destinations including the one or more of
the external devices and applications,

wherein the computer data management system includes
integration of at least one of said electronic image, electronic graphics
and electronic document using software so that said electronic image,
electronic graphics and electronic document gets seamlessly
replicated and transmitted to at least one of said plurality of external
destinations.

5. A computer data management system including at least one
of an electronic image, graphics and document management system
capable of transmitting at least one of an electronic image, electronic
IPR2013-00302
Patent 7,986,426 B1

6

graphics and electronic document to a plurality of external
destinations including one or more of external devices and
applications responsively connectable to at least one of locally and via
Internet, comprising:

at least one scanner, digital copier or other multifunction
peripheral capable of rendering at least one of said electronic image,
electronic graphics and electronic document;

at least one memory storing a plurality of interface
protocols for interfacing and communicating;

at least one processor responsively connectable to said at
least one memory, and implementing the plurality of interface
protocols as a software application for interfacing and communicating
with the plurality of external destinations including the one or more of
the external devices and applications,

wherein the software application comprises:

at least one input module managing data comprising at
least one of paper and electronic input to the computer data
management system, and managing said at least one scanner, digital
copier or other multifunction peripheral, and managing the electronic
input from at least one third-party software application;

at least one output module managing the data output from
the computer data management system, managing at least one imaging
device to output the data to at least one of a standard windows printer,
an image printer, and a digital copier, and managing the output of the
data to the third-party software application;

at least one process module applying at least one data
processing to the data comprising the at least one of the paper and the
electronic input as it is being copied, applying additional functionality
including at least one of workflow and processing functionality to the
data comprising the at least one of paper and electronic input as it is
being copied, and applying multiple processes to a single virtual copy;

IPR2013-00302
Patent 7,986,426 B1

7

at least one client module presenting the data comprising
the at least one of paper and electronic input as it is being copied, and
information related to at least one of input and output functions; and

at least one server module communicable with said at
least one input, output, client, and process modules and external
applications, and capable of dynamically combining the external
applications with at least one of digital capturing devices and digital
imaging devices.

10. A computer data management system including a server
module comprising:

enable virtual copy operation means for initiating, canceling,
and resetting at least one operation managed by said computer data
management system;

maintain list of available module means for maintaining a list of
input, output, and process modules that can be used in said computer
data management system, said list being used by at least one module
object accessible by said server module;

maintain currently active modules means for maintaining input,
output, and process modules currently being used for a current
computer data management system operation in a program object; and

maintain complete document information means for
maintaining information regarding a current file.

D. References Relied Upon
Petitioner relies upon the following prior art references in this Final
Decision:

Salgado, U.S. Patent No. 5,872,569 (Feb. 16, 1999) (Ex. 1005);

XEROX CORP., XEROX NETWORK SYSTEMS ARCHITECTURE GENERAL
INFORMATION MANUAL (1985) (Ex. 1002, “XNS Manual”); and

IPR2013-00302
Patent 7,986,426 B1

8

XEROX CORP., XEROX 150 GRAPHIC INPUT STATION OPERATOR AND
REFERENCE MANUAL, Parts I and II (1985) (Ex. 1003, “GIS 150 Manual”).
1

E. The Asserted Grounds
The trial involves the following grounds of unpatentability:
Claims 1–11 as anticipated under 35 U.S.C. § 102(b) by the XNS Manual;
Claims 1–11 as anticipated under 35 U.S.C. § 102(e) by Salgado.
II. ANALYSIS
A. Claim Construction
In an inter partes review, “[a] claim in an unexpired patent shall be given its
broadest reasonable construction in light of the specification of the patent in which
it appears.” 37 C.F.R. § 42.100(b); see also Office Patent Trial Practice Guide,
77 Fed. Reg. 48756, 48766 (Aug. 14, 2012) (Claim Construction). Under the

1
Petitioner refers to the GIS 150 Manual (Ex. 1003) as evidence to show inherent
features of the Xerox 150 GIS scanner, which is described in the XNS Manual as a
graphic input station, “Xerox 150 scanner,” and a “Xerox 150 GIS.” See Ex.
1002, 112, 114; Pet. 13–14 (discussing Ex. 1002 and Ex. 1003). Petitioner
essentially maintains that because the XNS Manual discloses the GIS 150 scanner
as part of XNS, the GIS 150 Manual forms a proper evidentiary basis to support
anticipation by the XNS Manual (for some of the claims). See Pet. 13, n. 11 (citing
Schering Corp. v. Beneva Pharmaceuticals, 339 F.3d 1373, 1377 (Fed. Cir. 2002),
18 (quoting Ex. 1002, 112); see also Ex. 1002, 114 (disclosing the “Xerox 150
GIS”); 135, Fig. 12-8 (“150 Graphic Input Station” “integrat[ed] in the Xerox
electronic publishing applications.”). Patent Owner does not argue that
Petitioner’s evidentiary use of the GIS 150 Manual to show inherent features is
improper. See PO Resp. 21 (“Patent Owner asserts that Petitioner’s reliance on
GIS 150 does not cure the deficiencies of the anticipation allegation,” because the
GIS 150 Manual discloses destination “addresses . . . not applications”). On this
record, under the reasoning and holding of Schering and In re Baxter Travenol
Labs, 952 F.2d 388, 390 (Fed. Cir. 1991) (extrinsic evidence may be used to
explain what a reference discloses), using the GIS 150 Manual as evidence to show
inherent basic features of the GIS 150 scanner, which the XNS Manual discloses as
an integrated Xerox networked device in XNS, is proper.
IPR2013-00302
Patent 7,986,426 B1

9

broadest reasonable construction standard, claim terms are 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). Any special definition for a claim term must be set forth in
the specification with reasonable clarity, deliberateness, and precision. In re
Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). In the absence of such a special
definition or other consideration, “limitations are not to be read into the claims
from the specification.” In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993).
At least one, at least one of, and related phrases
Claim 1 and most of the other claims recite the phrase “at least one” or “at
least one of” in a number of places. For example, claim 1 recites “at least one of
locally and via the Internet,” and claim 5 recites “at least one input module
managing data comprising at least one of paper and electronic input to the
computer data management system.”
In the Institution Decision, we initially determined that phrases of this type,
“at least one of A and B,” and “at least A and B,” are interpreted in the alternative,
i.e., “one or more A or B.” Dec. on Inst. 14. Petitioner and Patent Owner do not
challenge this interpretation. Patent Owner’s declarant, Mr. Weadock, “do[es] not
take issue” with this interpretation, and agrees that “at least one of A and B” and
“at least A and B” means “in the alternative.” Ex. 2002 ¶ 17.
Software Application/Application
Claims 1 and 5 recite a “software application,” and claim 1 also recites “one
or more of external devices and applications.” Patent Owner contends that an
“application” is “a discrete software program executable on an operating system
for the purpose of accomplishing a task.” PO Resp. 6. Patent Owner also contends
that an “application” and a “software application” do not include “firmware”:
IPR2013-00302
Patent 7,986,426 B1

10

“While firmware is made up of software, it is not the same thing as a software
application. Nowhere in the specification of the ‘426 patent is ‘application’ or
‘software application’ used in the context of device firmware.” Id.
Petitioner contends that an “application” “does not exclude firmware (or
even hardware),” and “is not limited to ‘a discrete software program.’” Pet.
Reply 8. The Specification supports Petitioner’s contention. It refers to “an
application (e.g., Lotus Notes, Microsoft Exchange, the Internet, or an electronic
filing system).” Ex. 1001, col. 6, ll. 59–61 (emphasis added). Also, it states that
VC can copy “in and out of devices and business applications (such as Microsoft
Office, Microsoft Exchange, Lotus Notes).” Id. at col. 45, ll. 44–46.
Patent Owner’s contentions imply that an “application” and a “software
application” mean the same thing. See PO Resp. 6–7. This contention renders the
term “software” redundant. The term “application” is not limited to software, as
the disclosed examples of the Internet and electronic filing systems verify. As
another example, in the Institution Decision, we found that the ’426 Patent
Specification “refers to copying from ‘one device and[/]or application to another
device and/or application,’ thereby broadly blurring any distinction between a
device and a device having a software application.” Dec. on Inst. 14 (quoting Ex.
1001, col. 6, ll. 44–46; col. 46, ll. 30–33). In other words, an “application” may
include hardware, software, or software and hardware.
Patent Owner also argues that a “software application” must be “a single
software application.” See PO Resp. 16. The claims do not recite a “single”
software application. Patent Owner does not point the Board to how the ’426
Patent Specification distinguishes “firmware” from stored software that is
distributed as part of a software application. Software must be stored somewhere
typically (i.e., unless it is being transmitted). As Petitioner argues, the
IPR2013-00302
Patent 7,986,426 B1

11

Specification includes “distributed architecture” with the VC software stored
virtually anywhere. See Pet. Reply 8. For example, the Specification states that
“[t]he VC software can reside on a PC, LAN/WAN server, digital device (such as a
digital copier), or on a web server to be accessed over the Internet.” Ex. 1001,
col. 45, ll. 46–48. According further to the Specification, software is stored in
“any multitude or combination of . . . storage devices.” Id. at col. 61, ll. 28–29;
Fig. 15 (depicting system components including memory devices 60, 62, 66, 68,
70, and processor/CPU 58). The processing system can include “processing
system network combinations of the same.” Id. at col. 61, l. 34. The software may
reside on different servers and clients: “Alternatively, the engine object layer and
the engine may be optionally located in a distributed environment on different
machines, servers, and the like.” Id. at col. 66, ll. 65–67.
The “Internet,” and “filing system,” and listed examples of an “application,”
involve a wide variety of distributed software and hardware. The Specification,
therefore, does not preclude an “application” from including hardware and
software, including firmware (software on a device). The ’426 Patent
Specification includes other broad examples: “Accounting systems, like most
business applications, typically have no way of maintaining an electronic copy of
the physical invoice . . . and . . . adding a document management system to an
accounting system is cumbersome . . . and . . . difficult to coordinate.” Ex. 1001,
col. 47, ll. 5–12 (emphasis added). This sentence equates a “system” with an
“application.” Claim 2 recites that “wherein one or more of the external devices
and applications include a printer, facsimile and a scanner.” This further implies,
in line with the ’426 Patent Specification, which includes the Internet or a file
server as an application, that an “application” may include a printer, facsimile, and
scanner hardware, with its associated software.
IPR2013-00302
Patent 7,986,426 B1

12

The record shows that a “software application” typically must be stored
somewhere to be used by a system. Patent Owner does not explain why the claims
preclude software from being stored as “firmware” and distributed in system-wide
memory. The title of the ’426 Patent is “Distributed Computer Architecture and
Process for Document Management.” The title bolsters the finding that the
disclosed invention contemplates a software application that works in a distributed
manner as a suite of programs, in different machines and on different memory
locations, to accomplish various functions. The ’426 Patent also discloses
combining a processing circuit with “any . . . suitable processing circuits,
including programmable logic devices, such as PALs (programmable array logic)
and PLAs (programmable logic arrays), DSPs (digital signal processors)[,] . . .
ASICs (application specific integrated circuits), VLSIs (very large scale integrated
circuits) or the like.” Id. at col. 61, ll. 58–64. This disclosure further shows that
the invention may include distributed software, including firmware and other
software.
During the hearing, Patent Owner acknowledged that one of the examples
disclosed as an application, “Microsoft Office,” is not a discrete application:
JUDGE TIERNEY: Counsel, can you explain, is Microsoft Office a
discrete application?
MR. HILL: No, it’s not, but every time Microsoft Office appears in
the specification, it appears in a parenthetical that uses the phrase
“business applications,” plural. So, when you open up that
parenthetical and you see Microsoft Office, Microsoft Office is an
embodiment of business applications. It’s PowerPoint, it’s Microsoft
Word, a person of ordinary skill in the art would readily reconcile
business applications and Microsoft Office in that parenthetical.
Tr. 27:21–28:4.
The ’426 Patent Specification does not support Patent Owner’s
grammatically-based argument at the hearing. The ’426 Patent Specification refers
IPR2013-00302
Patent 7,986,426 B1

13

to the set of “business applications (such as Microsoft Office, Microsoft Exchange,
Lotus Notes).” Ex. 1001, col. 10, ll. 32–33. It does not refer to each member of
the set, for example, Microsoft Exchange, or Microsoft Office, as comprising a
group of “business applications.”
Mr. Weadock, Patent Owner’s declarant, in forming his opinion that a
software application is a “discrete program,” does not address the broad examples
in the ’426 Patent Specification. See PO Resp. 6 (citing Ex. 2002 ¶ 22). During
his deposition, Mr. Weadock acknowledged that the disclosed software
application, Microsoft Office, constitutes multiple “programs . . . bundled in a
package . . . or . . . suite” of applications. See Pet. Reply 7 (citing Ex. 1013, 42:1–
12, 98:12–23, and discussing Mr. Weadock’s declaration).
Accordingly, a “software application” is a program, or group of programs,
which operate together in a system to perform a function or functions, and the
programs can be stored in a variety of places on a variety of devices, and operate in
a distributed manner. An application may include software and hardware and
performs a function or functions.
Module
Claim 5 recites a software application comprising at least five modules: “at
least one input module,” “at least one output module,” “at least one process
module,” “at least one client module,” and “at least one server module.”
In the Institution Decision, we found that one plain meaning of “module,” is
“a logically separable part of a program.” Dec. on Inst. 16 (citing IEEE 100 THE
AUTHORITATIVE DICTIONARY OF IEEE STANDARDS TERMS SEVENTH EDITION 704
(2000), available at
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4116801 (last visited
Sept. 19, 2013).
IPR2013-00302
Patent 7,986,426 B1

14

We determined that a “‘module’ . . . is a logically separable part of the
recited software application, and may include another module and may overlap
with another module in functionality.” Dec. on Inst. 18. Petitioner agrees with the
definition, and Patent Owner does not.
We noted that the ’426 Patent states that the modules have “counterparts” to
“aspects” in conventional devices: “Each module [except perhaps a server
module] is a counterpart to an aspect that is found on a conventional copier.” Id. at
3 (quoting Ex. 1001, col. 70, ll. 41–43), 16. As to the sever module, the ’426
Patent Specification states that “[u]nlike conventional copiers, VC’s Server
Module is a unique subsystem that can communicate with the other modules.”
Ex. 1001, col. 48, ll. 27–29 (emphasis added). A unique subsystem need not be a
discrete module.
We also noted that the ’426 Patent states that “[t]he Client module is
generally simply an interface to the Server Module.” Dec. on Inst. 16 (citing
Ex. 1001, col. 49, ll. 30–32). Therefore, we reasoned that because one module
may be within (i.e., an interface thereto) another module, a module may overlap
with another module and may overlap in functionality. See id. This overlap of
module programming code (or its associated function) coalesces with the ordinary
definition, which does not preclude it.
Patent Owner maintains that the Specification provides no support for this
inclusion or overlap. PO Resp. 7 (citing Ex. 2002 ¶ 27). Patent Owner proposes
that a “module” is “a logically separable part of the software application of the data
management system that can function in a plug-and-play manner within a Virtual
Copier.” Id.
Patent Owner, relying on Mr. Weadock, maintains that this definition “is the
broadest reasonable interpretation in light of the specification.” Id. (citing
IPR2013-00302
Patent 7,986,426 B1

15

Ex. 2002 ¶ 30). Mr. Weadock states that this definition constitutes a “more
appropriate interpretation of ‘module’ in the context of the ‘426” Patent. Ex. 2002
¶ 31. Mr. Weadock cites to the Institution Decision at page 12, where we noted
that the ’426 Patent states that “[a]s long as the Input and Output Module conform
to the API specified in this document it will plug-and-play with VC.” See
Ex. 2002 ¶ 28; Ex. 1001, col. 9, ll. 33–36. Mr. Weadock also bases his opinion on
the “fact [that] the ‘426 specification does not disclose one module that includes
another, or that overlaps with another.” Ex. 2002 ¶ 27.
The record does not support Mr. Weadock’s interpretation. Mr. Weadock’s
opinion that there is no support for one module including the other does not
address the fact quoted above and in the Institution Decision that the ’426 Patent
states that “[t]he Client module is generally simply an interface to the Server
Module.” Ex. 1001, col. 49, ll. 30–32. The client module, then, is an interface, or
part of the server module. Mr. Weadock’s interpretation also ignores the qualifier
in the Specification that is missing from claim 1: “[a]s long as the . . . [m]odule
conform[s] to the API specified in this document it will plug-and-play.” Ex. 1001,
col. 9, ll. 33–36 (emphasis added). No claim in the ’426 Patent requires a module
to conform to the “API specified,” the “‘C’-language API” or “COM-based
interface,” as specified in the ’426 Patent Specification. See Ex. 1001, col. 49, ll.
39–49. None of the claims, except claims 7 and 8, recite an API or “application
programmer interface.” None of the claims recite a “discrete” or “plug-and-play”
feature.
Patent Owner chose not to limit the claims by qualifying the modules as
“discrete” or “plug-and-play.” The ’426 Patent implies that a module, as set forth
in the claims, is broader than any specific examples of discrete “plug-and-play”
modules. Salgado refers to “discrete modules.” Ex. 1005, col. 3, l. 39. This
IPR2013-00302
Patent 7,986,426 B1

16

further implies that skilled artisans would have recognized that the ordinary
meaning of a generic module is not limited to discrete “plug-and-play” modules.
In essence, a software module has boundaries defined by specific code that
produces a specific software function. This generic software module is “logically
separable,” because it can be defined by the logic code that produces its function,
even if the module cannot be physically extracted from a single memory location
as a “plug-and-play” module.
Dr. Melen supports this concept of a generic software module defined by its
function. During cross-examination by Patent Owner, Dr. Melen, Petitioner’s
declarant, testifies that “the word ‘module’ is very broad and very nonspecific, and
be comprised of modules and modules of . . . modules, modules spread across the
network, modules which include other people’s code.” Ex. 2003, 144:16–20.
Dr. Melen similarly testified, when asked about the five modules claimed
and disclosed in a related patent having the same Specification as the ’426 patent,
that
I don’t think . . . module is necessarily one thing. You can have a
module inside a . . . module. You can have a module which spans
machines. Module is not so precise. But what is more specific is
exactly what they do. And so the question is, does [the prior art] talk
about those basic functions of scanning and printing and - - yes. . . .
It’s just software.
Ex. 2003, 142:5–15 (emphasis added).
Dr. Melen’s testimony is consistent with the ’426 Patent Specification,
which defines modules as counterparts to prior art modules–– defined by the
function they perform. Another passage in the ’426 Patent implies that in addition
to code, module functions may overlap: “[W]hile the above discussion has
separated the various functions into separate layers of functionality, the layers may
IPR2013-00302
Patent 7,986,426 B1

17

be combined, physically and/or logically, and various functions may be combined
together.” Ex. 1001, col. 84, ll. 19–22.
Mr. Weadock candidly stated during cross-examination that a module may
overlap in code with another module, retreating from statements in his declaration
that may have been interpreted as absolutely precluding overlap in modules: “And
normally when we talk about modules, we think of them as not overlapping, but
there might be situations in which modules could share some code. There might be
some common code between two modules.” Ex. 1013, 191:3–7. Mr. Weadock
also acknowledged that separate functionality between modules may not be
required: “I hesitate to ever make any absolute statements when it comes to
software. . . . Because there’s so many different designers and so many different
philosophies, but it would - - I can say that it would surprise me to see a modular
software application with heavy overlap of functionality between the modules.” Id.
at 192:6–15.
As Petitioner argues, Mr. Weadock’s declaration does not cite to the ’426
Patent Specification for support of a limiting definition of a module, which would
require it to be discrete, or plug-and-play. See Pet. Reply 10–11. Petitioner also
points out that Mr. Weadock relies on a publication dated about fifteen years after
the date of the invention, to support a limiting definition of module. See id. at 4,
10. Although Mr. Weadock generally testified during his cross-examination that
the concept of a distinction between modular versus monolithic software is well-
known, the testimony does not show that in light of the ’426 Patent Specification,
it was a well-known distinction at the time of the invention. See Ex. 1013, 191–
194. Rather, the testimony shows that both experts agree that at the time of the
invention, skilled artisans would have understood that software modules may
overlap in code and in function.
IPR2013-00302
Patent 7,986,426 B1

18

According to the foregoing discussion, each “module,” as recited in claim 5,
does not require a discrete or plug-and-play feature, but each module is a logically
separable part of the claimed “software application,” demarcated by code
corresponding to the specific function recited for that software module. Each
software module may include another software module and overlap with another
such module.
B. The Hearing
During the hearing, Patent Owner acknowledged that the XNS Manual or
Salgado disclose the claimed functions with respect to claims 1–5:
JUDGE EASTHOM: Can I ask you another question, are you
contending that those functions [i.e., claims 1–5] are not in the
software of XNS or Salgado? Are they? In other words, are the
functions separately there, or are they not?
MR. HILL: If you take XNS -- if you take all system elements
on XNS and you aggregate them, and you list out every function that
they, you know, are described or reasonably are associated with what
is being described, you would -- you would have all of the functions.
The problem is you wouldn’t have a software application taught
anywhere in Salgado that actually implements -- or I’m sorry, in XNS
that actually implements two interface protocols from a common
memory where that software application describes all of these
functions in a modular fashion that meets a reasonable construction of
the term “module.”
Tr. 43:17–44:5 (emphasis added); see also Tr. 44:1–7 (previous questioning about
“claims one through five”).
C. The Demand Letter
Petitioner Hewlett-Packard, in the related ’309 IPR proceeding, submitted a
demand letter (’309 IPR, Ex. 1016, 26) by Patent Owner to accused infringers of
Patent Owner’s patents. See ’309 IPR, Paper 25 (Pet. Reply) 4 (arguing “it would
be improper to ignore [Patent Owner’s] prior statements for purposes of BRI
IPR2013-00302
Patent 7,986,426 B1

19

[broadest reasonable interpretation].”). The demand letter is not necessary to the
holding or the claim construction, but it serves to corroborate the claim
construction of module and application outlined above. The demand letter implies
that Patent Owner’s claim construction of these terms corresponds to the
constructions outlined above.
2

For example, Patent Owner’s demand letter states that
[a] good example of an infringing system, and one your
company likely uses, is an office local area network (“LAN”) which is
in communication with a server, employee computers having email
software such as Outlook or Lotus, and a third-party scanner (or a
multi-function printer with scanning functionality) which permits the
scanning of a document directly to [an] employee email address as a
pdf attachment. Such a system would be a typical example of what
infringes. There are other examples listed further below.
. . . [Y]ou may find it useful to consider, as illustrative examples,
claims 1–5 of the ’426 Patent. Reviewing those you can see that the
patent claims are directed to a system having a digital
copier/scanner/multifunction device with an interface to office
equipment (or to the web) and related software, for scanning or
copying and transmitting images electronically to one or more
destinations such as email, applications or other local files. Coverage
of this type of system, and of the more generally worded example
[above] . . . , is further reflected in claims 1, 8 and 15 of the ’410
Patent, claims 12 and 15 of the ’381 Patent, and claims 9 and 16 of the
’590 Patent.
’309 IPR, Ex. 1016, 27 (emphasis added).
As noted above, claim 5 includes “a software application” that “comprises
. . . at least one input module . . . at least one output module . . . at least one process
module . . . at least one client module . . . at least one client module . . . and at least
one server module.” Ex. 1001, col. 86, ll. 21–46. The demand letter implies that

2
Patent Owner was questioned about the demand letter during the ’302 IPR
hearing and the ’309 IPR hearing. See Tr. 43; IPR ’309, Tr. 18–22.
IPR2013-00302
Patent 7,986,426 B1

20

infringing this claim, or any of claims 1–5, does not require discrete modules or a
single application. As the letter states, the claimed system is “directed to a system
having a digital copier/scanner/multifunction device with an interface to office
equipment (or to the web) and related software, for scanning or copying and
transmitting images electronically to one or more destinations such as email,
applications or other local files.” ’309 IPR, Ex. 1016, 27 (emphasis added).
D. Asserted Grounds of Unpatentability
1. XNS Manual – Overview
The XNS Manual, describes the Xerox Network System (“XNS”), which
constitutes a document management system. The described system allows one “to
design highly integrated information systems, using hardware and software
elements designed by different groups using different technologies.” Ex. 1002, 4.
3

“The general objectives of XNS [are] . . . to increase the ROIA [(return-on-
information assets)] by facilitating the creation, capture, storage, communication,
printing, and replicating of electronic or paper documents within the office . . . .
This is what Xerox calls document management.” Id. at 8. The XNS Manual
generally describes producing electronic or paper processing of a “variety of
complex images, including typeset quality documents, line graphics, and even
photographs that have been converted into electronic form by a scanner.” Id. at 91.
“In XNS, the electronic subsystem usually receives information over the network
(Ethernet or larger internet). This information consists of data to be printed and
instructions on how it is to be printed.” Id. at 92. The XNS Manual discloses

3
Exhibit 1002 includes original page numbers, to which Petitioner and Patent
Owner refer, and different page numbers, added by Petitioner. We refer to the
original page numbers.
IPR2013-00302
Patent 7,986,426 B1

21

email, network filing, network printing, and network scanning. See id. at 71–76,
83–116.
According to the XNS Manual, “server[s]” provide “services” which are
“high-level functional activities such as filing, printing, mailing, and external
communications.” Ex. 1002, 18. The services “represent high-level applications
performed within the architecture.” Id. “The XNS services implement various
application-layer protocols, as depicted in Fig. 2-4.” Id. “The[se] services are
typically collections of software acting according to the rules of the architecture
and its protocols.” Id. (emphases added, original emphasis omitted). “One should
. . . think of a ‘server’ as any collection of necessary electronics, software, and
peripheral equipment necessary to deliver a service.” Id. Servers may be “general-
purpose minicomputers programmed to perform the requisite functions,” and
include a workstation or a minicomputer. Id. (emphasis added).
“The user interface on Xerox professional work stations provides an easy
way for anyone to create, file, mail, or print information.” Id. at 19. These
“workstations are the clients of the described services.” Id. “Most system options
appear on ‘pop up’ menus and can be activated by merely pointing at an option and
clicking a button on a . . . ‘mouse’.” Id. The “user interface . . . makes services on
the network readily accessible,” with “network resources . . . shown as . . . icons.”
Id. XNS, according to the XNS Manual, divides conceptually into workstations,
which a user accesses directly, and servers, which provide services, although
workstations also can function as servers to provide a service (“given the
appropriate peripherals and software”). Id. at 18.
The XNS architecture employs a hierarchy of known protocols on different
layers. Ex. 1002, 14 (“Protocols for each layer”). In the XNS, the highest layer
includes “application protocols,” which include “mailing, printing, filing, and
IPR2013-00302
Patent 7,986,426 B1

22

gateway access,” and which are “implemented in hardware/software to provide the
XNS application services.” Id. at 16. Basically, two nodes (for example, two
software services, two workstation interfaces) communicate with each other
conceptually using several layers of protocols (“each layer in one node . . . working
with the corresponding layer in other node”). See id. at 14. “[A] given protocol
represents a dialogue between two equally potent functions, each of which operates
through its upper and lower interfaces [i.e., through the interfaces to upper and
lower protocol layers] to perform its specific tasks.” Id.
2. XNS Manual–Anticipation
Claim 1
Claim 1 recites a “computer data management system including . . . at least
one scanner, digital copier or other multifunction peripheral capable of rendering at
least one of said electronic image, electronic graphics and electronic document.”
Pet. 15–16. Addressing this limitation, Petitioner explains that an XNS scanning
or other device, including workstations, “communicate[s] with other devices and
services on the Internet,” and sends image data to “a specified file in a File Service
for storage, or to a Print Service for printing (using Printer Subset of the Filing
Protocol).” Id. (emphasis omitted) (quoting and citing Ex. 1002, 112, 126–135,
Fig. 11-2).
Claim 1 also recites “at least one memory storing a plurality of interface
protocols for interfacing and communicating,” and “at least one processor . . .
implementing the . . . protocols as a software application.” Pet. 16. Addressing
these related limitations, in addition to citing the Filing Protocols, Petitioner cites
the Courier protocol, “‘multiple transmission protocols corresponding to different
types of communication services,’” and “‘multiple application protocols
corresponding to different functions.’” Pet. 16 (emphasis omitted) (quoting
IPR2013-00302
Patent 7,986,426 B1

23

Ex. 1002, 14; citing id. at 14–20, Fig. 2-4). As explained supra in the Overview
section, system elements, including workstations, scanners, servers, and other
devices, generally employ a myriad of protocol layers to communicate in the XNS
network. See Pet. 16 (citing Ex. 1002, 17–18, 112; Ex. 1008 ¶ 34).
According to Dr. Melen, XNS software, including protocols, must be stored
in the “necessary” memory hardware, see id. (citing Ex. 1008 ¶ 34), and other
“necessary” hardware, such as a processor in a minicomputer, uses the software.
See Ex. 1008 ¶ 34. Dr. Melen provides an analysis of the XNS Manual to support
his opinion. The analysis tracks the findings supra in the Overview section. See
id. ¶¶ 31–34. Dr. Melen explains that his opinion is based on his experience, “the
explicit statements in [the] XNS [Manual] that the application protocols are
‘implemented in hardware/software’,” and that “‘a directly-connected device is
expected to implement all layers of XNS appropriate to its function which would
include at least all the layers upward through Courier (see Fig. 2-4), plus selected
application protocols.’” Ex. 1008 ¶ 34 (quoting Ex. 1002, 15, 18).
The record, summarized in the Overview section, supports Dr. Melen’s
testimony. Implementing appropriate protocols according to a software
application’s specific function implicitly means that the protocols must be stored in
memory to be selected and implemented by the software using some type of a
processor, i.e., “implemented in hardware/software.” Further, “[t]he XNS services
implement various application-layer protocols, as depicted in Fig. 2-4.” Ex. 1002,
18 (emphasis added). “These services are typically collections of software acting
according to the rules of the architecture and its protocols.” Id. (emphases added)
(original emphasis omitted).
Claim 1 further requires that the data management system includes
“integration of at least one of said electronic image, electronic graphics and
IPR2013-00302
Patent 7,986,426 B1

24

electronic document . . . so that said electronic image, electronic graphics and
electronic document gets seamlessly replicated and transmitted to at least one of
said plurality of external destinations the need to modify the destination
application.”
Petitioner explains that XNS provides services “‘to the network users on a
transparent basis, leaving them free to concentrate’” on other tasks. Pet. 17
(emphasis omitted) (quoting Ex. 1002, 121). Petitioner also explain that XNS
allows scanned and digitized documents to be sent to or via external applications,
including a File Service for storage, Print Service for printing, XNS mail, editing at
another workstation, or any other device or application on the network. See id.
(citing Ex. 1002, 71–76, 91–116, 121, 128). According further to Petitioner, the
XNS Manual describes that “‘[w]here graphic elements are acquired from other
sources (e.g. photographs), they can be scanned . . . and subsequently edited.
These electronic graphic elements can be automatically integrated with the text to
form final-form page masters . . . .’” Pet. 17 (quoting Ex. 1002, 128 (emphases
added) (Petitioner’s emphasis omitted); citing Ex. 1008 ¶¶ 40, 41).
Fundamentally, the purpose of XNS is to provide “compatibility among
products from different vendors,” (Ex. 1002, 146), and similarly, “functional
integration”: “integration means that all products work effectively with other
products, exchanging data, sharing resources, and building applications, thereby
leading to new levels of productivity” (id. at 2). According to the ’426 Patent,
“VC can be viewed as a copier,” even though “VC does not distinguish between
electronic and physical paper.” Ex. 1001, col. 70, ll. 37–39. Based on the
foregoing description, the XNS Manual and the ’426 Patent disclosure describe
similar functionality––basic copying/scanning functions that include scanning
paper for further application processing of an electronic copy of the paper.
IPR2013-00302
Patent 7,986,426 B1

25

Patent Owner asserts that the XNS Manual does not disclose “a ‘software
application’ such that ‘a plurality of [interface] protocols’ are implemented as a
software application,” as set forth in claims 1–5. PO Resp. 12 (emphasizing claims
1 and 5, addition by Board). Patent Owner argues that the highest protocol layer in
XNS contains application protocols, that lower layers contain transmission
protocols, and that the latter is not implemented as software application. Id. Patent
Owner explains that “transmission protocols are used ‘without disturbing the
protocols in higher layers.’” Id. (citing Ex. 1002, 21). Patent Owner also contends
that XNS does not “implement[] the plurality of interface protocols as a software
application.” Id. at 13 (emphasis omitted).
Patent Owner’s arguments are not persuasive. As explained in the Overview
section, the application layer itself contains multiple protocols for each application,
i.e., mailing, printing, filing, and gateway access. See Ex. 1002, 14–16, Fig. 2-4.
Even if lower layer protocols do not “disturb[]” upper layer protocols, as Patent
Owner contends, and even if an application layer does not contain multiple
protocols (which Patent Owner does not contend), different layers of protocols
generally communicate with, or at least “use the resources of,” lower layers
through “interfaces.” Id. at 14, 11 (“[A] commonly-accepted perspective is that the
functions of one layer use the resources of the lower layers to complete their
assigned tasks.”). In any event, the application layer protocols comprise several
types of application protocols. Id. at 15 (Fig. 2-4), 16.
The GIS-150 Manual is consistent with our understanding of the XNS
Manual and the XNS protocols used in the XNS, and states that, in addition to
Ethernet, the scanner “uses several additional layers of protocols,” and that devices
“communicate via a network using . . . standard protocols . . . . These connection
standards are implemented in functionally identical programs and operate through
IPR2013-00302
Patent 7,986,426 B1

26

compatible hardware interfaces in each attached device . . . .” Ex. 1003, App’x B-
1, 203 (emphasis added).
4

The “communication services” (i.e., software) implement transmission
“protocol modules”: “[I]n most cases new classes of communication services can
be accommodated through the addition of new transmission protocol modules
without disturbing the protocols in the higher layers.” Ex. 1002, 21 (emphasis
omitted). In other words, the “new transmission protocol modules” do not
“disturb[]” upper protocol layers, in the sense that upper layer protocols need not
be redesigned in order to continue to use or communicate with the new modules in
the lower layers. See id. In any event, software services generally implement
protocols. See id. at 16, 18; see also supra Overview section. The services
“represent high-level applications performed within the architecture.” Id. at 18.
“The XNS services implement various application-layer protocols, as depicted in
Fig. 2-4.” Id. The XNS Manual also describes “protocols” as “control functions,”
indicating, that protocols, as modules, implemented by software, primarily exist as
a stored software application. Id. at 21; Ex. 1008 ¶ 34. In summary, Dr. Melen’s
testimony supports our understanding and Petitioner’s showing regarding the XNS
Manual , and shows that XNS protocols must be stored in memory and
implemented as a software application to facilitate communication.
Patent Owner focuses attention on a “software application” as set forth in
claim 1. Patent Owner contends that “Petitioner ultimately relies on an entire
distributed network architecture made up of collections of software when alleging

4
The GIS 150 Manual corroborates our understanding of XNS protocols as
disclosed in the XNS Manual, but it is not required to support the ground of
anticipation by the XNS Manual of claim 1. Nevertheless, as discussed above, the
use of the GIS 150 Manual as evidence to support anticipation by the XNS Manual
of the claims (including claim 1) is proper on this record. See supra note 1.
IPR2013-00302
Patent 7,986,426 B1

27

[the] XNS [Manual] teaches ‘implementing a plurality of protocols.’” PO Resp.
14. Patent Owner similarly contends that “the distributed software that appears to
access XNS services to implement XNS protocols is not the same thing as
implementing the protocols as one software application.” Id. at 14 (emphasis
added).
These arguments imply that claim 1 recites a “single software application.”
Id. at 16. Claim 1 does not recite or require a “single software application,” nor
does it preclude distributed software from implementing protocols. Id. at 14. As
noted in the Claim Construction section, the disclosed system uses a distributed
architecture: “communication may . . . provide . . . a distributed component
interaction over a networking environment.” Ex. 1001, col. 67, ll. 58–61.
5

“Fig. 27 is a detailed illustration of a stand-alone and/or distributed environment or
architecture for image viewer in the Internet environment.” Id. at col. 67, ll. 62–
63. In addition, Patent Owner does not explain how the disclosed system in the
’426 Patent stores different “protocols” in a single memory, or what the limitation
entails, given the emphasis on a single protocol, DCOM. See note 5.
Patent Owner also acknowledges that the “XNS [Manual] discloses multiple
protocols,” (PO Resp. 16), implemented by distributed software, id. at 14
(describing “the distributed software that appears to access XNS services to
implement XNS protocols”). See also id. at 16 (arguing that some of the XNS
protocols “are implemented in software” and others are “implemented in
hardware” (citing Ex. 2002 ¶ 103)). Nevertheless, Patent Owner contends that
“different protocols appear to be supported on different machines,” but they are not
“necessarily stored in the same ‘at least one memory.’” Id.

5
“The present invention utilizes the DCOM communication protocol defining the
communication protocol . . . .” Ex. 1001, col. 67, ll. 44–45.
IPR2013-00302
Patent 7,986,426 B1

28

Contrary to these arguments, claim 1 does not recite a single, common,
memory, for storing the protocols. Rather, claim 1 recites “at least one memory
storing a plurality of interface protocols for interfacing and communicating.”
Further, as described in the Claim Construction section and above, the ’426 Patent
discloses storing software over a wide distributed architecture that includes many
devices or storage locations over a wide network.
As indicated above, Dr. Melen testifies that “XNS necessarily include[s] . . .
memory . . . and software to implement application and transmission protocols, and
to connect to the network; the memory used to store the protocols and software, the
processor used to implement the protocols and execute the software.” Ex. 1008
¶ 34. Mr. Weadock challenges Dr. Melen’s testimony on the “single memory”
basis: Dr. Melen “omits the ‘one memory’ wording from his analysis, and refers
instead to ‘[] the memory used to store the protocols and software.’” Ex. 2002
¶ 103. Mr. Weadock’s challenge, like Patent Owner’s, is not commensurate in
scope with claim 1, which does not require only “one memory.” There is no
dispute on this record that the XNS Manual discloses “at least one memory storing
a plurality of interface protocols,” as recited in claim 1.
Based on the foregoing discussion and the record evidence, Petitioner shows
by a preponderance of evidence that the XNS Manual anticipates claim 1.
Claims 2 and 11
Patent Owner contends that the XNS Manual does not disclose “integration
of . . . [an] electronic document into a destination application,” as claim 2 recites,
or “integrating electronic images into existing applications,” as claim 11 recites.
Patent Owner contends that distributing a document with XNS mail, editing a file
at a workstation, or sending a file to a print service or device, does not amount to
integrating. PO Resp. 17–21. Patent Owner explains, for example, that “editing a
IPR2013-00302
Patent 7,986,426 B1

29

file ‘at a work station’ fails to disclose this limitation,” because “eventually editing
[a scanned document] . . . at some prior point in time does not teach integrating.”
PO Resp. 20.
Patent Owner’s arguments are not persuasive. Claims 2 and 11 do not
define a temporal limitation that precludes “eventual[]” editing. In addition, the
central purpose of the XNS system is to provide document “integration,” as
explained above in connection with claim 1. See Ex. 1002, 2 (“Productivity
through Integration”). The XNS Manual describes “[i]ntegration of paper and
electronic documents.” Ex. 1002, 7 (Fig. 2-1) (emphasis added). As Petitioner
points out, the XNS Manual discloses that “‘[t]he scanned image may be combined
with text to form a composite document . . . at a workstation or at a printer, using
the Interpress SequenceInsertFile.’” Pet. 17 (quoting Ex. 1002, 112, emphasis by
Board, Petitioner’s emphasis omitted). Graphic elements may be scanned and
subsequently edited and “automatically integrated with the text to form electronic
final form page masters.” Id. (quoting Ex. 1002, 128, emphasis by Board,
Petitioner’s emphasis omitted). The XNS Manual also allows a scanned document
to be “rendered by a workstation, which makes an electronic document visible.”
Ex. 1002, 8. The documents are compatible and “capable of being operated upon”:
“Once a document is created, it must be capable of being operated upon at some
point in the future and at another part of the system (even in another part of the
world where a different language is used).” Id. at 9. The XNS avoids “‘dead-
end”’ documents. Id.
VC “‘involves paper being scanned from a device at one location and copied
to a device at another location’” in “‘its simplest form’,” and “‘[i]n its more
sophisticated form, VC can copy paper from a device at one location directly into a
business application residing on a network or on the Internet, or [vice] versa.’”
IPR2013-00302
Patent 7,986,426 B1

30

Dec. on Inst. 3 (quoting Ex. 1001, col. 5, ll. 48–55). Patent Owner does not
explain how the invention recited in claims 2 and 11, presumably embracing either
the disclosed “simplest form” or “more sophisticated form,” requires more than the
integration disclosed in the XNS Manual: copying scanned electronic data, and
sending it to a user in the XNS mail system, to a file system, or editing it, using
these other destination applications as disclosed in the XNS distributed system, as
set forth by Petitioner. See Pet. 16–18 (claim 1 requires “integration” also).
Contrary to Patent Owner’s related arguments (see PO Resp. 18–19), the
disclosed XNS Manual destination applications, including printer software services
in a remote printer, facsimile software services in a remote facsimile, mail
software, or any myriad of interface or other software at remote destination
workstations, including editing services, or such similar software services located
in a distributed manner, constitute destination applications according to broad
disclosures in the ’426 Patent, which include “the Internet, or an electronic filing
system,” as “an application.” See Ex. 1001, col. 46, ll. 46–47; Pet. 17–18; supra
Claim Construction section, and claim 1 discussion.
Contrary to Patent Owner’s argument that the claim phrase “without the
need to modify the destination application” implies that the destination application
must have the ability to be modified (see PO Resp. 19), the phrase does not imply
that ability. Even if it does, any of the destination applications in the XNS Manual,
which include software, could be modified, but need not be, because XNS provides
“transparent” and integrated features, as Petitioner explains. See Pet. 17; Dec. on
Inst. 25; Ex. 1008 ¶ 43; supra claim 1 discussion. Contrary to Patent Owner’s
argument, a hardware printer can be modified, but need not be. See PO Resp. 19
(asserting “[u]nlike a software application, a device, such as a printer, cannot be
modified.”). Therefore, the XNS Manual’s described destination applications
IPR2013-00302
Patent 7,986,426 B1

31

allow integration of an electronic image “without the need to modify the
destination application,” as claims 2 and 11 require.
Based on the foregoing discussion and the record evidence, Petitioner shows
by a preponderance of evidence that the XNS Manual anticipates claims 2 and 11.
Claims 4 and 9
Claim 4 recites a “computer data management system [that] includes adding
at least one of electronic document, data and paper processing means via a single
programming step.” Claim 9 recites a similar limitation. Patent Owner argues that
“cropping,” using the Xerox GIS 150 scanner according to the Petition, does not
satisfy adding electronic data in a single programming step according to claims 4
and 9. PO Resp. 22–23; Pet. 19 (citing Ex. 1003, 5-5).
Initially, it is not clear entirely, on this record, what “a single programming
step” means. The limitation appears to be a product-by-process limitation, because
it recites “adding” a “processing means” to the “data management system” “via a
single programming step.” This claim language implies the system was created
using the single step. However, on this record, how a step is added to create the
management system does not limit the system’s structure or functionality. In any
event, Petitioner asserts that ‘“cropping’ can be added by providing instructions to
(programming) the user interface.’” Pet. 19.
Patent Owner does not address persuasively the contention that providing
instructions for cropping satisfies claims 4 and 9. The ’426 Patent Specification
discloses adding multi-step a “pre-packaged” “component” to legacy systems,
showing that even if such a component is added to the legacy system in one step, it
results in a legacy system with multiple programming steps (in the package). See
e.g., Ex. 1001, col. 5, ll. 38–40. Petitioner shows, by a preponderance of evidence,
that the XNS (i.e., Xerox GIS 150) scanner discloses what amounts to a product-
IPR2013-00302
Patent 7,986,426 B1

32

by-process limitation––the Xerox GIS 150 scanner adds cropping functionality.
Implicitly, the cropping functionality involves programming steps, as Petitioner
shows.
In the Institution Decision, we made the following initial determination:
The Specification describes “a one step programming method . . .
including at least one of a one step method of supporting paper within
electronic business process application optionally including legacy
systems with no or minimal reprograming.” Ex. 1001, col. 14, ll. 63-
67. Therefore, on this record, “a single programming step” embraces
a single function such as the XNS cropping function or other
disclosed XNS paper processing functions.
Dec. on Inst. 26.
In the above-cited disclosure, the ’426 Patent Specification refers to a “one
step programming method” which allows for “no or minimal reprogramming” of
legacy systems, implying a product-by-process limitation––adding something to a
legacy system. Patent Owner does not address what “a single programming step”
means. The “single programming step” may embrace a system function, for
example, the cropping function disclosed in the GIS 150 Manual. Ex. 1003, 5–5.
Although Patent Owner argues claims 4 and 9 together, claim 9 recites “the system
comprises . . . a capacity for adding at least one of electronic document and paper
processing with a single programming step.” Adding a “capacity” to a system
claim in a single programming step does not mean that the capacity itself
constitutes a single programming step.
Assuming it does, Patent Owner contends that “cropping” in the GIS 150
scanner “seems to require multiple programming steps . . . in order to perform crop
processing.” PO Resp. 22. Patent Owner argues that certain entries, such as
“‘Right, Left, Top, and Bottom crop distances’” must be added, prior to
performing cropping, thus Petitioner “fails to show paper processing with a single
IPR2013-00302
Patent 7,986,426 B1

33

programming step.” Id. at 23. Contrary to this argument, entering crop distances
constitutes entering data prior to selecting the single cropping step. In a similar
disclosed operation in the ’426 Patent, “the user simply has one sequence to
execute: select From, select To, and then press GO.” Ex. 1001, col. 6, l. 67–col. 7,
l. 1. In other words, prior to selecting GO, the user enters location data for the
“From” and “To” commands. Therefore, the ’426 Specification implies that claims
4 and 9 do not preclude entering data prior to invoking a single programming step.
Based on the foregoing discussion and the record evidence, Petitioner shows
by a preponderance of evidence that the XNS Manual anticipates claims 4 and 9.
Claim 5
Claim 5 recites a software application that includes an input module, an
output module, a client module, a process module, and a server module, each with
separate functions. The input module manages “electronic input from at least one
third-party software application.” The output module manages “output of the data
[from the management system] to the third-party software application.” Petitioner
asserts that the XNS system, as disclosed in XNS Manual, includes the claimed
modules, even if they are not discrete, and the third-party software application.
See Pet. 19–20. As indicated in the discussion above, the record, including ’426
Patent Specification, the demand letter, and statements by Patent Owner at the
hearing, corroborate Petitioner’s assertions regarding the construction of modules
and application. See supra Section II.B. and II.C.
For example, Petitioner asserts that “[a]ny personal computer, workstation,
or terminal,” with a software interface for bi-directional communications, as
disclosed in the XNS Manual, constitutes third-party software. Pet. 19 (emphasis
omitted). Petitioner also relies on other Xerox or non-Xerox facsimile machines,
IPR2013-00302
Patent 7,986,426 B1

34

and a “Kurzweil Intelligent Scanning System.” See Pet. 19 (citing Ex. 1002, 16,
113, 117); Ex. 1008 ¶¶ 42–46.
Regarding “at least one input module,” Dr. Melen explains that an interface
such as the Gateway Access Protocol, which permits integration between Xerox
and non-Xerox devices, constitutes a software communication interface, which
manages inputs and outputs from and to third-party software and hardware. See
Ex. 1008 ¶ 44; Pet. 19; Ex. 1002, 65–70.
Petitioner also generally refers to an Interactive Terminal Service, as
software application input or output modules for interfacing third-party
applications, including those on workstations on the network. See Pet. 19 (citing
Ex. 1002, 117, 120). Another input (or output) module includes a “File Service” or
“Print Service” that a scanner can access for sending digitized hard copies (thereby
inputting data from the workstation or outputting data to the service). See id.
Petitioner also shows that XNS manages data from a Kurzweil third-party software
application using a gateway service. Id.; Ex. 1008 ¶ 44.
In addition to the input and output modules identified above (which may
have some overlap in some instances), Petitioner points to a print service for
printing, filing service for filing, facsimile device software, and standard input-
output software (e.g., supporting ASCII communications) as “at least one output
module.” See Pet. 19–20 (citing Ex. 1008 ¶¶ 42–46). Petitioner points to a user
interface at a scanner, which provides cropping or scaling of an image, and other
functions, such as labeling, or scaling, as “at least one process module.” Id. at 20.
As an example scanner, Petitioner cites the Xerox GIS 150 scanner and scanner
model that is disclosed as part of the XNS system in the XNS Manual, citing the
GIS-150 Manual (Ex. 1003) as evidence of how the scanner inherently functions.
See supra note 1; Pet. 20 (citing Ex. 1003); Ex. 1002, 112; Ex. 1008 ¶¶ 36–37.
IPR2013-00302
Patent 7,986,426 B1

35

Petitioner also identifies a display or user interface on a workstation connected to a
scanner, with the interface for image editing, sending, applying settings and other
functions, or a similar user interface or display on a scanner, as “at least one client
module.” Pet. 20 (citing Ex. 1002, 111–113). The software for applying any of
the settings or other functions, including cropping or scaling, corresponds to a
process module.
These software packages, generally for handling inputs, outputs, services,
and processes, constitute logically separable parts of the XNS program
architecture––the modules as recited in claim 5, according to the construction
outlined above. For example, the GIS-150 scanners, constitute client modules,
input modules, and process modules. Such a scanner includes “Control Panel
software,” as a client module that accesses certain process modules. See Ex. 1003,
228. One software “routine” in the GIS-150 provides a label function, constituting
“at least one process module” providing “workflow” information, as claim 5
requires. See id. Generally, the GIS-150 “operating firmware” divides into “major
functional modules and the application functions they provide,” including
functions related to the Control Panel, the Image Input Subsystem, Ethernet
Communications, and Diagnostics. Id. at 227. “Overall control . . . resides in the
set of tasks and programs stored in the Control/Communication module.” Id.
(emphasis added). “Destination performs Ethernet addressing.” Id. at 228. The
Ethernet addressing software constitutes an input module to the XNS network. As
Petitioner asserts, the GIS-150 receives paper scan inputs and sends outputs to at
least five separate destinations, including third-party destinations, in the XNS
system, and includes other functions that correspond to the claimed input, output,
process, and client modules. See Pet. 18–20.
IPR2013-00302
Patent 7,986,426 B1

36

Petitioner also generally identifies software that provides or facilitates
communication within the XNS network, as described above, as constituting at
least one server module. See id. at 20 (referring back to Pet. 19). As discussed
above in connection with claim 1 and in the Overview section, in addition to GIS-
150, the XNS Manual describes servers that include software services, including
for controlling communications, mailing, scanning, printing, implementing
protocols, and other functions, and such servers may reside in workstations,
personal computers, or other terminals. See Ex. 1002, 18–19 (“Servers and
services”); Pet. 19. In addition, an “Application Support Environment provides
support resources called on by users and/or the application protocols shown . . . .
These protocols––mailing, printing, filing, and gateway access––are implemented
in hardware/software to provide the XNS application services.” Ex. 1002, 16.
These server services, “collections of software,” are “high-level functional
activities such as filing, printing, mailing, and external communications.” Id. at
18. Such separate server software services each reasonably constitute “at least one
server module communicable” with the other modules and “capable of
dynamically combining the external applications with at least one of digital
capturing devices and digital imaging devices,” as set forth in claim 5.
Patent Owner argues that the claimed modules must be discrete, and that the
software application must be single software application. See PO Resp. 24
(arguing “XNS fails to disclose a modular software application”). Based on the
Claim Construction section supra, these arguments are not commensurate in scope
with claim 5. See Pet. Reply 10–11, 14–15 (explaining why claim 5 does not
require a set of discrete modules or a single software application). As Petitioner
notes, Dr. Melen testifies that “a module is ‘a piece of software’” and “‘is not so
precise. But what is more specific is exactly what they do.’” Pet. Reply 14–15
IPR2013-00302
Patent 7,986,426 B1

37

(quoting Ex. 1013, 110:4–7, 142:6–11). Further, Patent Owner admitted during the
hearing that the XNS Manual discloses the claimed functions (i.e., what the
modules do), as noted above. See supra quoting Tr. 43:17–44:5; Tr. 44:1–7. In
essence, the disclosed functions, which Patent Owner concedes that the XNS
Manual discloses, demarcate the claimed modules, because modules may overlap
in code or otherwise with other software. See supra Claim Construction.
Patent Owner makes a similar argument regarding the recited “process
module” in claim 5: “The fact that functions are performed does not necessarily
disclose that the functions are performed by a software module of the claimed
‘software application’.” PO Resp. 28. This basically acknowledges, similar to the
admission at the hearing, that the XNS Manual discloses the recited process
module functions (e.g., “applying additional functionality . . . to the data . . . as
[paper or the electronic input] is being copied”). Nevertheless, Patent Owner
argues that “XNS does not teach how cropping and scaling can be performed as a
document is being copied.” PO Resp. 28. This argument, in addition to ignoring
the admission, fails to acknowledge that claim 5 includes applying functionality to
the “electronic input” of data. The XNS Manual, through the GIS 150 (with the
GIS 150 Manual evidencing the inherent features of that particular scanner),
discloses cropping or scaling the “electronic input” as it is being “copied”––
transmitting the data from one location (e.g. a buffer) to another (e.g., a display)
amounts to copying it.
Moreover, according to the ’426 Patent, “[t]he Client Module presents the
electronic paper as it is being copied, and any relevant information related to the
input or output functions. . . . The counterpart to VC’s Client Module on a
conventional copier is the panel.” Ex. 1001, col. 71, ll. 4–12. This disclosure
implies that the functional phrase “presenting [data] . . . as [the data or electronic
IPR2013-00302
Patent 7,986,426 B1

38

input] is being copied” embraces the electronic copying existent in prior art
copiers, including the XNS copiers––tracking Patent Owner’s admission about
functionality during the hearing.
Patent Owner’s argument that Petitioner “relies on GIS 150 in alleging XNS
discloses a software application that includes a process module,” but “GIS 150
does not disclose an input module or an output module,” does not address
Petitioner’s separate showings regarding the modules. See PO Resp. 28. For
example, Patent Owner’s argument about input and output modules does not upset
Petitioner’s showing that GIS 150 discloses a process module, i.e., a user interface
that includes processes of cropping or scaling scanned images. See Pet. 20. In
addition to the description of modules and software supra, the GIS 150 scanner
includes the following separate functions, which correspond to input, client,
output, and process modules: User input, User output, Scanning, Image processing,
Compression, Storage, Ethernet, Diagnostics, and Error handling. Ex. 1003, 223.
Patent Owner also argues that the “XNS [Manual] does not teach a third-
party software application that can provide an input as it is managed by an input
module.” PO Resp. 25. Patent Owner focuses on Petitioner’s citation of the
“Kurzweil Intelligent Scanning System” (“Kurzweil”) as the claimed “third party
software application.” See Pet. 19. Patent Owner contends that “Kurzweil
includes hardware components for scanning documents, XNS does not disclose
that Kurzweil includes a software application,” and Kurzweil “is used to ‘exchange
information over telephone lines with users on the Internet.’” PO Resp. 26
(quoting Ex. 1002, 70). According further to Patent Owner, XNS “does not
disclose a software application that manages the input of Kurzweil.” Id.
Patent Owner’s arguments do not address the myriad of other types of
software that would be resident on workstations disclosed in the XNS Manual that
IPR2013-00302
Patent 7,986,426 B1

39

Petitioner relies upon. See Pet. 19 (citing Ex. 1002, 117, 120). For example, the
work stations on the XNS network can “send or receive mail messages and
documents.” Ex. 1002, 120. The arguments also are not clear or not
commensurate in scope with claim 5. Claim 5 requires “at least one input module .
. . managing the electronic input from at least one third-party software application.”
(Emphasis added to claim 5). As discussed above in Section II. B., Patent Owner
conceded at oral argument that the XNS Manual discloses all the claimed
functions. These conceded functions include managing data.
Patent Owner makes a parallel argument about an alleged lack of an output
module by asserting that “Kurzweil does not teach a third-party software
application that is managed by an input module and an output module of a software
application.” PO Resp. 27. Claim 5 requires “at least one output module . . .
managing the output of the data to the third-party software application.” The
phrase “the third-party software application” refers back to the antecedent phrase
in claim 5, quoted above, “at least one third-party software application.” The “at
least one” output and input modules need not manage data to and from the same
third party application, as Patent Owner’s argument implies, by referring to the
Kurzweil system. Patent Owner does not explain how the disclosed input and
output modules must manage data to and from the same third-party application. In
any event, the XNS protocol applications, disclosed as a service (i.e., software),
constitute input and output modules that manage data to and from the same third-
party device, such as most software resident on a workstation or server. In
addition, the Interactive Terminal Service, the Gateway Access Protocol, the 860
Gateway service, each send or receive mail messages or documents, or otherwise
communicate bi-directionally with third-party applications, including facsimile
IPR2013-00302
Patent 7,986,426 B1

40

devices (with software). See Pet. 19 (citing Ex. 1002, 14–17, 65–70, 112, 113,
117; Ex. 1008 ¶¶ 42–46).
Patent Owner’s argument that Kurzweil does not include software
contradicts its declarant: “Kurzweil is a discrete software program.” Compare PO
Resp. 27, with Ex. 2002 ¶ 111. In addition, Dr. Melen testifies that the “XNS
[Manual] describes managing input from non-Xerox hardware and software. For
example, the XNS supports input from the ‘Kurzweil Intelligent Scanning
System.’” Ex. 1008 ¶ 45.
The record supports both declarants who essentially agree that Kurzweil at
least includes software: “Kurzweil Intelligent Scanning System . . . not only scans
a document but converts it into textual rather than bit-map representation.”
Ex. 1002, 113. It takes a hardcopy and converts it into textual digital data. Id.
“[It] uses the 860 gateway service to connect to the internet . . . to store files on a
file server or mail them to a user for editing at a workstation.” Id. On this record,
skilled artisans would have recognized that “[i]ntelligent” character to textual
conversion, file transfers, and electronic mail service, over the internet, imply
software functions.
In addition to the showings discussed above regarding managing output to a
third-party application, Petitioner relies on sending data to “a Print Service for
printing,” and on sending output to facsimile devices. Pet. 19–20 (emphasis
omitted) (citing Ex. 1002, 112, 120; Ex. 1008 ¶¶ 42–46). Patent Owner argues that
a facsimile device may “not necessarily include a software application.” PO Resp.
26. To the contrary, based on the description of XNS above, skilled artisans would
have recognized that XNS connects to devices, including facsimile devices,
implementing application software protocols using firmware interfaces. See id.
(acknowledging that “XNS discloses compatibility with ‘any Xerox or non-Xerox
IPR2013-00302
Patent 7,986,426 B1

41

facsimile device’” (quoting Ex. 1002, 104–105)). In addition, a third-party
application is not limited to software.
Patent Owner also contends that the XNS Manual does not disclose
“managing output of data to a non-Xerox device,” another third-party software
application identified by Petitioner, as discussed above. See id. at 27. As Patent
Owner acknowledges, the XNS Manual describes services for communicating with
a variety of non-Xerox devices, which include software services. See id. at 26.
Sending data, including managing signals with the data, to and from such a
compatible device, is implicit in the teaching of compatibility. See Dec. on Inst. 15
(construing “managing”); Ex. 1008 ¶ 45 (describing managing facsimile data in the
XNS Manual (citing Ex. 1002, 105)).
Patent Owner also acknowledges that the “XNS enables effective integration
between individual hardware and software elements within XNS-compatible
products. Techniques are also provided within the XNS for bi-directional protocol
and format conversion, permitting other systems to achieve integration with XNS.”
PO Resp. 25 (emphasis omitted, Board emphasis added) (citing Ex. 1002, 16, and
discussing Pet. 19). Patent Owner argues that “[t]his does not necessar[il]y teach
‘third party applications.’” Id. Patent Owner fails to explain why “other systems,”
or “XNS-compatible” products, are not “third-party” applications. Moreover, even
if the term “third-party” implies another programmer or source, distinct from the
creator of the claimed “computer data management system” or the “software
application,” the term does not create a structural limitation in claim 5 that
distinguishes over the XNS Manual. At most, “third-party” is a product-by-
process limitation that does not alter the structure of the “third-party software.”
Moreover, the ’426 Patent specifically states that a “third-party” may create
one of the modules of the claimed invention: “The Client Module can be a GUI
IPR2013-00302
Patent 7,986,426 B1

42

that Imagination Software develops, or a third-party application that directly
communicates with the Server Module.” Ex. 1001, col. 79, ll. 49–51. This verifies
that a generic identifier (“third-party”) of a programmer who creates any software
that communicates with the claimed “computer data management system,” does
not structurally distinguish software made by the maker of the “computer data
management system.”
Patent Owner also argues that the XNS Manual does not disclose a server
module that communicates with other modules. PO Resp. 28. The argument is not
persuasive. As discussed above in connection with claim 1 and in the general
discussion of the XNS Manual, the XNS is based on servers with software
services, and servers basically “perform their assigned function,” and are
“programmed to perform the requisite functions,” including “filing, printing,
mailing, and external communications,” thereby communicating with other servers,
software, and devices, using XNS protocols in a distributed architecture, as
generally explained above. See Ex. 1002, 18–19 (“Servers and services”). Each
server software service constitutes a module according to the Claim Construction
section above.
Based on the foregoing discussion and the record evidence, Petitioner shows
by a preponderance of evidence that the XNS Manual anticipates claim 5.
Claim 6
Patent Owner contends that Petitioner does not establish that the XNS
Manual discloses “a list of said input, output, and process modules . . . being read
on startup,” as recited in claim 6. PO Resp. 31 (citing Ex. 1002, 149). Petitioner
asserts that XNS uses a “Clearinghouse” service that contains the list. See Pet. 21–
22 (discussing claims 6 and 10). Patent Owner maintains that the “XNS [Manual]
states that before a user can use the clearinghouse, the ‘user must first locate a
IPR2013-00302
Patent 7,986,426 B1

43

clearinghouse server.’” PO Resp. 31 (quoting Ex. 1002, 149). According to Patent
Owner, “[t]his suggests that the clearinghouse is used on demand . . . . This is the
opposite of reading a list on startup.” Id.
Patent Owner’s argument has merit. Petitioner does not explain
persuasively, if at all, how the XNS Manual discloses the claimed list being read
on start-up. Based on the foregoing discussion, Petitioner does not show by a
preponderance of evidence that the XNS Manual anticipates claim 6.
Claim 10
Claim 10 recites a list that is similar in scope to claim 6, expect claim 10
does not require the list to be read on start-up.
6
Patent Owner argues that claim 10
is “directed to a server module (which is part of a software application), that
maintains a list of input, output, and process modules.” PO Resp. 30. According
to Patent Owner, “there is no disclosure in [the] XNS [Manual] that demonstrates
maintaining a list of input modules or process modules.” Id. Patent Owner argues
that “a list of physical devices is not the same as a list of software modules of the
same software application.” Id.

6
Claims 6 and 10 recite “means for” limitations that are not at issue. Patent
Owner’s arguments are not directed to any specific “means for” clause recited in
claim 10. Patent Owner’s declarant, Mr. Weadock, states that the means-plus-
function limitations “will vary accordingly, depending on where the VC software
resides.” Ex. 2002 ¶ 34, ¶ 33 (noting that “[c]laim 10 discloses very similar
means-plus-function limitations” to claim 6). In other words, according to Mr.
Weadock, the disclosed structure corresponding to the means clauses includes the
various types of memory structure disclosed: “[T]he corresponding structure is the
memory for storing.” Id. ¶ 34. Mr. Weadock does not argue that claim 10 requires
specific algorithmic structure: “[T]he corresponding structure is the memory for
storing the Server Module code and the processor that executes the Server Module
code.” Id. ¶ 34. Petitioner has made a sufficient showing regarding claim 10. See
Pet. 9, 22–23; Dec. on Inst. 20–23. As discussed above, XNS discloses different
forms of memory and processors on servers, including workstations.
IPR2013-00302
Patent 7,986,426 B1

44

According to Patent Owner, the XNS Clearinghouse is used to locate
physical devices such as workstations and servers. Id. Patent Owner relies on the
following description in XNS that “[t]he clearing house is[] ‘[a]n XNS service that
provides a central repository for names, addresses and properties of system
resources, permitting XNS system elements (workstations, servers, etc.) to locate
them.’” Id. at 29–30 (quoting Ex. 1002, 156).
Contrary to Patent Owner’s arguments, claim 10 does not specify that the
input, output, or process modules are software modules, and the XNS Manual does
not limit the listed “resources” to hardware, even if the claimed modules are
software. Given that the modules have “counterparts” in prior art printer and
scanning devices, listing hardware on the system reasonably satisfies the input,
output, and process modules recited in claim 10 as part of a list. See Ex. 1002, 52.
In addition, or in the alternative, the XNS Clearinghouse service lists
services (software) and devices by name, because “address numbers are
unintuitive.” Id. at 50. Users can locate and access “specific resources . . . on the
network,” including a “communication service.” Id. at 49. As another example,
the XNS Manual discloses a “Help Service” software application, typically
available in workstations, which helps client users find services by querying the
Clearinghouse list based on descriptions in the list. See id. at 52. The
Clearinghouse provides a list of all objects, functioning as a “Yellow Pages-like
services”: “Client software can request a service in a standardized fashion, and
need not remember what named resources are available.” Id. (emphases added).
Claim 10 does not specify any function for the input, output, and process
modules recited. It specifies that the list must be “used by at least one module
object accessible by said server module.” These claimed input, output, and process
modules have “counterparts” in prior art printers and devices. Therefore, the
IPR2013-00302
Patent 7,986,426 B1

45

discussion of the modules in claim 5 applies, although the modules here are
broader, and may include the hardware “counterparts.” For example, the XNS
scanners or workstations, or software services thereon, constitute input modules;
printers, facsimile devices, or workstations, or software services thereon, constitute
output modules, other servers or services, including the user interface in scanners,
described in the XNS Manual, constitute process modules. The server module
reads on the Clearinghouse server, the map software therein, the client software
service (the “Help Service,” or “Client service”), the communication service, or
other services in the XNS system, including a number of application protocol
services. See Ex. 1002, 52, and the discussion supra of claim 5. Alternatively, any
of the software services, for example, the “Help service,” constitutes a process
module of claim 10. As noted, all “system resources” would be in listed by name,
including a “[g]eneric name,” in the Clearinghouse based on the record evidence.
See Ex. 1002, 50, 156.
Claim 10 does not specify whether the list is within the computer data
management system or the server in that system: “A computer data management
system including a server module comprising: . . . a list of input, output, and
process modules.” The XNS Manual’s Clearinghouse list may be distributed on
several servers, with copies thereof for redundancy (id. at 52), or, “on a small
network the Clearinghouse can co-exist with other services on a single system
server” (id. at 53). Therefore, claim 10 reads on the single or multiple server
Clearinghouse system.
Based on the foregoing discussion and record evidence, Petitioner shows by
a preponderance of evidence that the XNS Manual anticipates claim 10.
IPR2013-00302
Patent 7,986,426 B1

46

Claims 7 and 8
Claim 7 requires “wherein the server module includes at least one server
module application programmer interface.” Patent Owner argues that XNS does
not disclose the interface limitation. PO Resp. 32. Claim 7 depends from claim 5,
which recites “at least one server module.” Therefore, “the server module” in
claim 7 refers to one of the plurality of server modules that are in the set of “at
least one server module[s]” in claim 5.
Petitioner maintains that “Dr. Melen explains that at least one API is
inherent in XNS.” Pet. 21 (citing Ex. 1008 ¶ 35). According to Dr. Melen,
“numerous application programming interfaces exist between the programs
illustrated [in] FIG 2-4. Application programming interfaces are necessary in
order to link the various programs, layers, etc., so that they may interact as
described throughout the XNS disclosure.” Ex. 1008 ¶ 35.
Patent Owner responds that “an API used by a first software application to
communicate with a second software application does not necessarily disclose a
software module of a software application that includes an API.” PO Resp. 32.
Patent Owner also contends that the layers “may . . . fall outside the application
layer.” Id.
The former argument appears to rest on Patent Owner’s narrow
constructions of “module” and “application layer.” The latter argument does not
dispute that the application layer, or any of the layers, require an API. As
discussed above, all the protocol layers are involved in communications.
Therefore, Patent Owner’s arguments are not persuasive.
Moreover, Patent Owner provides a trade dictionary that includes a
definition of “Application Program Interface” as follows: “API. A set of
formalized software calls and routines that can be referenced by an application
IPR2013-00302
Patent 7,986,426 B1

47

program to access underlying network services.” Ex. 2009. The trade dictionary
defines “Application Programming Interface” as follows: “API. A set of functions
and values used by one program to communicate with another program or with an
operating system.” Id.
Although the ’426 Patent Specification does not specify what an
“application programmer interface” is, it admits that “[m]any, if not most, core
software technologies, such as OCR (Optical Character Recognition) or barcode
recognition, are designed and implemented using a ‘C’-language API (Application
Program Interface). The technology is often complex . . . .” Ex. 1001, col. 49,
ll. 45–49. Mr. Weadock testifies generally that “API’s are not ‘inherent’ in
software.” Ex. 2002 ¶ 120.
Mr. Weadock does not support his testimony regarding lack of inherency
with a persuasive, if any, explanation, whereas Dr. Melen’s testimony is supported
by admissions in the ’426 Patent and the trade dictionary. The record shows that
some form of at least a generic type of API is necessary for communication
between nodes or software services. XNS provides communication between
software services, including by using the protocol layers identified by Dr. Melen.
Mr. Weadock does not address with specificity the evidence that shows that an API
is necessary for at least one server software application (i.e., a server module) to
communicate with other servers and software in the XNS system. According to
the claim language, the server module with an API in claim 7 need not be the
server module “communicable” with the other modules in claim 5––it may be one
of the other “at least one server module[s].” Based on the foregoing discussion and
record evidence, Petitioner shows by a preponderance of evidence that the XNS
Manual anticipates claim 7.

IPR2013-00302
Patent 7,986,426 B1

48

The Decision to Institute outlines Petitioner’s showing with respect to claim
8, which depends from claim 7. See Dec. on Inst. 7–8. Patent Owner does not
argue claim 8 separately. However, Patent Owner argues a limitation recited in
claim 6 that is similar to a limitation recited in claim 8. See PO Resp. 30. That is,
Patent Owner argues that the XNS Clearinghouse server application only lists
hardware instead of software. See id. Claim 8 requires the list to include available
and currently used input, output, and server modules.
Petitioner maintains that Clearinghouse is a data base of objects, which
“correspond to devices and services available on the network.” See Pet. 22–23
(identifying lists of currently available and active modules). As discussed in
connection with claim 10, these XNS services reasonably correspond to software
resident on servers and software throughout the system, and the Clearinghouse
server or servers identifies all resources, including hardware and software services.
Based on the record evidence and arguments presented, Petitioner shows by
a preponderance of evidence that the XNS Manual anticipates claim 8.
3. Summary
Pursuant to the discussion above, Patent Owner generally argues that the
XNS Manual does not disclose related elements of claims 1, 2, 4–7, and 9–11.
Patent Owner does not present separate and distinct arguments for claims 3 and 8.
Considering the arguments and record evidence, we determine that Petitioner
demonstrates by a preponderance of the evidence that the XNS Manual anticipates
claims 1–5 and 7–11 of the ’426 Patent. See Pet. 13–23; Dec. on Inst. 23–28.
Petitioner does not demonstrate by a preponderance of the evidence that the XNS
Manual anticipates claim 6 of the ’426 Patent. Patent Owner’s acknowledgement
during the oral hearing that the XNS Manual discloses all the claimed functions
recited in claims 1–5, and Patent Owner’s demand letter, corroborate our
IPR2013-00302
Patent 7,986,426 B1

49

determination that Petitioner has shown by a preponderance of evidence that the
XNS Manual anticipates claims 1–5 and 7–11.
4. Salgado
Based on the finding of anticipation by the XNS Manual of claims 1–5 and
7–11, it is not necessary to reach the ground of anticipation of claims 1–5 and 7–11
by Salgado.
On the other hand, it is necessary to reach the ground of anticipation of
claim 6 by Salgado. As discussed above in connection with Patent Owner’s
arguments regarding claim 6, claim 6 requires “a list of said input, output, and
process modules . . . being read on startup.” PO Resp. 31. Patent Owner generally
asserts that Salgado does not disclose “a list of said input, output, and process
modules.” PO Resp. 41.
The Petition refers to the analysis of claim 10 to address the limitations in
claim 6. See Pet. 39. However, claim 10 does not recite the list “being read on
start-up,” and Petitioner does not address persuasively, if at all, the start-up
requirement. See Pet. 40. Petitioner does not show persuasively that Salgado
discloses the claimed list being read on start-up, as required by claim 6. Based on
the foregoing discussion, Petitioner does not show by a preponderance of evidence
that Salgado anticipates claim 6.
III. MOTION TO EXCLUDE
Patent Owner moves to exclude Dr. Melen’s testimony on re-direct during
his deposition. Paper 40. We do not consider any of the re-direct testimony,
rendering the motion moot. Therefore, we dismiss it.
IV. WEIGHT OF TESTIMONY
Patent Owner maintains that Dr. Melen’s “opinion regarding anticipation [by
the XNS Manual] should be given little to no weight.” PO Resp. 12. According to
IPR2013-00302
Patent 7,986,426 B1

50

Patent Owner, Dr. Melen “has not even considered the [XNS Manual] reference at
issue.” Id. at 11–12. Patent Owner relies on statements made by Dr. Melen during
cross-examination. See id. at 11 (discussing Ex. 2003). For example, Dr. Melen
answers “I don’t know,” to a question about whether, if in 1985, “there was a
single server module in XNS that performed the four functions of claim 6.” See
PO Resp. 9–11 (quoting and discussing testimony at Ex. 2013, 113–116).
Even if Patent Owner’s assertions raise doubt as to Dr. Melen’s use of the
XNS Manual to support his opinion that it anticipates claim 6, see id. at 9–12,
Patent Owner does not show how this translates to undermining Dr. Melen’s
opinion regarding the other claims. Throughout his analysis of the XNS Manual,
Dr. Melen’s declaration provides specific and accurate citations to the XNS
Manual (Ex. 1002), supporting his opinion and showing that he relies on the XNS
Manual’s disclosure. See Ex. 1008 ¶¶ 29–47. In addition, because Petitioner has
not shown that the XNS Manual or Salgado anticipates claim 6, Dr. Melen’s
opinion about claim 6 is not of significant consequence.
In reciprocal fashion, Petitioner maintains that “the Board should give no
weight to Mr. Weadock’s Declaration.” Pet. Reply 7–8. Mr. Weadock’s testimony
is not necessary to reach our decision with regard to claim 6, and we did not
consider it in reaching the decision about claim 6. Given the finding of
anticipation of claims 1–5 and 7–11, the issue is moot.
Nevertheless, as this Final Decision implies, we afforded Mr. Weadock’s
declaration and Dr. Melen’s declaration due weight in reaching the finding that the
XNS Manual anticipates claims 1–5 and 7–11.
V. CONCLUSION
Considering the record, including Petitioner’s showing in the Petition and
Patent Owner’s arguments and evidence, Petitioner has demonstrated by a
IPR2013-00302
Patent 7,986,426 B1

51

preponderance of the evidence that the XNS Manual anticipates claims 1–5 and 7–
11. Petitioner has not demonstrated by a preponderance of the evidence that the
XNS Manual or Salgado anticipates claim 6.
VI. ORDER
In consideration of the foregoing, it is hereby
ORDERED that claims 1–5 and 7–11 of U.S. Patent No. 7,986,426 are
unpatentable;
FURTHER ORDERED that Patent Owner’s Motion to Exclude Dr. Melen’s
testimony on re-direct is dismissed as moot; and
FURTHER ORDERED that, because this is a final decision, 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.

IPR2013-00302
Patent 7,986,426 B1

52

For Petitioner:

Michael Specht
Jason Eisenberg
H. Keeto Sabharwal
Dennis Varughese
Richard Bemben
STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C
mspecht-PTAB@skgf.com
jasone-PTAB@skgf.com
keetos-PTAB@skgf.com
dvarughe-PTAB@skgf.com
rbemben-PTAB@skgf.com

For Patent Owner:

Vivek A. Ganti
Scott Horstemeyer
N. Andrew Crain
THOMAS | HORSTEMEYER, LLP
vg@hkw-law.com
scott.horstemeyer@thomashorstemeyer.com
andrew.crain@thomashorstemeyer.com