Trials@uspto.gov
`571-272-7822
`
`Paper 7
`Entered: April 14, 2020
`
`
`
`
`
`
`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
`SEAN P. O’HANLON, Administrative Patent Judges.
`
`QUINN, Administrative Patent Judge.
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`571-272-7822
`
`Paper 7
`Entered: April 14, 2020
`
`
`
`
`
`
`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
`SEAN P. O’HANLON, Administrative Patent Judges.
`
`QUINN, Administrative Patent Judge.
`
`
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`I. INTRODUCTION
`Microsoft Corp. (“Petitioner”) filed a Petition (Paper 2, “Pet.”)
`requesting inter partes review of claims 1–4, 6–14, and 16–21 of U.S. Patent
`No. 6,467,088 B1 (Ex. 1001, “the ’088 patent”). Uniloc 2017 LLC (“Patent
`Owner”) timely filed a Preliminary Response (Paper 6, “Prelim. Resp.”).
`Under 35 U.S.C. § 314(a), an inter partes review may not be instituted
`unless the information presented in the petition “shows that there is a
`reasonable likelihood that the petitioner would prevail with respect to at
`least 1 of the claims challenged in the petition.” For the reasons stated
`below, we determine that Petitioner has demonstrated a likelihood of
`prevailing with respect to at least one challenged claim. We, therefore,
`institute inter partes review.
`
`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., 1:18-cv-00296 (W.D. Tex.), filed April 9, 2018; Uniloc 2017 LLC v.
`Microsoft Corporation, 8:19-cv-00956 (C.D. Cal.), filed May 20, 2019; and
`Uniloc USA, Inc. and Apple Inc., 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”).
`
`B. The ’088 Patent
`The ’088 patent is directed to techniques for upgrading or
`
`reconfiguring software and/or hardware components in electronic devices.
`2
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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
`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, the 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. Asserted Prior Art
`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.
`
`E. Asserted 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
`Apfel, Lillich, Todd
`Apfel, Lillich, Todd, Pedrizetti
`Apfel, Lillich
`Apfel, Todd
`
`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
`
`
`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). At this stage,
`Patent Owner “does not dispute Petitioner’s definition of a POSITA.”
`Prelim. Resp. 13. Given the lack of dispute, and for purposes of this
`decision, 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. Patent Owner “requests that the
`Board adopt the ordinary and customary meaning of the claim term as
`7
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`understood by one of ordinary skill in the art.” Prelim. Resp. 15. None of
`Patent Owner’s arguments point out disagreement with Petitioner’s proposed
`constructions, and, upon review of those proposed constructions, at this
`juncture, we find them reasonable. For purposes of this Decision, we adopt
`Petitioner’s proposed constructions as follows:
`“list”
`any stored representation of information
`indicative of component compatibility
`The term “known” means “previously
`determined” and the phrase “for the
`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].”
`
`“known . . . for the
`electronic device”
`
`“at least one of”
`
`
`Further, on this record, we 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 installing and updating a software program
`module component. Ex. 1004, Abstract. In particular, Apfel describes a
`8
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`system for automatically updating a software program module component
`stored on a computer, as shown in Figure 3 reproduced below.
`
`
`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 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
`
`9
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`110 to package server 80b at the URL of the update package. Id. at 7:4−8.
`Package server 80b will send update 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, system 30 may be hardware,
`
`10
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`software, or a combination thereof, and includes client 32 and provider 34
`connected by connector 36 such that information from the 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.
`
`11
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`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
`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.
`
`12
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`
`Figure 1 of Todd (above) is a block diagram of system 100. Id. at
`5:28. 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
`
`13
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`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.
`
`D. Obviousness Ground Based on Apfel, Lillich, and Todd
`Petitioner asserts that claims 1–4, 6–14, and 16–21 would have been
`obvious over the combined teachings of Apfel, Lillich, and Todd.
`Pet. 26−64. Patent Owner challenges Petitioner’s assertions by arguing,
`inter alia, that “there exists no motivation within Apfel to be combined with
`either the teachings of Lillich or Todd.” Prelim. Resp. 20.
`Analysis
`1.
`Petitioner contends that Apfel teaches or suggests all the limitations of
`the independent claims, including the comparing step. See Pet. 41−42,
`
`14
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`45−46 (arguing that Apfel inherently describes or implicitly teaches the
`comparing step with regard to the known acceptable configurations, and that
`Apfel shows obviousness with regard to the known unacceptable
`configurations). Petitioner further argues that Lillich teaches the comparing
`step with regard to the known acceptable configurations (id. at 42−45), and
`that Todd teaches the comparing step with regard to the known unacceptable
`configurations (id. at 46−48). As for motivation to combine these
`references, Petitioner’s arguments can be summarized as follows:
`Apfel and Lillich
`a. It would have been obvious to combine the teachings of Apfel
`and Lillich because a person of ordinary skill in the art would
`recognize the benefit of ensuring that a requested update will
`not render the system inaccurate or inoperative. Pet. 27−28.
`b. Further, it would have been obvious to modify Apfel’s database
`lookup to include the Lillich evaluation of the version numbers
`of the components in Apfel (such as the Web Authoring
`Components program module, the HTML converter, and the
`word processor program module) “to determine whether they
`are within an appropriate range to ensure compatibility between
`and among those components and any requested update or
`combination of updates to one or more of these component
`versions.” Id. at 44−45 (arguing also that the combination
`would have been nothing more than the application of a well-
`known known technique for determining compatibility as
`
`15
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`evidenced by Apfel’s desire to perform a lookup for available
`upgrades that should be downloaded).
`Apfel and Todd
`a. It would have been obvious to incorporate the teachings of
`Todd into Apfel because the combination provides a person of
`ordinary skill in the art with information about methods to
`perform network-based updates in a manner that ensures
`compatibility. Id. at 29−30.
`b. It would have been obvious to modify Apfel’s server
`assessment using Todd’s described conflict determination so
`that program updates that would result in known conflicts
`would not be downloaded. Id. at 48 (arguing also that Todd’s
`technique is one of a limited number of solutions for
`determining incompatibility).
`Apfel, Lillich and Todd
`a. A person of ordinary skill in the art would recognize that
`combining the affirmative approach emphasized in Lillich
`(verifying compatibility) with the safeguards presented in Todd
`(identifying conflicts) would result in an improved system as
`compared with an approach that performed only one of these
`checks. Id. at 30.
`b. The methods described in Lillich and Todd comprise well-
`known techniques that a person of ordinary skill in the art could
`have combined with Apfel’s database lookup without undue
`
`16
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`
`experimentation, and with a reasonable likelihood of success.
`Id. at 31.
`With regard to Petitioner’s contentions that Apfel alone renders
`obvious the challenged independent claims, at this juncture, we find
`reasonable Petitioner’s arguments, which appear to be factually supported by
`the current record. As the Petition sets forth, regarding the recited receiving
`step, Apfel’s database server receives from a computer a request to update
`the Web Authoring Components program module of Word 8.0 (id. at
`35−37), and, regarding the recited determining step, Apfel performs a
`database lookup to determine if an upgrade package is available (id. at
`37−38). Apfel’s request for the update is an HTTP query that includes the
`information Apfel uses to make the determination: the version of the Web
`Authoring Components program module to be upgraded, the version of an
`HTML converter in the word processor program module, the version of the
`word processor program module, the localization language, and the type of
`operating system on the computer. See id. at 40 (citing Ex. 1004, 8:39−46,
`8:53−66).
`As to the comparing step, Apfel also discloses that the database stores
`the upgrade package information and the corresponding configurations that
`should be downloaded, and that different update packages are available for
`different version combinations, different operating systems, and different
`languages. Ex. 1004, 9:36−40. Therefore, at this juncture, it seems
`reasonable, as Petitioner argues, that Apfel’s database lookup performs a
`comparison of the information in the HTTP query with the information
`
`17
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`stored in the database, which, Petitioner argues, inherently discloses the list
`of known acceptable configurations for the electronic device. See Pet. 42. It
`further seems reasonable, as Petitioner argues, that, because Apfel denies the
`upgrade “if the upgrade is somehow incompatible with computer 20,” it
`would have been obvious to a person of ordinary skill in the art that Apfel’s
`database lookup (i.e., comparison) determines the incompatibility by using
`information previously received about configurations that are not
`compatible. See Pet. 45−46. After the determination whether to allow or
`deny the upgrade, regarding the recited generating step, Apfel sends an
`UPDATE message if the upgrade is available or sends a NOUPDATE
`message if the upgrade is denied. See id. at 49−50.
`As for Petitioner’s additional obviousness contention that the
`combination of Apfel, Lillich, and Todd teaches the comparing step, we also
`find that, on the present record, Petitioner’s arguments are factually
`supported and have merit. In particular, 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 provider software is compatible with the client software.
`Pet. 42−45 (citing Ex. 1005, 1:41−44, 3:66−4:27; Villasenor Decl.
`¶¶ 86−89). Todd, according to Petitioner, teaches the comparison with
`“known unacceptable configurations” because Todd, like Apfel, uses a
`database to identify incompatibility of conflicts between configurations. Id.
`at 46−48 (citing Ex. 1006, 3:15−30, 3:43−51, 3:55−59, 5:8−13, 12:9−15,
`14:17−20; Villasenor Decl. ¶¶ 92−95). As for reasons to combine, as stated
`
`18
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`above, Petitioner explains why a person of ordinary skill in the art would
`have combined Apfel with the teachings of either Lillich or Todd. Petitioner
`also presents reasons to combine Apfel with both Lillich and Todd.
`Petitioner’s proffered rationales appear reasonable at this stage of the
`proceeding.
`Patent Owner challenges the reasons to combine. We address each of
`Patent Owner’s challenges in turn.
`Arguments Targeting Apfel’s Teachings
`First, Patent Owner argues that Apfel’s upgrade requests are fulfilled
`without regard to compatibility issues, and, therefore, there is no reason to
`attribute to Apfel the desire to perform a software upgrade based on
`compatibility. Prelim. Resp. 17−20. That is, Patent Owner argues, there
`exists no motivation within Apfel to combine its teachings with those of
`either Lillich or Todd. Id. at 20. We are not persuaded by this argument.
`As Petitioner notes, Apfel determines, for each configuration of the
`computer, which upgrade package to allow (Pet. 41–42)1 and Apfel
`evaluates whether, even if an upgrade is available, the upgrade “is somehow
`incompatible” with the computer and should not be downloaded (Pet.
`45−46).2 Thus, Petitioner sufficiently shows that Apfel is concerned with
`basing its determination whether to allow a software upgrade based on
`compatibility of two types: whether the software component is compatible
`
`1 The Petition cites Exhibit 1004 (6:65−67, 9:30−42) and Villasenor
`Declaration (¶¶ 83−85).
`2 The Petition cites Exhibit 1004 (7:13−19) and Villasenor Declaration
`(¶¶ 90, 91).
`
`19
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`with the computer’s configuration or whether the software component is
`incompatible with the computer’s configuration. Accordingly, Patent
`Owner’s argument regarding Apfel’s teachings as lacking disclosure of
`compatibility is unpersuasive.
`Second, Patent Owner argues that Apfel should be construed to teach
`that the user or administrator, who has general knowledge about
`incompatibility, would perform “a manual action,” rather than the system
`determining the upgrade compatibility. Prelim. Resp. 19. This argument is
`unpersuasive. The passages in which Apfel describes the determination
`regarding whether the software is compatible with the computer refer to the
`actions performed by Apfel’s server, not an administrator. Ex. 1004,
`7:11−19. We do not see Apfel, nor does Patent Owner point to any
`persuasive disclosure in the reference, as teaching a manual action of any
`kind.
`Arguments Targeting Lillich’s Teachings
`Patent Owner argues that Lillich’s compatibility-verification
`technique “is only applicable to a client program component and a provider
`program component when executed locally on the memory of one
`computer.” Prelim. Resp. 22. Patent Owner also argues that the request for
`a software upgrade would not work as the claims require because the
`“compatibility could only be verified after the client program component is
`downloaded in response to the request, and executed locally on the host
`computer.” Id. at 23. According to Patent Owner, “combining a request for
`a software upgrade as taught by Apfel would destroy the functionality of the
`
`20
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`compatibility verification technique as taught by Lillich.” Id. We are not
`persuaded by Patent Owner’s arguments.
`The asserted combination of teachings, as we understand the Petition,
`involves modifying Apfel’s database lookup to include the comparison of
`Lillich’s version numbers for the various components that Apfel utilizes to
`determine compatibility. Pet. 44−45. Thus, the combination relies on
`Apfel’s server utilizing Lillich’s compatibility-check technique. In other
`words, the comparison using Lillich’s technique occurs at Apfel’s server.
`Therefore, it is irrelevant, for purpose of the asserted combination, that
`Lillich teaches performing its technique at a local computer.
`Further, because the relevant Lillich teaching is that of the
`compatibility check, it is also unpersuasive to argue that Lillich’s programs
`are already downloaded and executed. Apfel provides the teachings of the
`servers receiving the upgrade requests, checking the compatibility, and
`servicing the request. See, e.g., Ex. 1004, 7:13–16. We see no evidence in
`the record that Apfel would not work as intended or be incompatible with
`Lillich’s compatibility-check technique. Patent Owner’s arguments to the
`contrary focus on aspects of Lillich that are not part of the asserted
`combination. Nor has Patent Owner supported any of its arguments with
`facts tending to show that the teachings of Lillich could not be combined
`with Apfel’s teachings, as Petitioner asserts.
`Arguments Targeting Todd’s Teachings
`Patent Owner argues that Todd’s conflict check occurs after the
`computer has been reconfigured, contrary to the recited order of steps.
`Prelim. Resp. 28−29. Patent Owner contends that, “even if the software
`21
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`upgrade request of Apfel was to be incorporated into the teachings of Todd,
`the resulting combination could not arrive at the recitations of Claims 1, 11,
`and 21.” Id. at 29. The argument is not persuasive.
`As with the arguments addressed above, Patent Owner focuses on a
`combination of teachings that Petitioner did not make. Petitioner relies on
`Apfel’s server receiving the upgrade requests, checking the compatibility,
`and servicing the request. Todd is merely supplying the teaching of how to
`perform a conflict check, which Apfel’s server would perform. Patent
`Owner’s arguments characterize Petitioner’s asserted combination
`backward: incorporating Apfel into Todd. The Petition clearly states the
`obviousness contention differently than argued by Patent Owner: “it would
`have been obvious to modify Apfel’s server assessment using stored
`information regarding incompatible configurations . . . regarding known
`conflicts . . . , as described in Todd.” Pet. 48. It is irrelevant when Todd
`performs the conflict check. The timing is regulated by Apfel’s server,
`which, according to Petitioner’s contention, would perform the conflict
`check during Apfel’s database lookup—not after the software upgrade is
`installed, as Patent Owner seems to argue.
`Finally we address Patent Owner’s argument that the combination of
`teachings of Lillich and Todd would render the resulting combination
`inoperable for its intended purpose. Prelim. Resp. 29−31. Patent Owner
`combines the various arguments made above with regard to Lillich
`performing the compatibility check locally with the argument that Todd is a
`network-based system. Id. According to Patent Owner, because Todd’s
`technique is applied on a network-based system, it would not function with
`22
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`the Lillich local-based technique. Id. We are not persuaded by this
`argument for the same reasons as stated above. The Apfel server would be
`performing the relevant techniques taught by Lillich and Todd. The
`disclosure of Lillich being a local check and Todd’s being network-based
`say little to nothing about whether these techniques fail to be combinable
`with Apfel’s database lookup process. Further, Patent Owner’s arguments
`presume an incorporation of either Lillich’s technique into Todd’s system or
`vice-versa. Id. at 30−31 (arguing incompatibility of combining the system
`of Todd with that of Lillich). These arguments do not respond to the
`asserted combination of teachings, which involve Apfel’s database lookup as
`the base teaching, and, instead focus on the bodily incorporation of features
`of the secondary references that are not at-issue.
`In conclusion, on the present record, we do not find any of Patent
`Owner’s arguments persuasive to show fault with Petitioner’s asserted
`reasons to combine. Having considered Patent Owner’s arguments in light
`of Petitioner’s contentions and supported evidence of record, we are
`persuaded that Petitioner has demonstrated a reasonable likelihood of
`prevailing on its assertion that claims 1, 11, and 21 would
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
