Uniloc 2017 LLC

Patent Trials and Appeals Board

Apr 6, 2021

IPR2020-00023 (P.T.A.B. Apr. 6, 2021)

Trials@uspto.gov Paper No. 20
571-272-7822 Date: April 6, 2021

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

MICROSOFT CORPORATION,
Petitioner,

v.

UNILOC 2017 LLC,
Patent Owner.
____________

Case IPR2020-00023
Patent 6,467,088 B1
____________

Before SALLY C. MEDLEY, MIRIAM L. QUINN, and
SCOTT RAEVSKY, Administrative Patent Judges.

QUINN, Administrative Patent Judge.

JUDGMENT
Final Written Decision
Determining No Challenged Claims Unpatentable
35 U.S.C. § 318(a)

IPR2020-00023
Patent 6,467,088 B1

2
We instituted inter partes review pursuant to 35 U.S.C. § 314 to
review claims 1−4, 6−14, and 16−21 of U.S. Patent No. 6,467,088 B1 (“the
’088 patent”), owned by Uniloc 2017 LLC. We have jurisdiction under 35
U.S.C. § 6. This Final Written Decision is entered pursuant to 35 U.S.C.
§ 318(a) and 37 C.F.R. § 42.73. For the reasons discussed below, Petitioner
has not shown by a preponderance of the evidence that claims 1−4, 6−14,
and 16−21 of the ’088 patent are unpatentable.
I. BACKGROUND
A. Related Matters
The parties identify the following district court proceedings involving
the ’088 patent: Uniloc USA, Inc. and UNILOC Luxembourg, S.A. v. Apple
Inc., No. 1:18-cv-00296 (W.D. Tex.), filed April 9, 2018; Uniloc 2017 LLC
v. Microsoft Corporation, No. 8:19-cv-00956 (C.D. Cal.), filed May 20,
2019; and Uniloc USA, Inc. and Apple Inc., No. 6:19-cv-00532 (W.D. Tex.),
filed September 10, 2019. Pet. x; Prelim. Resp. 11−12; Paper 4, 2.
In addition to this Petition, the ’088 patent was also challenged by a
different party, Apple Inc., in IPR2019-00056 (“the Apple IPR”), which we
denied.
B. The ’088 Patent
The ’088 patent is directed to techniques for upgrading or
reconfiguring software and/or hardware components in electronic devices.
Ex. 1001, 1:6−9. The ’088 patent explains that prior art systems developed
for updating components of electronic devices rely on a central computer
IPR2020-00023
Patent 6,467,088 B1

3
system that tracks all software configurations for a number of remote
systems. Id. at 1:31−36. These prior art systems updated software by the
central computer transmitting patches to each of the remote systems. Id. at
1:39−42; see also id. at 2:4−10 (explaining that a distributed system
transmits patches to mobile units). Other known techniques for software
update involve assuming that each desktop computer has a set of resources
determined in accordance with a set of enterprise policies or a central server
maintaining a master list that is used to keep files on a remote device
updated to the latest version. Id. at 1:49−52, 1:60−65. According to the
’088 patent, all of the above techniques fail to avoid potential conflicts and
ensure compatibility because they do not account for interdependencies of
the resources required by the desktops or the files resident in the remote
devices. Id. at 1:41−45, 1:52−56, 1:65−2:3, 2:10−14.
The ’088 patent solves the problem by providing a list or listing, that
indicates “which of a set of software components supported by the manager
10 are known to work well together or are otherwise compatible.” Id. at
3:36−42. For instance, Figure 1 of the ’088 patent, reproduced below,
illustrates reconfiguration manager 10 that “includes a listing 16 of known
configurations, and a repository 18 of software components.” Id. at
3:27−29.

IPR2020-00023
Patent 6,467,088 B1

4

Figure 1, above, illustrates a reconfiguration manager 10 interacting
with an electronic device 12, also referred to as “Device X.” Id. at 3:14−16.
When reconfiguration manager 10 receives a request for an upgrade from
Device X, the request indicates that the device wants to upgrade to version
2.0 of software component A and includes a list of the components currently
on the device, i.e., version 1.1 of component A, version 2.0 of component C,
and version 2.3 of component B. Id. at 4:12−19. Reconfiguration manager
10 processes the request, and if appropriate, delivers the requested version
2.0 of software component A. Id. at 4:22−26. Processing the request
involves generating a potential upgrade configuration that will satisfy the
received request, and searching through a set of known “bad”
configurations. Id. at 4:62−66. A known “bad” configuration is indicated in
IPR2020-00023
Patent 6,467,088 B1

5
Figure 1 as a dashed line between components that are not compatible. Id. at
3:58−61. For example, “[t]he pair including version 1.8 of component A
and version 1.0 of component C is an example of a known bad
configuration.” Id. at 3:61−63.
If the upgrade configuration corresponds to a bad configuration, the
reconfiguration manager “attempts to find a set or sets of potential upgrade
configurations from a set of known good configurations.” Id. at 4:67−5:3.
A known “good” configuration is indicated in Figure 1 by a solid line
between a given pair of components indicating that the components work
well together or are otherwise compatible. Id. at 3:52−55.
C. Illustrative Claim
Petitioner challenges claims 1–4, 6–14, and 16–21 of the ’088 patent.
Pet. 2. The ’088 patent recites three independent claims: 1, 11, and 21.
Challenged claim 1, reproduced below, is illustrative of the recited subject
matter:
1. A processor-implemented method for controlling the
reconfiguration of an electronic device, the method comprising
the steps of:
receiving information representative of a reconfiguration
request relating to the electronic device;
determining at least one device component required to
implement the reconfiguration request;
comparing the determined component and information
specifying at least one additional component currently
implemented in the electronic device with at least one of a
list of known acceptable configurations for the electronic
device and a list of known unacceptable configurations for
the electronic device; and
IPR2020-00023
Patent 6,467,088 B1

