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,
`
`Vv.
`
`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 US.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,
`
`Vv.
`
`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 US.C. § 314
`
`
`
`IPR2020-00023
`Patent 6,467,088 Bl
`
`I.
`
`INTRODUCTION
`
`Microsoft Corp. (“Petitioner”) filed a Petition (Paper2, “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 (Paper6, “Prelim. Resp.”).
`
`Under 35 U.S.C. § 314(a), an inter partes review may notbeinstituted
`
`unless the information presented in the petition “showsthat 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 LLCv.
`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; Paper4,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 ’0&88 Patent
`
`The ’088 patent is directed to techniques for upgrading or
`
`reconfiguring software and/or hardware componentsin 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.
`
`/d. at 1:31-36. Theseprior art systems updated software by the
`
`central computer transmitting patches to each of the remote systems. Jd. 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 computerhasa set of resources
`
`determined in accordance with a set of enterprise policies or a central server
`
`maintaining a masterlist that is used to keep files on a remote device
`
`updated to the latest version.
`
`/d. at 1:49-52, 1:60-65. According to the
`
`’088 patent, all of the above techniquesfail to avoid potential conflicts and
`
`ensure compatibility because they do not account for interdependencies of
`
`the resources required by the desktopsorthe files resident in the remote
`
`devices. Jd. at 1:41-45, 1:52-56, 1:65-2:3, 2:10-14.
`
`The ’088 patent solves the problem by providinga list orlisting, that
`
`indicates “which of a set of software components supported by the manager
`
`10 are known to work well together or are otherwise compatible.” Jd. 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. /d. at 3:27—29.
`
`
`
`IPR2020-00023
`Patent 6,467,088 Bl
`
`REQUEST
`
`20
`
`WANT UPGRADE TO A V2.0
`
`COMPONENTS
`
`RECONFIGURATION MANAGER
`
`REPOSITORY
`OF SW
`
`Win)09
`
`12
`
`4A
`
`DEVICEX
`
`14C
`
`148
`
`RESPONSE
`
`FG.100.0.0... KNOWN BAD CONFIG.
`
`KNOWN GOOD CONFIG.
`
`Figure 1, above,illustrates a reconfiguration manager 10 interacting
`
`with an electronic device 12, also referred to as “Device X.” Jd. at 3:14—-16.
`
`Whenreconfiguration 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 andincludesa 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.
`
`/d. at 4:12-19. Reconfiguration manager
`
`10 processes the request, and if appropriate, delivers the requested version
`
`2.0 of software component A. Jd. 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. Jd. at 4:62—-66. A known “bad” configuration is indicated in
`4
`
`
`
`IPR2020-00023
`Patent 6,467,088 Bi
`
`Figure 1 as a dashedline between components that are not compatible.
`
`/d. 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. Jd.
`
`at 3:61-63.
`
`If the upgrade configuration correspondsto 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. Jd. 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:
`
`A. processor-implemented method for controlling the
`1.
`reconfiguration of an electronic device, the method comprising
`the stepsof:
`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
`and_
`comparing the determined component
`specifying at
`least one additional component currently
`implemented in the electronic device with at least one of a
`list of known acceptable configurations for the electronic
`device and a list of known unacceptable configurations for
`the electronic device; and
`
`
`
`IPR2020-00023
`Patent 6,467,088 Bl
`
`generating information indicative of an approvalor a denial of
`the reconfiguration request based atleast in part on the result
`of the comparingstep.
`
`Ex. 1001, 6:43-59. Werefer 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):
`
`
`
`
`
`
`§ 103
`§ 103
`§ 103
`§ 103
`
`Apfel, Lillich, Todd
`Apfel, Lillich, Todd, Pedrizetti
`Apfel, Lillich
`Apfel, Todd
`
`
`
`
`14, 6-14, 16-21
`
`1-3, 9-13, 19-21
`1,3, 4, 6-11, 13,
`14, 16-21
`
`Petitioner further relies on the Declaration of John Villasenor to
`
`support its patentability challenge. Ex. 1003 (“Villasenor Declaration”).
`
`
`
`IPR2020-00023
`Patent 6,467,088 Bl
`
`Il. ANALYSIS
`
`A. Level of Ordinary Skill in the Art
`
`Petitioner contends that a person ofordinary 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
`
`componentsin electronic devices” and that “[l]ess work experience may be
`
`compensated by a higherlevel of education, such as a Master’s Degree, and
`
`vice versa.” Pet. 16-17 (citing Villasenor Decl. J] 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 ofskill 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 usedin federaldistrict court, including construing
`
`the claim in accordance with the ordinary and customary meaningofthe
`
`claim as understood by oneofordinary 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 termas
`.
`7
`
`
`
`IPR2020-00023
`Patent 6,467,088 Bl
`
`understood by one ofordinary 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:
`
`indicative of component compatibili
`
`
`The term “known” means“previously
`“known... for the
`
`determined”and the phrase “for the
`electronic device”
`
`
`electronic device” does not require that the
`“list” of known acceptable and known
`
`unacceptable configurations be specific to
`
`the electronic device
` “at least one of”
`
`To be read in accordance with the plain
`meaning of the phrase, namely as
`
`
`conjunctivelists of their respective
`
`elements,i.e., “at least one of [a] and at
`
`least one of [b].”
`
`
`
`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
`
`1.
`
`Overview ofApfel
`
`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 Bl
`
`system for automatically updating a software program module component
`
`stored on a computer, as shownin Figure 3 reproduced below.
`
`COMPUTER
`
`20
`
`Figure 3 of Apfel (above)illustrates a system including computer 20,
`
`database server 80a, and package server 80b. /d. at 6:36-37. Computer 20
`
`sends query 100 on orafter a predetermined date over the Internet to
`
`database server 80a. Jd. at 6:39-40. Query 100 includesall of the
`
`information regarding computer 20 that the database server 80a needsto
`
`determine if an upgradeis available and, if an upgrade is available, to
`
`determine the location of the upgrade package. Jd. at 6:49-53. After
`
`reviewing query 100, database server 80a returns response 105 over the
`
`Internet to computer 20. Jd. at 6:54-55. If an upgradeis 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
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`110 to package server 80b at the URL of the update package. Id. at 7:48.
`
`Package server 80b will send update package 115 to computer 20, and
`
`computer 20 will then install the update package 115. Jd. at 7:8-10. The
`
`servers are responsible for assessing whether an upgradeis available and
`
`whether it should be downloaded based on the information sent by computer
`
`20. Id. at 7:13-16.
`
`2.
`Overview ofLillich
`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.
`
`/d. at Abstract. Figure 1 of Lillich is
`
`reproduced below.
`
`30
`
`\
`
`32
`
`36
`
`5
`
`PROVIDER
`
`34
`
`34
`
`PROVIDER
`
`FIG. 1
`
`Figure 1 of Lillich (above) is a symbolic, simplified block diagram of
`
`system 30. Jd. at 5:28. As shownin 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. Jd. 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. Jd. at 4:5-7. A provider indicator identifies a
`
`particular type of provider. Jd. at 4:7-8. A currentindicator of a provider
`
`specifies the version of the provider.
`
`/d. at 4:8-9. When a clientis linked
`
`with a version of a provider, the current indicator of that provideris stored in
`
`the executable client produced, thereby identifying the version of the
`
`provider, referred to as a “definition provider,” used to build the client. Jd.
`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. Jd. 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. Jd. 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. Jd. 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. Jd. at 4:22-25. The versions within each of the
`
`two compatibility ranges are older than or equal in age to the current
`
`version. Jd. at 4:25-27. Lillich defines an “implementation provider”as
`
`“the provider which will be used to execute the client.” Jd. 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. Jd. at 4:28-32. Compatibility
`
`checks are performed betweena client and available versions of the
`
`provider(s), implementation providers, with which it has been linked.
`
`/d. at
`
`4:32-35.
`
`3.
`
`Overview of Todd
`
`Toddis titled “System and Methodfor 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.
`
`/d. at Abstract. Figure 1 of Todd is reproduced below.
`
`12
`
`
`
`IPR2020-00023
`Patent 6,467,088 Bl
`
`FIG. 1
`
`f”
`
`130 ( REMOTE DATA SOURCE)
`
`REGISTRATION
`DATABASE
`
`132
`
`
`
`
`COMMUNICATIONS
`CIRCUITRY
`
`
`
`PROCESSING
`CIRCUITRY
`CONFIGURATION
`
`
`
`DETECTION CIRCUITRY
`
`
`
`110 (COMPUTER SYSTEM )}
`
`REVISIONS
`
`CONFIGURATION DATA
`
`COMMUNICATION LINK
`
`
`MEMORY
`DEVICE
`
`NONVOLATILE
`MEMORY
`
`
`Figure 1 of Todd (above) is a block diagram of system 100. Jd. 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. Jd. at 6:7-9. Computer
`
`system 110 also comprises processing circuitry 114, nonvolatile memory
`
`116, and communicationscircuitry 118.
`
`/d. 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. Jd. 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
`_ determinesthe 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. Jd. at 6:50-55. As shownin Figure 1 of
`
`Todd, remote data source 130 contains a database of software revisionsthat
`
`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 14, 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.
`
`1,
`
`Analysis
`
`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 knownacceptable 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 summarizedas follows:
`
`Apfel and Lillich
`
`a.
`
`It would have been obvious to combinethe teachings of Apfel
`
`and Lillich because a person ofordinary 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 morethan the application of a well-
`
`known knowntechnique for determining compatibility as
`
`15
`
`
`
`IPR2020-00023 -
`Patent 6,467,088 Bl
`
`evidenced by Apfel’s desire to perform a lookup for available
`
`upgrades that should be downloaded).
`
`|
`Apfel and Todd
`a. It would have been obviousto 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 mannerthat ensures
`
`compatibility. Jd. 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. Jd. at 48 (arguing also that Todd’s
`techniqueis one of a limited numberofsolutions for
`determining incompatibility).
`
`Apfel, Lillich and Todd
`
`a. A person of ordinary skill in the art would recognize that
`
`combiningthe affirmative approach emphasizedin 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 oneofthese
`
`checks. Id. at 30.
`
`b. The methods described in Lillich and Todd comprise well-
`knowntechniquesthat 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 independentclaims, at this juncture, we find
`
`reasonable Petitioner’s arguments, which appearto 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 Word8.0 (id. at
`
`35-37), and, regarding the recited determining step, Apfel performs a
`
`database lookup to determine if an upgrade packageis 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 moduleto 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,
`§: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 packagesare 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 performsa
`
`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 knownacceptable 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 obviousto a person ofordinary 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
`
`UPDATEmessageif the upgrade is available or sends a NOUPDATE
`
`message if the upgradeis denied. See id. at 49-50.
`
`Asfor 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 argumentsare 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. Jd.
`
`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. J] 92-95). As for reasons to combine,as stated
`
`18
`
`
`
`IPR2020-00023
`Patent 6,467,088 B1
`
`above, Petitioner explains why a person ofordinary skill in the art would
`
`have combined Apfel with the teachings ofeither Lillich or Todd. Petitioner
`
`also presents reasons to combine Apfel with both Lillich and Todd.
`
`Petitioner’s proffered rationales appear reasonableat this stage of the
`
`proceeding.
`
`Patent Ownerchallenges the reasons to combine. We address each of
`
`Patent Owner’s challengesin 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 combineits teachings with those of
`
`either Lillich or Todd.
`
`/d. at 20. We are not persuaded by this argument.
`
`As Petitioner notes, Apfel determines, for each configuration of the
`computer, which upgrade packageto allow (Pet. 41-42)! and Apfel
`
`evaluates whether, even if an upgradeis available, the upgrade “is somehow
`
`incompatible” with the computer and should not be downloaded (Pet.
`
`45-46).* Thus,Petitioner sufficiently shows that Apfel is concerned with
`
`basing its determination whetherto allow a software upgrade based on
`
`compatibility of two types: whether the software component is compatible
`
`' The Petition cites Exhibit 1004 (6:65—-67, 9:30—42) and Villasenor
`Declaration (ff 83-85).
`* The Petition cites Exhibit 1004 (7:13-19) and Villasenor Declaration
`(7 90, 91).
`
`19
`
`
`
`IPR2020-00023 ©
`Patent 6,467,088 B1
`
`with the computer’s configuration or whether the software componentis
`
`incompatible with the computer’s configuration. Accordingly, Patent
`
`Owner’s argument regarding Apfel’s teachings as lacking disclosure of
`
`compatibility is unpersuasive.
`
`Second, Patent Ownerargues that Apfel should be construed to teach
`
`that the user or administrator, who has general knowledge about
`
`incompatibility, would perform “a manualaction,” rather than the system
`
`determining the upgrade compatibility. Prelim. Resp. 19. This argumentis
`
`unpersuasive. The passages in which Apfel describes the determination
`
`regarding whether the software is compatible with the computerrefer to the
`
`actions performed by Apfel’s server, not an administrator. Ex. 1004,
`
`7:11-19. We do not see Apfel, nor does Patent Ownerpoint to any
`
`persuasive disclosure in the reference, as teaching a manualaction of any
`
`kind.
`
`Arguments Targeting Lillich’s Teachings
`
`Patent Ownerarguesthat Lillich’s compatibility-verification
`technique “‘is only applicable to a client program componentand a provider
`program component whenexecuted locally on the memoryof one
`
`computer.” Prelim. Resp. 22. Patent Owneralso argues that the request for
`
`a software upgrade would not workas the claims require because the
`
`“compatibility could only be verified after the client program componentis
`
`downloaded in response to the request, and executed locally on the host
`
`computer.” Jd. 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.” Jd. 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 teachingsof 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 Ownersupported any of its arguments with
`
`facts tending to show that the teachings of Lillich could not be combined
`
`with Apfel’s teachings, as Petitionerasserts.
`
`Arguments Targeting Todd’s Teachings
`
`Patent Ownerargues that Todd’s conflict check occurs after the
`
`computer has been reconfigured, contrary to the recited order ofsteps.
`
`Prelim. Resp. 28-29. Patent Ownercontendsthat, “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 notarrive at the recitations of Claims 1, 11,
`
`and 21.” Jd. at 29. The argumentis not persuasive.
`As with the arguments addressed above, Patent Ownerfocuses 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
`
`performsthe 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—notafter the software upgradeis
`
`installed, as Patent Owner seemsto argue.
`
`Finally we address Patent Owner’s argumentthat 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 regardto Lillich
`
`performing the compatibility check locally with the argument that Toddis a
`network-based system. Jd. 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 Bl
`
`the Lillich local-based technique. Jd. We are not persuaded bythis
`
`argumentfor the samereasonsas stated above. The Apfel server would be
`
`performingthe 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 whetherthese techniquesfail to be combinable
`
`with Apfel’s database lookup process. Further, Patent Owner’s arguments
`
`presumean incorporation ofeither Lillich’s technique into Todd’s system or
`
`vice-versa. Jd. 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 referencesthat are not at-issue.
`
`In conclusion, on the present record, we do notfind 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
`
`persuadedthat Petitioner has demonstrated a reasonable likelihood of
`
`prevailing on its assertion that claims 1, 11, and 21 would have been obvious
`
`over Apfel alone or the combination of Apfel, Todd, and Lillich.
`
`Weare aware that this groundalso involves dependent claims 2-4,
`
`6-10, 12-14, and 16—20. Patent Ownerdid not raise any arguments
`
`concerning these dependent claims. Having reviewed these claims and the
`
`asser
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
