`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`
`_________________
`
`Case IPR2020-00023
`U.S. Patent No. 6,467,088
`_________________
`
`PETITIONER’S NOTICE OF APPEAL
`
`
`
`
`
`
`
`IPR2020-00023
`Patent No. 6,467,088
`
`Director of the United States Patent and Trademark Office
`c/o Office of the General Counsel
`United States Patent and Trademark Office
`P.O. Box 1450 Alexandria, VA 22313-1450
`
`
`NOTICE IS HEREBY GIVEN that, pursuant to 35 U.S.C. §§ 141(c) and 142
`
`and 37 C.F.R. § 90.2, Petitioner Microsoft Corporation (“Microsoft”) appeals to the
`
`United States Court of Appeals for the Federal Circuit from the Patent Trial and
`
`Appeal Board Final Written Decision dated April 6, 2021 (Paper 20, “Decision”) in
`
`IPR2020-00023, and all prior and interlocutory rulings related thereto or submitted
`
`therein. A copy of the Decision is attached hereto as Exhibit A.
`
`In accordance with 37 C.F.R. § 90.2(a)(3)(ii), Microsoft states that the issues
`
`on appeal include, but are not limited to: the Board’s determination that Microsoft
`
`did not show by a preponderance of the evidence that claims 1−4, 6−14, and 16−21
`
`of the ’088 patent are unpatentable, any finding or determination supporting or
`
`related to these issues, and all other issues decided adversely to Microsoft in any
`
`orders, decisions, rulings, and opinions entered in IPR2020-00023.
`
`Pursuant to 37 C.F.R. § 90.3, this Notice of Appeal is timely, having been
`
`duly filed within 63 days after the date of the Final Written Decision.
`
`Pursuant to 35 U.S.C. § 142 and 37 C.F.R. § 90.2(a), this Notice is being filed
`
`with the Director of the United States Patent and Trademark Office, the Patent Trial
`
`1
`
`
`
`and Appeal Board, and the Clerk’s Office for the United States Court of Appeals for
`
`IPR2020-00023
`Patent No. 6,467,088
`
`the Federal Circuit.
`
`
`
`Dated: June 8, 2021
`
`
`
`Respectfully submitted,
`
`
`
`By: /Andrew M. Mason/
`Andrew M. Mason (Reg. No. 64,034)
`KLARQUIST SPARKMAN, LLP
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Tel: 503-595-5300
`Fax: 503-595-5301
`
`Counsel for Petitioner
`
`2
`
`
`
`IPR2020-00023
`Patent No. 6,467,088
`
`CERTIFICATE OF SERVICE
`
`The undersigned certifies that on June 8, 2021, a true and correct copy of
`
`PETITIONER’S NOTICE OF APPEAL was:
`
`(1) Electronically filed through PTAB E2E;
`
`(2)
`
`Filed by Priority Mail with the Director of the United States Patent and
`
`Trademark Office at the following address:
`
`Office of the Solicitor
`United States Patent and Trademark Office
`Mail Stop 8, PO Box 1450
`Alexandria, VA 22313-1450
`
`Filed in the U.S. Court of Appeals for the Federal Circuit using the
`
`(3)
`
`Court’s CM/ECF filing system and pay.gov to pay the filing fee;
`
`(4)
`
`Provide a courtesy copy via electronic mail to the following attorneys
`
`of record for the Patent Owner listed below:
`
`Brett Mangrum – Lead Counsel
`brett@etheridgelaw.com
`Jeffrey A. Stephens – First Back-up Counsel
`jstephens@etheridgelaw.com
`Ryan Loveless – Back-up Counsel
`ryan@etheridgelaw.com
`James Etheridge – Back-up Counsel
`jim@etheridgelaw.com
`Jeffrey Huang – Back-up Counsel
`jeff@etheridgelaw.com
`Etheridge Law Group
`2600 E. Southlake Blvd., Ste. 120-324
`Southlake, TX 76092
`
`
`3
`
`
`
`IPR2020-00023
`Patent No. 6,467,088
`
`
`
`
`By /Andrew M. Mason/
`Andrew M. Mason (Reg. No. 64,034)
`KLARQUIST SPARKMAN, LLP
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Tel: 503-595-5300
`Fax: 503-595-5301
`
`Counsel for Petitioner
`
`
`
`
`
`4
`
`
`
`EXHIBIT A
`
`EXHIBIT A
`
`
`
`Trials@uspto.gov
`571-272-7822
`
`Paper No. 20
`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
`
`
`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
`2
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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.
`
`
`3
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`
`
`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
`4
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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;
`information
`comparing
`the determined component and
`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
`
`5
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`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”).
`6
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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. §
`1–4, 6–14, 16–21
`§ 103
`9, 19
`§ 103
`1–3, 9–13, 19–21
`§ 103
`1, 3, 4, 6–11, 13,
`§ 103
`14, 16–21
`
`References/Basis
`Apfel, Lillich, Todd
`Apfel, Lillich, Todd, Pedrizetti
`Apfel, Lillich
`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
`7
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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
`The term “known” means “previously
`determined” and the phrase “for the
`8
`
`“known . . . for the
`electronic device”
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`“at least one of”
`
`electronic device” does not require that the
`“list” of known acceptable and known
`unacceptable configurations be specific to
`the electronic device
`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
`Overview of Apfel
`1.
`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.
`9
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`
`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
`
`10
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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.
`Overview of Lillich
`2.
`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
`
`11
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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
`12
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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.
`
`Overview of Todd
`3.
`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.
`
`
`
`13
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`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.
`
`14
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`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.
`
`Issue
`1.
`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.
`
`Analysis
`2.
`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
`
`15
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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.
`16
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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
`17
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`(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
`
`18
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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.
`19
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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
`