6
generating information indicative of an approval or a denial of
the reconfiguration request based at least in part on the result
of the comparing step.

Ex. 1001, 6:43−59. We refer to the steps of claim 1 as the receiving step,
the determining step, the comparing step, and the generating step,
respectively.
D. Procedural History
Petitioner filed the Petition on October 11, 2019. Paper 2 (“Pet.”).
Patent Owner filed a Preliminary Response on January 22, 2020. Paper 6
(“Prelim. Resp.”). After considering the parties’ filings, we granted the
Petition and instituted inter partes review on all challenged claims and all
grounds asserted. Paper 7 (“Decision” or “Dec. on Inst.”).
During trial, Patent Owner filed a Patent Owner Response (Paper 10
(“PO Resp.”)) and Petitioner filed a Reply (Paper 11 (“Reply”)). Patent
Owner also filed a Sur-Reply. Paper 13 (“Sur-Reply”). We heard oral
argument on January 15, 2021, a transcript of which is filed in the record.
Paper 19 (“Tr.”).
E. Evidence of Record
Petitioner relies on the following references as prior art (Pet. 3):
1) Apfel: U.S. Patent No. 5,974,454, filed as Exhibit 1004;
2) Lillich: U.S. Patent No. 5,613,101, filed as Exhibit 1005;
3) Todd: U.S. Patent No. 5,867,714, filed as Exhibit 1006; and
4) Pedrizetti: U.S. Patent No. 6,151,708, filed as Exhibit 1007.
Petitioner further relies on the Declaration of John Villasenor to
support its patentability challenge. Ex. 1003 (“Villasenor Declaration”).
IPR2020-00023
Patent 6,467,088 B1

7
With the Reply, Petitioner filed the Supplemental Declaration of John
Villasenor. Ex. 1016 (“Second Villasenor Declaration”).
F. Grounds of Unpatentability
Petitioner asserts the following grounds of unpatentability (Pet. 3−4):
Claims Challenged 35 U.S.C. § References/Basis
1–4, 6–14, 16–21 § 103 Apfel, Lillich, Todd
9, 19 § 103 Apfel, Lillich, Todd, Pedrizetti
1–3, 9–13, 19–21 § 103 Apfel, Lillich
1, 3, 4, 6–11, 13,
14, 16–21 § 103 Apfel, Todd
II. ANALYSIS
A. Level of Ordinary Skill in the Art
Petitioner contends that a person of ordinary skill in the art at the time
of invention of the ’088 patent “would have had a Bachelor’s Degree in
Electrical Engineering, Computer Science, or a related subject, and one or
more years of experience working with configuring hardware and software
components in electronic devices” and that “[l]ess work experience may be
compensated by a higher level of education, such as a Master’s Degree, and
vice versa.” Pet. 16–17 (citing Villasenor Decl. ¶¶ 31−34). Patent Owner
“does not offer a competing definition because, even if it were appropriate to
apply Petitioner’s amorphous and varying definition for a POSITA,
Petitioner would still not meet its burden to prove unpatentability of any
challenged claim.” PO Resp. 11. Aside from this statement, Patent Owner
does not provide a specific reason for why Petitioner’s proffered level of
ordinary skill in the art is amorphous or otherwise inappropriate. Given the
IPR2020-00023
Patent 6,467,088 B1

8
lack of actual dispute regarding the appropriate level we adopt Petitioner’s
definition of the level of ordinary skill in the art, as it is consistent with the
level of skill in the art reflected in the prior art of record. See Okajima v.
Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001).
B. Claim Construction
In an inter partes review proceeding, a claim of a patent is construed
using the same standard used in federal district court, “including construing
the claim in accordance with the ordinary and customary meaning of [the]
claim as understood by one of ordinary skill in the art and the prosecution
history pertaining to the patent.” 37 C.F.R. § 42.100(b) (2019). The Petition
addresses three claim terms/phrases. Pet. 18−25. Two of the proposed
constructions (“list” and “known . . . for the electronic device”) are derived
from our preliminary claim construction in the Decision Denying Institution
in the Apple IPR. See Ex. 1012, 7−8. In its Preliminary Response, Patent
Owner “requests that the Board adopt the ordinary and customary meaning
of the claim term[s] as understood by one of ordinary skill in the art.”
Prelim. Resp. 15. In its Response, “Patent Owner submits that the Panel
here need not expressly construe any claim term in a particular manner in
order to arrive at the conclusion that the Petition is substantively deficient.”
PO Resp. 13. In our Decision on Institution, we adopted the following
preliminary claim constructions, based on Petitioner’s proposals (Dec. on
Inst. 8):
“list” any stored representation of information
indicative of component compatibility
“known . . . for the
electronic device”
The term “known” means “previously
determined” and the phrase “for the
IPR2020-00023
Patent 6,467,088 B1

9
electronic device” does not require that the
“list” of known acceptable and known
unacceptable configurations be specific to
the electronic device
“at least one of” To be read in accordance with the plain
meaning of the phrase, namely as
conjunctive lists of their respective
elements, i.e., “at least one of [a] and at
least one of [b].”

