throbber
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
`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
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket