`571.272.7822
`
`Paper No. 7
`Filed: April 29, 2019
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLEINC.,
`Petitioner,
`
`V.
`
`UNILOC 2017 LLC,
`Patent Owner.
`
`Case IPR2019-00056
`Patent 6,467,088 Bl
`
`Before SALLY C. MEDLEY, MIRIAM L. QUINN,and
`SEANP. O’HANLON,Administrative Patent Judges.
`
`QUINN,Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314(a) and 37 C.F-R. § 42.108
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`AppleInc. (“Petitioner”) filed a Petition requesting inter partes
`
`review of claims 1-21 of U.S. Patent No. 6,467,088 B1 (Ex. 1001,
`
`‘088 patent”). Paper 1 (“Pet.”). Uniloc 2017 LLC, (“Patent Owner’’)filed
`
`a Preliminary Response. Paper6 (‘‘Prelim. Resp.”’).
`
`Pursuant to 35 U.S.C. § 314(a), an inter partes review may not be
`
`instituted unless “the information presented in the petition .. . and any
`
`response .. . showsthat there is a reasonable likelihood that the petitioner
`_ would prevail with respectto at least 1 of the claims challenged in the
`petition.” For the reasons given below, we determinePetitioner has not
`demonstrated a reasonable likelihood that it would prevail in establishing
`that claims 1-21 of the ’088 patent are unpatentable.
`
`I. BACKGROUND
`
`A. THE ’088 PATENT
`
`1. Disclosure
`
`The ’088 patent is directed to techniques for upgrading or
`
`reconfiguring software and/or hardware componentsin electronic devices.
`
`Ex. 1001, 1:6-9. The ’088 patent explainsthat prior art systems developed
`
`for updating componentsof electronic devices rely on a central computer
`
`system that tracks all software configurations for a number of remote
`
`systems. Jd. 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 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 hasa set of resources
`
`determined in accordance withaset of enterprise policies or a central server
`
`maintaining a masterlist that is used to keep files on a remote device
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`updated to the latest version. Jd. at 1:49-52, 1:60-65. Accordingto 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 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 or listing, that
`
`indicates “which of a set of software components supported by the manager
`
`10 are knownto 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 includesa listing 16 of known
`
`configurations, and a repository 18 of software components. Jd. at 3:27-29.
`
`10
`
`RECONFIGURATION MANAGER
`KNOWN CONFIGURATIONS
`
`REQUEST
`
`20
`
`WANT UPGRADETO A V2.0
`
`12
`
`14A
`
`
`
`DEVICEX
`
`14C
`
`RESPONSE
`
`
`Gi)
`
`
`REPOSITORY
`
`COMPONENTS
`
`FIG 1
`
`KNOWN GOOD CONFIG.
`
`Toorssrssss KNOWN BAD CONFIG.
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`Figure 1, above,illustrates a reconfiguration manager10 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 componentA,andincludesa list of the components
`
`currently on the device,i.e., version 1.1 of component A,version 2.0 of
`
`componentC, 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. 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. Jd. at 4:62-66. A known “bad”configurationis
`
`indicated in Figure 1 as a dashed line between componentsthat are not
`
`compatible. Jd. at 4:58-61. For example, the pair including version 1.8 of
`
`componentA 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 managerattemptsto find a set or sets of potential upgrade
`
`configurations from a set of known “good”configurations. Jd. 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.
`
`2. Prosecution History
`
`During prosecution of the ’088 patent, the Examinerissued a
`
`Rejection of claims 1-21 under 35 U.S.C. § 103 over U.S. Patent No.
`
`6,301,707 B1 (“Carroll”). Ex. 1007. The Examiner found that Carroll
`
`4
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`teachesall the limitations of claim 1, and, in particular, with respect to the
`
`comparing step, the Examiner found that Carroll performs a comparison
`
`using the profile of the target system to install components identified in that
`
`profile. Jd. at 3.! The Applicant filed a Response. Ex. 1008. It argued that
`
`the installation process in Carroll installs in the target system only
`
`components that are defined in the profile of the target system, and that the
`
`invention, in contrast, ensures that upgrades are compatible with the
`
`configuration of a given device before they are implemented in that device.
`
`Id. at 2-3. Thus, Applicant argued, although Carroll teaches the use of a
`
`profile comparisonto install software, Carroll did not teach the limitation of
`
`“comparing the determined componentand information specifying at least
`
`one additional componentcurrently implementedin the electronic device
`with at least one of a list of known acceptable configurations for the
`
`electronic device andalist of known unacceptable configurations for the
`
`electronic device.” Jd. at 3-4.
`
`The Examiner, in response to Applicant’s arguments, issued a Notice
`
`of Allowability of all pending claimsstating:
`
`The applicant argues that Carrol[1] fails to teach “receiving
`information representative of a configuration request.”
`However, see Carrol[l’s] fig. 3, item 320 (placing order).
`The placing of an order
`is
`inherently “information
`representative of a request.”
`It
`is further specified that
`Carrol[l]
`does not
`teach or
`suggest
`comparing the
`determined (requested)
`component
`and
`at
`least
`one
`additional componentto at least one of an acceptable or an
`unacceptable list. Carrolfl], as indicated in the previous
`action
`compares
`the
`requested
`component with
`an
`acceptable list (one of an acceptable and an unacceptable
`
`' Page numbersto this Exhibit refer to the page numberin the original
`Office Action.
`
`5
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`list); however, he does not teach or suggest comparing an
`additional component with one of the list in response to a
`request. Therefore, the claims are allowable overthe art of
`record.
`Ex. 1009, 2 (emphasis added).
`
`B. ILLUSTRATIVE CLAIM
`
`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 steps of:
`receiving information representative of a reconfiguration
`request relating to the electronic device;
`determining at
`least one device component
`implementthe 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
`generating information indicative of an approval or a denial of
`the reconfiguration request based at least in part on the
`result of the comparingstep.
`
`required to
`
`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.
`
`C. EVIDENCE OF RECORD
`
`ThePetition relies upon the following printed publications:
`
`U.S. Patent No. 5,752,042 (Ex. 1002, “Cole’’);
`
`U.S. Patent No. 6,449,723 B1 (Ex. 1004, “Elgressy”);
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`U.S. Patent No. 7,062,765 B1 (Ex. 1005, “Pitzel’’); and
`PCT Application Publication No. WO 97/30549 (Ex. 1003, ““MacInnis”).
`In addition, Petitioner supports its contentions with the Declaration of
`
`Charles D. Knutson, Ph.D. (Ex. 1006, “Knutson Decl.”).
`
`D. ASSERTED GROUNDS OF UNPATENTABILITY
`
`Petitioner asserts the following grounds of unpatentability. Pet. 4.
`
`
`
`Challenged Claims|Basis|__—_—References_
`§ 103|Cole, MacInnis, and Elgressy
`
`
`§ 103|Pitzel, Cole, and Elgressy
`
`If. ANALYSIS
`
`A. CLAIM CONSTRUCTION
`
`The Board interprets claim terms of an unexpired patent using the
`
`“broadest reasonable construction in light of the specification of the patent.”
`
`37 C.F.R. § 42.100(b) (2017);” see Cuozzo Speed Techs., LLC v. Lee, 136S.
`
`Ct. 2131, 2144-46 (2016). We presume a claim term carriesits “ordinary
`
`and customary meaning,” which is the meaning “the term would have to a
`
`person of ordinary skill in the art” at the time of the invention. Jn re
`
`Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007) (citation
`
`omitted).
`
`1. “list”
`
`The independentclaimsof the ’088 patent recite “at least one ofa list
`
`of known acceptable configurations for the electronic device anda list of
`
`knownunacceptable configurations for the electronic device.” Ex. 1001,
`
`2 A recent amendmentto this rule does not apply here becausethe Petition
`wasfiled before November 13, 2018. See Changes to the Claim
`Construction Standard for Interpreting Claims in Trial Proceedings Before
`the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018) (to
`be codified at 37 C.F.R.pt. 42).
`
`7
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`6:53-56, 7:48-51, 7:59-62, 8:59-62. Petitioner proposes a construction for
`
`the term “‘list” based on the description provided in the Specification as:
`
`“any stored representation of information indicative of component
`
`compatibility.” Pet. 9; see Ex. 1001, 4:6—8 (“The term ‘list’ as used herein
`is therefore intended to include any stored representation of information
`indicative of component compatibility.”) Patent Owner does not challenge
`
`Petitioner’s proposal and arguesthat “the Board need not construe any term
`
`in a particular mannerin orderto arrive at the conclusion that the Petition fs
`
`substantively deficient.” Prelim. Resp. 4-5.
`
`Uponreview of the arguments presented by Patent Owner, we note
`
`that Patent Ownerdistinguishes the asserted prior art on the basis ofthe
`
`“list” term. For example, Patent Owner argues that Cole does not disclose
`
`the recited list of “known acceptable configurationfor the electronic device”
`and the list of “known unacceptable configurationsfor the electronic
`
`device.” See Prelim. Resp. 6-10. In particular, Patent Owner arguesthat
`
`the recited “list” must be (1) previously determined,i.e. “known”; and (2)
`
`specific to the electronic device in question,i.e., “for the electronic device.”
`
`Id. at 6. For purposes of this Decision, we adopt Petitioner’s proposed
`
`construction of the term “list” as “any stored representation of information
`
`indicative of component compatibility.” We also adopt, for purposesof this
`
`Decision Patent Owner’s proposed construction of “known” to mean
`
`previously determined.
`
`2. Other Claim Terms
`
`Onthis record, 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
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`(Fed. Cir. 2017) (holding that only terms “that are in controversy” must be
`
`construed and “only to the extent necessary to resolve the controversy”).
`
`B. ALLEGED OBVIOUSNESS OVER COLE, MACINNIS, AND ELGRESSY
`
`Petitioner argues that claims 1-21 of the ’088 patent would have been
`
`obvious over Cole, MacInnis, and Elgressy. Pet. 13-41. Patent Owner
`
`disputes Petitioner’s assertions. Prelim. Resp. 6-10.
`
`1. Overview of Cole
`
`Cole is directed to a server computer for selecting program updates
`
`for a client computer based onresults of recognizer program(s) furnished to
`
`the client computer. Ex. 1002, [57]. Cole describes that a known technique
`
`for providing a client with a code upgrade involvesregistering the client
`
`with the server so that the server may automatically send the code updates to
`
`every client on the list of registered clients.
`
`/d. at 1:30-35. Alternatively, a
`
`client can periodically request all updates, and the server will respond
`
`accordingly. Jd. at 1:37—-38. Because of cost, download time, or other
`
`reasons, some clients may not wishto obtain the update.
`1:38-40.
`
`/d. at 1:34—36,
`|
`
`Cole, therefore, describes a server that identifies code updates that are
`
`consistent with basic system characteristics of the client computer.
`
`/d. at
`
`1:45—49. Then, the client computerutilizes a “recognizer” program, which
`
`the client computer obtains from a server, to determine whetherthe client
`
`computerhasa version other than a current version ofthe identified code
`
`updates. Jd. at 1:49-54. Theclient then sendsthe results of the recognizer
`
`program to the server computer, which generatesa list of code updatesthat
`
`are consistent with the basic characteristics representing programsthat exist
`
`on the client computer for which an update would be appropriate. Jd. at
`
`9
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`1:54-59. Then the server computer sendsthe list of code updates to the
`
`client computerso that a user of the client computer can select a code update
`
`from the list. Jd. at 1:59-62. In response, the server computer sends
`
`addresses of the selected code updates to the client computer and the client
`
`computer downloadsthe selected code updates. Id. at 1:62-65.
`
`2. List ofKnown Acceptable Configurations
`
`Petitioner argues that Cole, in combination with MacInnis and
`
`Elgressy, teaches the comparing step. Pet. 20-28. More specifically as to
`
`the “list,” Petitioner contends that Cole teaches the “list of known acceptable
`
`configurations” by providing an exampletable that lists code updates and
`basic system requirements metadata. Jd. at 21. Petitioner explains that Cole
`discloses that “the BIOS level 123, BIOS date Jan. 1, 1996 and mother board
`
`ID XYZ basic system information obtained from [the] client [] is consistent
`
`with a device driver file named ABCDE.DRV,”and,that, therefore, the
`
`device driver ABCDE.DRVis “potentially appropriate for the client.” Jd. at
`
`22 (citing Ex. 1002, 3:65-4:30). Petitioner also argues that “the device
`
`driver file named FGHIJ.DRVis inappropriate for the client andis
`eliminated from further consideration, because its required BIOS level(i.e.
`
`BIOS level 456), does not match the BIOS levelofthe client.” Jd. (citing
`
`Ex. 1002, 3:65-4:34; Knutson Decl. J 77).
`
`Patent Ownerarguesthat Cole does not teach the “list of known
`
`acceptable configurations,” at least in part becausethe alleged
`
`configurations in Cole are not known. Prelim. Resp. 8-9. In particular,
`
`Patent Ownerpoints out that Petitioner relies on Cole’s description of the
`
`match between the meta data and the basic system information “‘indicat[ing]
`
`that the corresponding code updatesare potentially appropriate for’the
`
`10
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`client. Jd. at 9 (citing Ex. 1002, 3:62—4:1). Patent Ownerarguesthat the
`
`matchis, at best, potentially appropriate, and, therefore, is not known that the
`
`code update is an “acceptable configuration.” Jd.
`
`Weare persuaded by Patent Owner’s argument. Cole describes that
`
`each client computer that seeks a code update first downloads a basic system
`
`information recognizer program so that the client computer can provide to
`
`the selection server the basic system information, such as BIOS level and
`
`system model. Ex. 1002, 3:42—50. The selection server determines which
`
`code updates are “consistent with the basic system information of the client
`
`and which code updatesare inconsistent thereby eliminating the vast
`
`majority ofthe code updates stored in content server 17... from further
`
`consideration.” Id. at 3:56—60 (emphasis added). The server determines
`
`this subset of code updates by “correlating the meta data in the data base 13
`
`to the basic system information obtained from client 14.” Jd. at 3:62—65.
`
`Thus, from this description, it appears that Cole performs a comparison
`
`between someaspects of the basic system information of the client and all of
`
`the code updates that are stored in the system. The code updates selected at
`
`this juncture in Cole are those that match someofthe basic system
`
`information; but Cole describes the selected code updates as “potentially
`
`appropriate for client 14.” Jd. at 3:65—-4:1. Therefore, neither the client nor
`
`the server anticipates that the selected code updatesat this point are actually
`
`a “knownacceptable configuration for the electronic device.” Although the
`
`code updatesat this point match somecriteria of the client device, they are
`
`not “known”to be acceptable configurations, but merely “potentially
`
`appropriate.” The indecisive language “potentially” is not the required
`
`11
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`decisive language of “known’”—a difference that Petitioner does not explain
`
`persuasively,if at all.
`
`The conclusion that Cole does not teach a “list of known acceptable
`
`configurations” is confirmed by Cole’s further explanation ofits technique,
`
`which requires a further recognition step to ultimately select the code
`
`updates that are acceptable for the client computer. For instance, Cole
`
`describes that the selection server sends to the client computer the FTP
`
`address information of the recognizer programs correspondingto the
`
`potentially appropriate code updates. Jd. at 4:35—47. Each of the recognizer
`
`programsis very small, and downloads muchfaster than the actual code
`
`update. Jd. at 4:48-52. This additional step is necessary because Colestates
`
`that “based on the basic system information alone, the selection update
`
`program 30 within server 12 is not sure which ofthe code updates that are
`
`consistent with the basic system information are actually needed by the
`
`client; for example, the client may already have the latest version.” Jd. at
`
`4:53-58 (emphasis added). Thus, none ofthe potentially appropriate code
`
`updates mayactually be installed. A further recognition step is necessary,
`
`by each of the recognizer programs downloaded,to actually investigate the
`
`hardware, software, and other components of the client computer “to assist
`
`the server in determining whether the corresponding code update is
`
`appropriate for the client.” Id. at 5:5—-7 (emphasis added). Further, Cole
`
`states that the recognizer program “could also determineif the
`
`corresponding code update is consistent with aspects of the client other than
`the basic system information, such as other programs within the client.” Jd.
`
`at 5:8-11. Therefore, Cole’s recognition programs mayindicate that the
`
`“potentially appropriate” code updates were actually not appropriate for the
`
`12
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`current configuration of the client computer, if other programs within the
`
`client computer are not compatible with the “potentially appropriate” code
`
`updates.
`
`The Petition does not explain the further recognition step of Cole and
`
`relies solely on the “potentially appropriate” code update determination,
`
`which,alone,is insufficient to teach or suggest “a list of known acceptable
`
`configurations.” See In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364,
`
`1381 (Fed. Cir. 2016) (holding that because petitioner “bears the burden of
`
`proof,” the Board “must base its decision on arguments that were advanced
`
`by [petitioner]”); 35 U.S.C. § 312(a)(3); 37 C.F.R. §§ 42.22(a)(2),
`
`42.104(b)(4)+(5).
`
`This limitation is recited in all independent claims of the ’088 patent.
`
`Accordingly, we are not persuadedthat Petitioner has met its burden of
`
`demonstrating by a reasonable likelihood its assertion that the challenged
`
`claims of the ’088 patent are obvious over Cole, MacInnis, and Elgressy.
`
`C. PITZEL, COLE, AND ELGRESSY
`
`Petitioner alleges that claims 1-21 would have been obvious over
`
`Pitzel, Cole, and Elgressy. Pet. 42-68.
`
`1. Overview ofPitzel
`
`Pitzel is directed to a system and method for updating information via
`
`a network,andparticularly, updating computer programs based uponclient-
`
`specific information. Ex. 1005, [54], 1:6-12. Pitzel explains that typically a
`
`userVisits an “update” server that hosts the improved computer programs.
`
`Id. at 1:31-32. Users are often confused and downloadthe incorrect version
`
`of the requested software because a numberof possible versions are
`
`available for downloading. Jd. at 1:33-36. For example, a user may be
`
`13
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`interested in a “French” version, but the user may not knowthe version of an
`
`operating system or whether other computer programsare required for
`
`proper operation of the upgrade. Jd. at 1:36—42. Thus, Pitzel seeks
`
`automatic downloading of an appropriate version of a computer program
`
`withoutuser intervention. Jd. at 1:47—49.
`
`Pitzel thus describes a methodfor installing components on the client
`
`computerby first having the user at the client computer initiate an upgrade
`
`request. Jd. at 7:15-19. The user then accesses a configuration server that
`
`hosts configuration files. Jd. at 7:21-24. A configuration file contains the
`
`configuration information for the installation of one or more components on
`
`the client computer. Jd. at 5:10-12. For each componentthere is associated
`
`a configurationfile. Jd. at 5:20-22. The configuration server provides
`
`information about the components via a web page, where the user can click
`
`on the information that is hyperlinked to the configuration file. Jd. at
`
`7:22-27. Clicking the hyperlink causes the configuration server to
`
`download the configuration file to the client computer. /d. at 7:27—30. The
`client computer determinesthe client conditions and forwards the
`configurationfile and the client conditions to the component server. Jd. at
`
`7:40-44. The client conditions are stored in a computer profile such that
`
`when a componentis designatedfor installation, a version of the component
`
`that is compatible with the client conditions may be selected. Jd. at 5:40—44.
`
`The client conditions include: a preferred operating language, e.g., French,
`
`English, German,etc., the nameof the operating system oftheclient
`computer, any version numberthat may be associated with the operating
`
`system, the existence of one or more other componentsofthe client
`
`computer, and/or a user identification number. Jd. at 4:43—S2.
`
`14
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`The componentserver analyzes the upgrade request and determines
`
`the appropriate version of the componentthat the user requested. Jd. at
`
`7:49-56. In particular, an upgrade handler module in the componentserver
`
`“uses the client conditions to select components that are compatibly operable
`
`with the client computer 104.” Jd. at 9:59-61. “For example, the upgrade
`
`handler module 134 selects components and/or version of components 102
`
`that are in a language whichis preferred by the user, i.e., English, French,
`
`German.” Jd. at 9:61-65. Additionally, the upgrade handler module can
`
`optionally determine one or more additional components that are necessary
`
`for proper operation in addition to those components requested by the client
`
`computer. Jd. at 9:66—10:2. In one embodiment, the dependency
`
`information is stored in the component database. Jd. at 10:9-10. After the
`
`componentserver makesthe selection, it generates an upgrade response
`
`messagethat identifies the locations of the components requested by the
`
`client computer. Jd. at 7:56—-59.
`
`2. List ofKnown Acceptable Configurations
`
`Petitioner asserts that Pitzel teaches the “list of known acceptable
`
`configurations.” Pet. 48-50. Petitioner contends that Pitzel’s component
`
`server performs two comparisonsthat meet the claim limitation. As to the
`
`first comparison, Petitioner contends that the componentserver stores
`
`“dependency information”in a database “so that when a version of a
`
`requested componentto be installed on the client requires an additional
`
`componentfor proper operation, and that additional componentis missing,
`
`the additional componentcan be identified and provided to the client.” Jd. at
`
`49. Thus, Petitioner argues, Pitzel discloses comparing the client conditions
`
`15
`
`
`
`TPR2019-00056
`Patent 6,467,088 Bl
`
`and the additional component with “information about known compatible or
`
`incompatible configurations.” Jd.
`
`Asto the second comparison, Petitioner contends that the client
`
`conditions identify multiple components ofthe client. Jd. For instance,
`
`Petitioner arguesthat the client conditions include a nameor version number
`of the operating system, one or more components of the client computer,
`
`product information, distribution codes, and a unique identifier associated
`
`with a microprocessor. Jd at 49-50. Petitioner argues that each of these
`
`“client conditions” is both a “device component required to implementthe
`
`reconfiguration request” and an “additional component currently
`
`implementedin the electronic device.” Jd. at 50. According to Petitioner
`
`then, Pitzel teaches the comparison of one of the components identified in
`
`the client conditions, and another componentidentified in the client
`
`conditions, with the “information about known compatible or incompatible
`configurations.” Id.
`|
`For both of Petitioner’s alleged comparisons, Petitioner alludes to
`
`“information about known compatible or incompatible configurations”in
`
`Pitzel as disclosing the recited “list of known acceptable configurations” and
`
`“list of known unacceptable configurations.” The Petition does not explain,
`
`nor do wefind, how Pitzel discloses, teaches, or suggests, a “list of known
`
`acceptable configurations”or a “list of known unacceptable configurations”
`
`by alluding to “information about known compatible or incompatible
`
`configurations.” The conclusory assertion and lack of factual support
`
`thereof is further confirmed by closer study of Pitzel and Petitioner’s
`
`contentions.
`
`First, we are not persuadedthat Pitzel supports Petitioner’s assertions
`
`of a comparison with a “list.” Petitioner asserts that Pitzel’s component
`16
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`server selects components that are compatibly operable with the client. See
`
`Pet. 48 (citing Ex. 1005, 7:53-56). This is not a disclosure of the required
`
`comparison. From this disclosure, at best, we can infer the result of
`
`componentselection based on compatibility—but this statement does not
`
`teach how Pitzel performsthe selection. Further, the claim requires a
`
`specific comparison of two pieces of information (determined component
`
`and one additional component) with the required “at least one of a list of
`
`known acceptable configurations anda list of a known unacceptable
`
`configurations.” But Petitioner does not explain how Pitzel teaches the
`
`required comparison with either of the recited lists of known configurations.
`
`Pitzel states that the upgrade handler module selects components and/or
`
`version of componentsthat are in a language whichis preferred by the user,
`
`i.e., English, French, German. Ex. 1005, 9:61-65. At best Pitzel compares
`
`a requested component with a client condition, whichis alleged to be the
`
`“additional componentcurrently implementedin the electronic device.” For
`
`instance, Pitzel may examinethe client conditions to determine that the user
`
`prefers French language, and thus selects the French version of a software
`
`requested by the user. There is no disclosure in Pitzel ensuring that the
`
`selected French version of the requested software is compatible or otherwise
`
`listed as a “known acceptable configuration.” Again, the Petition merely
`
`states that there is a comparison with “information about known compatible
`
`or incompatible configurations” in Pitzel, without explanation orfactual
`
`support.
`
`Second, for both alleged comparisons, Petitioner simply restates the
`
`claim languagealluding to “information about known compatible or.
`
`incompatible configurations” as disclosing the recited lists. Pet. 48
`
`17
`
`
`
`IPR2019-00056
`Patent 6,467,088 Bl
`
`(“information about known compatible or incompatible configurations (‘at
`
`least one of a list of known acceptable configurations for the electronic
`
`device anda list of known unacceptable configurations for the device’),” 49
`
`(“information about known compatible or incompatible configurations (‘at
`
`least one of a list of known acceptable configurations for the electronic
`
`device andalist of known unacceptable configurations for the device’).”
`
`- Neither of Petitioner’s statements shows what specific disclosure of Pitzel
`
`Petitioner contends is evidence of “information about known compatible or
`
`incompatible configurations.” Further, relying on the Knutson Declaration
`
`as supporting these statements is to no avail because the Knutson
`
`Declaration repeats these statements verbatim with no further explanation or
`
`factual support. See Knutson Decl. {J 159, 160. Thus, we accord the
`
`Knutson Declaration little to no weight on this point. See Verlanderv.
`
`Garner, 348 F.3d 1359, 1371 (Fed. Cir. 2003) (Board hasdiscretion to
`
`accordlittle weight to broad conclusory statements from expert witness); see
`
`also 37 C.F.R. § 42.65(a) (explaining that experts are required to provide
`supporting facts or data for their opinions).
`
`Third, Petitioner has not shown persuasively that the embodiment of
`
`the dependency information stored in the componentserver database teaches
`
`the recited comparison with the required “list.” Pitzel states that the upgrade
`handler module examinestheclient conditions to determinethe existence of
`
`necessary components, and, if missing, to supply these componentsin
`
`addition to the requested component. Ex. 1005, 10:5—10. Pitzel, thus,
`
`describes identifying missing components,in addition to the component
`
`requested bythe client. If the missing componentis the recited “device
`
`componentrequired to implement the reconfiguration request,” as Petitioner
`
`contends, then the claim requires comparing that “missing” or dependent
`18
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`
`component and the “additional componentcurrently implemented in the
`
`electronic device” with the “list of known acceptable configurations.”
`
`Pitzel, however, at best, compares the client conditions with the dependent
`
`components, to identify whether those dependent components are missing in
`
`the client device. Following Petitioner’s characterization of Pitzel, there is
`
`no comparison with the “list of known acceptable configurations” because
`
`Pitzel merely compares the missing component(“determined component”)
`
`with the client conditions (“information specifying at least one additional
`
`componentcurrently implementedin the electronic device”). Pitzel does not
`
`describe any otherlists or any other selections that arguably constitute
`
`comparisons with the requiredlist.
`
`Consequently, we are not persuadedthat Petitioner has shownthat
`
`Pitzel alone teaches the comparison limitation because, at a minimum,it
`
`does not teach the comparison with “a listof known acceptable
`
`configurations for the electronic device” and Petitioner has failed to explain
`
`and factually support its assertion that Pitzel teaches this element of the
`
`claim.
`
`Petitioner further argues that “Patent Owner mayarguethat Pitzel
`
`does not disclose a ‘list of known acceptable configurations for the
`
`electronic device and a list of known unacceptable configurations for the
`
`electronic device’ and thus does not compare components with suchalist.”
`
`Pet. 50. Petitioner then argues that “database tables and other such lists of
`
`acceptable and unacceptable configurations were well-knownat the time of
`
`the alleged invention.” Jd. at 50-51 (citing Knutson Decl. § 162). Atthis
`
`point in the Petition, Cole is relied upon as “disclos[ing] a ‘selection server’
`
`that utilizes a database table to identify potentially appropriate code updates
`
`for aclient.” Jd. at 51. Petitioner posits that it would have been obvious “to
`19
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1 -
`
`modify Pitzel, so that, in determining whetherparticular versions o