Other than to state that the meaning of these terms should retain their
plain and ordinary meaning, Patent Owner does not argue that adopting
these preliminary constructions constitutes error. Because there is no actual
dispute regarding these adopted claim constructions, and because our
Decision here does not depend on adopting any particular construction for
these terms, we adopt our preliminary claim constructions as final claim
constructions. We also determine that no other claim terms require an
express construction to resolve the issues presented by the patentability
challenges. See Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co.,
868 F.3d 1013, 1017 (Fed. Cir. 2017) (holding that only terms “that are in
controversy” must be construed and “only to the extent necessary to resolve
the controversy”).
C. Overview of the Prior Art
1. Overview of Apfel
Apfel is concerned with “[i]nstalling and updating a software program
module component.” Ex. 1004, Abstract. In particular, Apfel describes a
system for automatically updating a software program module component
stored on a computer, as shown in Figure 3 reproduced below.
IPR2020-00023
Patent 6,467,088 B1

10

Figure 3 of Apfel (above) illustrates a system including computer 20,
database server 80a, and package server 80b. Id. at 6:36−37. Computer 20
sends query 100 on or after a predetermined date over the Internet to
database server 80a. Id. at 6:39−40. Query 100 includes all of the
information regarding computer 20 that the database server 80a needs to
determine if an upgrade is available and, if an upgrade is available, to
determine the location of the upgrade package. Id. at 6:49−53. After
reviewing query 100, database server 80a returns response 105 over the
Internet to computer 20. Id. at 6:54−55. If an upgrade is available, then
database server 80a will send back response 105 that includes the Uniform
Resource Locator (URL) of the upgrade package. Id. at 6:63−65. After
computer 20 receives response 105 including the URL of the upgrade
package, computer 20 will send query 110 to package server 80b at the URL
of the update package. Id. at 7:4−8. Package server 80b will send update
IPR2020-00023
Patent 6,467,088 B1

11
package 115 to computer 20, and computer 20 will then install the update
package 115. Id. at 7:8−10. The servers are responsible for assessing
whether an upgrade is available and whether it should be downloaded based
on the information sent by computer 20. Id. at 7:13−16.
2. Overview of Lillich
Lillich is titled “Method and Apparatus for Determining at Execution
Compatibility Among Client and Provider Components Where Provider
Version Linked With Client May Differ From Provider Version Available at
Execution.” Ex. 1005, code [54]. Lillich describes a “method and apparatus
for verifying compatibility between components of a system[,] which share a
client-provider relationship.” Id. at Abstract. Figure 1 of Lillich is
reproduced below.

Figure 1 of Lillich (above) is a symbolic, simplified block diagram of
system 30. Id. at 5:28. As shown in Figure 1, “[s]ystem 30 may be
hardware, software, or a combination thereof, and includes client 32 and
provider 34 connected by . . . connector 36 such that information from the
IPR2020-00023
Patent 6,467,088 B1

12
client and provider can be compared.” Id. at 6:7−10. A provider indicator, a
current indicator of a provider, and a compatibility range are defined for
each of a client and a provider. Id. at 4:5–7. A provider indicator identifies
a particular type of provider. Id. at 4:7–8. A current indicator of a provider
specifies the version of the provider. Id. at 4:8–9. When a client is linked
with a version of a provider, the current indicator of that provider is stored in
the executable client produced, thereby identifying the version of the
provider, referred to as a “definition provider,” used to build the client. Id.
at 4:9–13. Lillich describes that the compatibility range for the client
identifies the range of versions of the provider, which can be used to execute
the client, i.e., which have an implementation which is compatible with the
definitions supplied by the definition provider. Id. at 4:13–16. The
compatibility range for the client specifies the oldest version of the provider
that can be used to execute the client. Id. at 4:17–19. The compatibility
range for the provider identifies the range of versions of the provider that
could be used to build a client capable of operating with the current version
of the provider. Id. at 4:19–22. The compatibility range for the provider
specifies the oldest version of the provider that could have been used to
build a compatible client. Id. at 4:22–25. The versions within each of the
two compatibility ranges are older than or equal in age to the current
version. Id. at 4:25–27. Lillich defines an “implementation provider” as
“the provider which will be used to execute the client.” Id. at 4:28–31.
Lillich further describes a connector for connecting, at runtime, the
client to the implementation provider to determine compatibility between the
client and the implementation provider. Id. at 4:28–32. Compatibility
IPR2020-00023
Patent 6,467,088 B1

13
checks are performed between a client and available versions of the
provider(s), implementation providers, with which it has been linked. Id. at
4:32–35.
3. Overview of Todd
Todd is titled “System and Method for Distributing Configuration-
Dependent Software Revisions to a Computer System.” Ex. 1006, code
[54]. Todd describes “a system for detecting and avoiding faults stemming
from conflicts in hardware and/or software configurations in a computer
system.” Id. at Abstract. Figure 1 of Todd is reproduced below.

IPR2020-00023
Patent 6,467,088 B1

14
Figure 1 of Todd (above) is a block diagram of system 100. Id. at
5:57−65. As shown in Figure 1, system 100 comprises computer system 110
and remote data source 130. Computer system 110 comprises “memory
device 112 to store current configuration data pertaining to the hardware and
software configuration of the computer system 110.” Id. at 6:7–9.
Computer system 110 also comprises processing circuitry 114, nonvolatile
memory 116, and communications circuitry 118. Id. at 5:66–6:41.
Computer system 110 also comprises configuration detection circuitry 120
responsible for obtaining data pertaining to at least a portion of the current
hardware and software configuration of the computer system 110. Id. at
6:42–46. Todd describes that the configuration detection circuitry 120 may
be as simple as a software program, executable within the computer system
110, for querying the user as to the current hardware and software
configuration. Id. at 6:46–49. However, Todd describes that configuration
detection circuitry 120 determines the hardware and software configuration
automatically, by polling hardware components and cataloging software
components to create a list of current configuration data setting forth the
components that comprise the computer system 110. Id. at 6:50–55. As
shown in Figure 1 of Todd, remote data source 130 contains a database of
software revisions that may be communicated to computer system 110 as a
function of the current configuration data transmitted from computer system
110 to remote data source 130 and diagnostic and analytic processes within
the remote data source 130 that analyze the current configuration data to
identify conflicts. Id. at 12:1–8.
IPR2020-00023
Patent 6,467,088 B1

15
D. Obviousness Grounds
The Petition challenges claims 1–4, 6–14, and 16–21 as obvious over
the combined teachings of Apfel, Lillich, and Todd. Pet. 26. Petitioner
further asserts two alternative obviousness grounds: (1) that claims 1−3,
9−13, and 19−21 would have been obvious over Apfel and Lillich (id. at
69−71); and (2) that claims 1, 3, 4, 6−11, 13, 14, and 16−21 would have
been obvious over Apfel and Todd (id. at 71−72). We address these grounds
together.
1. Issue
In this proceeding, a single issue has turned out to be dispositive,
which is whether Apfel’s disclosure of a database lookup (alone or in
combination with the teachings of Lillich) performs the comparing step
recited in the challenged independent claims. We determine that, based on
the full record before us, Petitioner has not shown by a preponderance of the
evidence that Apfel’s teachings support Petitioner’s contentions regarding
the comparing step.
2. Analysis
The claim is directed to a “reconfiguration of an electronic device.”
See Ex. 1001, 6:43−45. The method requires determining what component
is required to implement that reconfiguration. Id. at 6:51−50. Then the
system performs a comparison—the recited comparing step. Id. at 6:51−56.
That comparing step, as recited, states: “comparing the determined
component and information specifying at least one additional component
currently implemented in the electronic device with at least one of a list of
IPR2020-00023
Patent 6,467,088 B1

16
known acceptable configurations for the electronic device and a list of
known unacceptable configurations for the electronic device.” Id. Parsing
out this limitation, and for ease of reference, there are four pieces of
information that are required in the recited comparison: (a) a determined
component (i.e., the component that is required to implement the
reconfiguration request); (b) information specifying at least one additional
component currently implemented in the electronic device; (c) a list of
known acceptable configurations and (d) a list of known unacceptable
configurations.
Petitioner turns to Apfel as teaching the comparison of (a), (b), and
(c). For instance, the Petition asserts that Apfel inherently discloses the
claimed comparison:
In describing maintaining and performing a lookup against
a database of upgrade packages and corresponding
configurations which “should result in their download,” as well
as configurations that “require a [particular] upgrade package,”
Apfel inherently describes comparing the information provided
in the request for an upgrade and the additional system
information—including information specifying other
components—against a list of known acceptable configurations,
i.e., “configurations for the electronic device comprising sets of
multiple components previously determined to work well
together or be otherwise compatible.”
Pet. 42. In this passage, the Petition relies on an alleged inherent disclosure
of the comparing step. The Villasenor Declaration repeats this paragraph
verbatim with no additional explanation of how Apfel necessarily performs
the alleged comparison. Ex. 1003 ¶ 85. Patent Owner repeatedly argues that
Apfel’s disclosure does not support this theory of inherency. See PO Resp.
IPR2020-00023
Patent 6,467,088 B1

17
16−17, Sur-Reply 3−4. In particular, Patent Owner argues that Apfel’s
database lookup does not include the determined component (information (a)
in the above description of the comparing step). Id. at PO Resp. 16−17.
Further, Patent Owner argues that Apfel’s database lookup only determines
that “a new upgrade is available”—not that there is a “known compatible
upgrade” available. Sur-Reply 5. We agree with Patent Owner’s arguments.
We first turn to an analysis of Apfel’s database lookup. Apfel’s
computer initiates a Hyper Text Transfer Protocol (HTTP) query. Ex. 1004,
8:39−41. This query includes an Internet address and appended setup
information. Id. at 8:44−53. That appended information identifies
“information needed to determine which upgrade package URL is required
by [the] computer.” Id. at 8:53−55. Specifically, the information includes
the version of the “program module components to be upgraded, the
platform that the program module components are running on, and the
language of the program module components.” Id. at 8:55−60. For
instance, Apfel provides a query with specific information for the system to
determine if an upgrade is available.

Id. at 9:1−5. The HTTP query shown above identifies the version of the
word processor program module (Version 8.0), the version of the Web
Authoring Component program module (Version 3.0), the localization
language (English), and the type of operating system on the computer
IPR2020-00023
Patent 6,467,088 B1

18
(Windows). Id.; see also id. 8:60−67. If this query is successfully received
by Apfel’s database server, “it is determined whether there is an upgrade
package for the Web Authoring Components program module.” Id. at
9:28−32. Specifically, using a database lookup, the database server “uses
the information received in the HTTP query . . . to determine if an upgrade
package is available.” Id. at 9:32−35.
From this discussion of Apfel, and the parties seem to agree, we
understand that Apfel’s database server does perform a comparison. See
also id. at 12:45−48 (describing that “determining whether an upgrade
package for the software program module component is available comprises
comparing the database query to a database lookup table”); Tr. 9:2−22,
25:1−9. Apfel’s comparison, however, is between the information presented
in the query and the lookup table. Ex. 1004, 9:32−35; see also id. at
12:45−48, Tr. 10:19−12:8 (discussion about the comparison between the
query and the lookup table). The program module versions identified in the
query all pertain to versions of components currently installed in the
computer. See id. at 6:49−53 (stating that the query “includes all of the
information regarding computer 20 that the database server 80a needs to
determine if an upgrade is available . . . .” (emphases added)). Thus, there is
no “determined component” in Apfel’s query. Using the database lookup,
Apfel then determines whether a component is available for upgrade. Id. at
9:30−32; Ex. 1003 ¶ 80 (Villasenor, citing Ex. 1004, 9:30−35, opining that
Apfel describes performing a database lookup to determine the
component(s) needed to perform the requested upgrade). Thus, it is after the
IPR2020-00023
Patent 6,467,088 B1

19
database lookup that a “determined component” may be obtained. See, e.g.,
id. at 6:54−55 (stating that “[a]fter reviewing query 100, the database server
80a returns a response 105 over the Internet to the computer 20.” (emphasis
added)). To illustrate this point, and by way of example, after receiving the
query reproduced above, Apfel’s database server may determine that there is
a new version of the Web Authoring Component program module, say
version 4.0. We do not see how Apfel further discloses comparing this
newer version (i.e., the determined component) with information (b) and (c)
of the comparing step. In other words, Apfel lacks detail sufficient to
explain that the database lookup involves further comparing the resulting
newer version component with the query information that identifies
currently installed components (such as the “Word 8.0” version) and with a
known list of acceptable configurations.
On this point, Petitioner relies on a general description of Apfel’s
database servers. Pet. 41 (citing Ex. 1003 ¶ 83). That passage states that
“[d]ifferent update packages may be provided for different version
combinations.” Ex. 1004, 9:36−38. The passage continues, “[t]hus, the
database server 80a maintains a database of upgrade packages and
corresponding configurations which should result in their download.” Id. at
9:38−40. Patent Owner argues that this passage uses indecisive language
(i.e., “should”) that falls short of the required factual support for a theory of
inherency. PO Resp. 17; Sur-Reply 3−4. Petitioner argues that the “should
result” language denotes a user choice—that Apfel has already determined
compatibility and that because of the injection of user’s choice to download,
the result of an actual download is uncertain, but “should” occur. Reply 6.
IPR2020-00023
Patent 6,467,088 B1

20
These arguments highlight the deficiency in Petitioner’s case. The passage
Petitioner relies on merely describes what the database lookup provides—the
determination of an upgrade package based on the given query. It does not
explain that the database lookup, in addition to determining that a new
upgrade is available, also determines that the available upgrade is
compatible with the current configuration of the electronic device.
We agree with Petitioner that the database server of Apfel maintains
upgrade packages and corresponding configurations that should be
downloaded. The database, however, is a “lookup table” (see Ex. 1004,
12:45−48; Ex. 1003 ¶ 81). And neither Petitioner nor Mr. Villasenor explain
the content of this lookup table or the details of the Apfel comparison such
that we could conclude that Apfel necessarily performs the comparison
between the determined component, a component currently installed, and the
required list of known acceptable configurations, as the claim requires.
“Inherency . . . may not be established by probabilities or possibilities.”
PAR Pharm., Inc. v. TWI Pharm., Inc., 773 F.3d 1186, 1195 (Fed. Cir.
2014). “The mere fact that a certain thing may result from a given set of
circumstances is not sufficient.” Id. (emphasis added).
Moreover, our understanding, in light of the arguments and evidence
on the full record, is that Apfel’s comparison of the query with the lookup
table merely yields the identification of a program module version that
should be installed. See Ex. 1004, 9:30−35. To illustrate our understanding,
and following our previous example of the disclosed query, Apfel may
determine that there is a new version of the Web Authoring Component
program module by looking up on the table an entry for version Word 8.0, in
IPR2020-00023
Patent 6,467,088 B1

21
English, and identifying the latest version available of the program module
as IAVer=4.0. See id. at 2:38−41 (“The database server can determine
whether an upgrade package for the software program module component is
available by performing a database lookup using the information included in
the database query.”); see also id. at 8:60−9:7 (identifying an exemplary
query including the current version of the Web Authoring Components
program module), 9:32−35 (stating that the database server uses the
information received in the HTTP query to determine if an upgrade package
is available, such as by database lookup), 12:45−48 (disclosing “comparing
the database query to a database lookup table”). A comparison of the
version in the query (3.0) with the version in the database (4.0) would result
in the determination that a newer version is available at step 427 of Apfel’s
Figure 4A. See, e.g., id. at 12:45−48. As we understand Apfel, no further
comparisons would be needed (nor does the Petition point to a further
comparison in Apfel’s database lookup) in order for Apfel to retrieve the
URL corresponding to the download address of the newer component. Thus,
Petitioner has failed to show that the mere disclosure of a database lookup,
and thus a comparison with the query, necessarily means that Apfel has
performed a compatibility determination in the manner claimed: by making
a comparison between (a) the determined component, (b) the currently
implemented component, and (c) the list of known acceptable
configurations.
Petitioner further argues that Apfel provides different URLs for the
different upgrade packages required. For instance the Petition states, “[n]ot
IPR2020-00023
Patent 6,467,088 B1

22
only are there certain upgrades that ‘should’ be installed, but certain
computer configurations, according to Apfel ‘require’ certain upgrade
packages.” Pet. 42 (citing Ex. 1004, 6:65−67). The passage of Apfel relied
on and the argument presented still do not explain how Apfel discloses that
it compares the (a) determined component, (b) currently implemented
component, and (c) list of known acceptable configurations. The passage
states that, “[i]t should be understood that each configuration of computer 20
may require a different upgrade package and, therefore[] a different URL.”
Ex. 1004, 6:65−67. This passage, rather, confirms that the query (which
reflects the current configuration of the computer) is the information that
Apfel’s database lookup uses to identify whether a version of the Web
Authoring Component program is available for download. For instance, if
the query identified that the localization language was Spanish, then the
lookup table would index to another record and retrieve a different URL for
the Spanish version of the Web Authoring Component program. But, again,
Apfel describes this lookup for identifying the latest component that is
available for download. That Apfel may have URLs for each version of the
Web Authoring Component does not transform Apfel’s lookup into the
recited comparison. Indeed, Apfel explains that because it identifies the
appropriate version of the component for computer 20, using the lookup, the
server would not allow the download of versions that do not match the query
information sent by the computer. See, e.g., Ex. 1004, 7:13−19 (stating that
Apfel would not allow the download of a version of the Web Authoring
Component program that is incompatible with computer 20), 2:38−42.
IPR2020-00023
Patent 6,467,088 B1

23
a. Petitioner’s Alternative Argument
The Petition further states that “[a]lternatively, even were it not
considered to be inherently disclosed, Apfel’s teaching implicitly suggests
maintaining such ‘known good’ configuration information in some forms so
that a determination can be made which update package URL (if any) to
send to the requesting computer.” Pet. 42; Reply 18 (arguing that Apfel
discloses servers that check for compatibility and that “Apfel either
inherently discloses or implicitly suggests doing so using a list”). Mr.
Villasenor’s opinion repeats verbatim this alternative contention with no
further explanation. Ex. 1003 ¶ 85. Petitioner’s argument seems to be that
Apfel maintains (c) the list of known acceptable configurations in some form
as suggested by the disclosure of having distinct URLs for the available
configurations. But the issue is not whether Apfel’s database may comprise
a list with the various URLs corresponding to the versions of the Web
Authoring Component. The issue is that the comparison Petitioner claims
that Apfel performs is a lookup of the information in the query—which does
not include (a) the determined component. The query contains the
information of components installed in the device. And, as stated above, the
database lookup results in (a) the determined component—the Web
Authoring Component program module that is available for download.
Petitioner admits, and we agree, that the database lookup results in the
(a) determined component when it argues, for the determining limitation,
that Apfel’s database lookup performs this step. Pet. 37−38. For instance,
the Petition states that “Apfel describes performing a database lookup to
determine the component(s) needed to perform the requested upgrade.” Id.
IPR2020-00023
Patent 6,467,088 B1

24
at 38 (citing Ex. 1004, 9:30−35). Petitioner also relies on the passage
alluded to earlier that Apfel provides a different update package “depending
on the configuration of the computer requesting the update.” Id. (citing
Ex. 1004, 9:30−42). The Petition, however, goes a step further and relies on
the same passage describing whether the component is available to also
disclose, imply, or suggest that Apfel performs the comparing step. Id. at 41
(citing Ex. 1004, 9:30−42). As we have already explained, that contention is
not supported by a plain reading of Apfel, and the testimony of Dr.
Villasenor on this point does not persuade us otherwise, as it is conclusory
and is also unsupported by Apfel’s disclosure.
On Reply, Petitioner argues that “when it is determined that an
upgrade should be installed, it is a precondition in Apfel that the upgrade be
compatible with the configuration of the destination computer, as Dr.
Villasenor explains.” Reply 9−10 (citing Ex. 1016 ¶¶ 27−29). Again, this
argument is unpersuasive. Apfel does not disclose any “precondition,” and
Dr. Villasenor does not explain how a reading of Apfel would lead a person
of ordinary skill in the art to such an understanding. See also, Tr.
52:17−53:1 (Petitioner identifying paragraph 24 of the Second Villasenor
Declaration as including a detailed explanation of how Apfel would perform
the compatibility check); but see Ex. 1016 ¶ 24 (stating that the key
disclosure in Apfel is the “yes” output from box 427 in Figure 4A of a
“known compatible upgrade” without further explanation). On this point,
the Second Villasenor Declaration (paragraphs 27−29) is a verbatim copy of
the Reply. There is no factual or technical explanation of how Apfel would
IPR2020-00023
Patent 6,467,088 B1

25
have performed both steps of determining and comparing with the single
database lookup that Apfel discloses. To imply that after determining the
availability of a program some compatibility check has been performed
requires some anchor in Apfel other than the use of the word “should” in a
sentence that refers to whether a user of the computer receives a prompt that
an update is ready for download.
We recognize that in our Decision on Institution we determined a
reasonable likelihood of prevailing because of the Petition’s reliance on
Apfel’s description of a “corresponding configuration.” Dec. on Inst. 17
(citing Ex. 1004, 9:36−40). On a full record, however, having had the
benefit of a full development of the arguments by both parties, we do not
read Apfel’s passage in column 9 to suggest that Apfel’s database server
determines if the upgrade “should” be downloaded, i.e., the server making a
qualitative decision regarding the compatibility of the program with the
requesting computer. Rather, column 9, as explained earlier, refers to the
overall operation of the database server with regard to maintaining the
database of upgrade packages and corresponding configurations. Ex. 1004,
9:36−40. Whether the upgrade package that is determined to be available at
step 427 “should result in their download” is a result of the database lookup
determining the URL for the entry matching the query request and then
providing that URL to the user. See id. at 6:63−65, 7:4−8; see also id. at
8:53 (“The query is structured to identify the information needed to
determine which upgrade package URL is required by computer 20.”).
From that point forward, the database server has no further control over
whether the upgrade package will be downloaded by the user, ergo the
IPR2020-00023
Patent 6,467,088 B1

26
phrase “should result in their download,” because it depends on whether the
user actually accepts the invitation to download the package. See id. at
10:11−33. The passage on “corresponding configurations” does not convey
that the database server makes two determinations, as Petitioner contends,
that (1) there is a program available for upgrade, and (2) such a program is
compatible with the computer using the recited comparison. In any event,
the claims require the comparison between the three recited components, and
neither the Petition nor Villasenor’s testimony explain how Apfel would
perform the disclosed database lookup with (a) the determined component.1
b. Petitioner’s Reliance on Lillich
Petitioner relies on Lillich as disclosing a compatibility range, as
evidence of the “known acceptable configurations” that would have been
used with Apfel’s database lookup. Pet. 42−45; Tr. 15:1−16:7 (adding that
Lillich “provides additional implementation details about at least one way
that list could be set forth and a way that clearly would satisfy the claims,
namely looking at known acceptable ranges of components that work well
together”). For instance, Petitioner asserts that Lillich teaches the
comparison with “known acceptable configurations” because Lillich uses a
compatibility range that allows it to assess whether the configuration of the

1 In this respect we are not persuaded by the belated argument during the
hearing in which Petitioner alluded that “there may be multiple database
lookups.” Tr. 52:4−16. Such a contention has no support in the record. Nor
is there any support in Apfel, the Petition, or the proffered testimony that the
database lookup would involve determining compatibility by comparing the
newer version with the versions of currently installed components and a list
of acceptable known configurations. Id.
IPR2020-00023
Patent 6,467,088 B1

27
provider software is compatible with the client software. Pet. 42−45 (citing
Ex. 1005, 1:41−44, 3:66−4:27; Ex. 1003 ¶¶ 86−89).
Reliance on Lillich, however, does not cure the deficiency we have
noted above with regard to Apfel. That is, Lillich is not relied on for
teaching the comparison that includes the (a) determined component. Tr.
16:8–13. Rather, as the Petition makes clear, Apfel’s lookup would be
modified “to consider the version numbers of the various clients and
providers.” Pet. 44. According to the Petition, the modified lookup would
result in considering the versions of the “Web Authoring Components
program module 37a,” “the HTML converter,” and or “the word processor
program module” of Apfel’s query components, to determine whether they
are within an appropriate range. Pet. 44. In other words, the Apfel lookup
would be modified only in providing Lillich’s range of versions. Id. As we
understand Petitioner’s theory, the resulting comparison of Apfel’s query
and the database record would consider whether a Web Authoring
Component version is within an acceptable range of compatibility with the
installed word processor program, for example Word 8.0. See, e.g., Ex.
1004, 3:34−46 (explaining that Apfel checks for available upgrades of the
Web Authoring Components of the Word 8.0 program module). However,
the Petition does not explain how Apfel would perform the lookup to
determine whether the latest version of a component (“device component
required to implement the reconfiguration request” or “the determined
component”), currently not installed, would then be further compared with
Lillich’s compatibility range. This is missing from Petitioner’s contention,
because, as Patent Owner correctly points out, the comparison in Lillich
IPR2020-00023
Patent 6,467,088 B1

28
(whether using the Apfel lookup procedure or not) is a comparison of
components that are already installed in the computer. PO Resp. 22−24
(relying on Ex. 1005, 3:66−4:27, 5:33−34, 5:38−39, 6:44−45, Figs. 3, 5).
Petitioner’s reliance on Lillich, therefore, has not cured the failure to show
that either Apfel or Lillich determines a device component required to
implement the reconfiguration request ((a) the determined component) that
is further compared with (b) the additional component currently
implemented and (c) the list of known acceptable configurations.
Because we determine that Petitioner has not shown by a
preponderance of the evidence the recited comparing step with regard to the
known acceptable configurations (hence the combination of Apfel and
Lillich), we need not determine whether Petitioner has shown whether the
combination with Todd (regarding the comparison with the list of known
unacceptable configuration) is sufficient. We note here that Petitioner took
the position that the claim requires, because of the conjunctive “at least one
of,” a comparison with both a list of known acceptable configurations and a
list of known unacceptable configurations. Pet. 23−25 (arguing that the
claim language and Specification of the ’088 patent supports the proposed
claim construction, which is undisputed on the full record). Therefore,
having found that Petitioner has not shown by a preponderance of the
evidence that the prior art teaches the required comparison with one list, then
there is no need to consider the alternative contention presented in the
Petition in which only a comparison with the list of known unacceptable
configurations would have been determined. See Pet. 69−72; see also PO
IPR2020-00023
Patent 6,467,088 B1

29
Resp. 28−29 (addressing the alternative contention in which the claim would
perform the comparison with one of the two recited lists, but arguing that the
deficiencies would not be cured by this alleged interpretation).
Consequently, we determine that Petitioner has not shown by a
preponderance of the evidence that claim 1 would have been obvious over
Apfel in view of Lillich and Todd; Apfel in view of Lillich, or Apfel in view
of Todd. Claims 11 and 21 recite the comparing step in substantially similar
scope to that of claim 1, therefore, Petitioner has not met its burden as to
those claims either. Because of their dependency on the challenged
independent claims, dependent claims 2, 3, 6, 7, 12−14, 16−18, and 20 have
also not been shown to be unpatentable as asserted by Petitioner.

E. Obviousness Ground Based on Apfel, Lillich, Todd, and Pedrizetti
Petitioner argues that Pedrizetti teaches the limitations recited in
claims 9 and 19. Pet. 64−70. Patent Owner does not argue the patentability
of claims 9 and 19 apart from their parent independent claims.
1. Overview of Pedrizetti
Pedrizetti is titled “Determining Program Update Availability via Set
Intersection Over a Sub-Optical Pathway.” Ex. 1007, code [54]. Pedrizetti
describes a method of updating software on a client computer wherein a set
of software programs on the client computer is compared against “a set of
updates on a server computer to determine which updates are applicable and
should be transferred from the server to the client.” Id. at 1:41–45. “A
many-to-one mapping function (e.g. a hash function) is applied to update
identifiers to generate a table of single bit entries indicating the presence of
IPR2020-00023
Patent 6,467,088 B1

30
particular updates on the server.” Id. at 1:45–48. Figure 1 of Pedrizetti is
reproduced below.

Figure 1 of Pedrizetti (above) depicts a “basic configuration of a client
and server.” Id. at 2:55. As shown in Figure 1, “server computer 100 is in
communication with . . . client computer 102 over a communications
pathway 104.” Id. at 2:57–58. Associated with both server 100 and client
102 are databases 106, 108, containing information regarding program
modules that may be updated. Id. at 2:66–3:1. On the server 100 side,
database 106 contains entries 110 regarding each updateable program
module, where each entry contains data 112 including the module name and
related tracking information. Id. at 3:6–9. On the client 102 side, database
108 corresponds to server database 106 in that it also contains entries 116
regarding each updateable program module, where each entry contains data
118 including the module name and related tracking information. Id. at
3:18–23. Client computer database 108 might only track entries for program
IPR2020-00023
Patent 6,467,088 B1

31
modules corresponding to programs 122 already installed on client computer
102. Id. at 3:25–28.
2. Analysis
Claims 9 and 19 recite “wherein the reconfiguration request comprises
a request for an upgrade of at least one of a software component and a
hardware component of the electronic device.” Ex. 1001, 7:37−40, 8:42−45.
Petitioner relies on Pedrizetti as teaching this limitation. In particular,
Petitioner points out that Pedrizetti performs software updates as well as
hardware updates. Pet. 67−68 (citing Ex. 1007, 1:41−65, 5:37−45,
5:60−65). Thus, Petitioner argues, it would have been obvious to include in
Apfel’s request an upgrade request for an associated hardware component
because “it is common for software and hardware components to work in a
complementary manner in electronic devices.” Id. at 69 (citing Villasenor
Decl. ¶¶ 138−139).
The argument and evidence presented by Petitioner do not attribute to
Pedrizetti as teaching what we found lacking in Apfel, namely the required
comparison of (a) the determined component with the other information
required in the comparing step. The reliance on Pedrizetti, therefore, does
not cure the deficiencies noted above with regard to Apfel. Indeed, we
determine that the combination with Pedrizetti would result in Apfel
determining merely that a new “hardware component” would either be
available or not available, but not that there is a comparing step that further
determines the compatibility of the available hardware component by
performing the recited comparison (read here of the (a) determined
component) with the currently installed components and required lists, as
IPR2020-00023
Patent 6,467,088 B1

32
such a comparison has not been shown to be taught by either Apfel or
Lillich.
Consequently, we determine that Petitioner has failed to show by a
preponderance of the evidence that claims 9 and 19 would have been
obvious over Apfel, Lillich, Todd, and Pedrizetti.

III. CONCLUSION
We have determined that Petitioner has not shown by a preponderance
of the evidence that the challenged claims are unpatentable.

Claims 35 U.S.C. § Reference(s)/Basis
Claims
Shown
Unpatentable
Claims
Not shown
Unpatentable
1−4,
6−14,
16−21
103 Apfel, Lillich,
Todd
1−4, 6−14,
16−21
9, 19 103 Apfel, Lillich,
Todd, Pedrizetti
9, 19
1−3,
9−13,
19−21
103 Apfel, Lillich, 1−3, 9−13,
19−21
1, 3, 4,
6−11, 13,
14,
16−21
103 Apfel, Todd 1, 3, 4, 6−11,
13, 14, 16−21
Overall
Outcome
1−4, 6−14,
16−21
IPR2020-00023
Patent 6,467,088 B1

33
IV. ORDER
Accordingly, it is hereby:
ORDERED that claims 1−4, 6−14, 16−21 of the ’088 patent have not
been proven to be unpatentable;
FURTHER ORDERED because this is a Final Written Decision,
parties to this proceeding seeking judicial review of the Decision must
comply with the notice and service requirements of 37 C.F.R. § 90.2.

IPR2020-00023
Patent 6,467,088 B1

34
PETITIONER:

Derrick W. Toddy (Lead Counsel)
Andrew M. Mason
John M. Lunsford
Todd M. Siegel
KLARQUIST SPARKMAN, LLP
derrick.toddy@klarquist.com
andrew.mason@klarquist.com
john.lunsford@klarquist.com
todd.siegel@klarquist.com

PATENT OWNER:

Ryan Loveless (Lead Counsel)
Brett Mangrum
James Etheridge
Jeffrey Huang
ETHERIDGE LAW GROUP
ryan@etheridgelaw.com
brett@etheridgelaw.com
jim@etheridgelaw.com
jeff@etheridgelaw.com