`571.272.7822
`
`Paper No. 7
` Filed: April 29, 2019
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`____________
`
`Case IPR2019-00056
`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
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314(a) and 37 C.F.R. § 42.108
`
`Page 1 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`Apple Inc. (“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. Paper 6 (“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 . . . 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 given below, we determine Petitioner 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 components in electronic devices.
`Ex. 1001, 1:69. 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:3136. These prior art systems updated software by the
`central computer transmitting patches to each of the remote systems. Id. at
`1:3942; see also 2:410 (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
`
`2
`
`Page 2 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`updated to the latest version. Id. at 1:4952, 1:6065. 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:4145, 1:5256, 1:652:3, 2:1014.
`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:3642. 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:2729.
`
`3
`
`Page 3 of 22
`
`
`
`IPR2019-00056
`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:1416.
`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:1219.
`Reconfiguration manager 10 processes the request, and if appropriate,
`delivers the requested version 2.0 of software component A. Id. at 4:2226.
`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:6266. A known “bad” configuration is
`indicated in Figure 1 as a dashed line between components that are not
`compatible. Id. at 4:5861. 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:6163.
`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:675: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:5255.
`2. Prosecution History
`During prosecution of the ’088 patent, the Examiner issued 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
`
`Page 4 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`teaches all 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. Id. at 3.1 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 23. Thus, Applicant argued, although Carroll teaches the use of a
`profile comparison to install software, Carroll did not teach the limitation of
`“comparing the determined component and information specifying at least
`one additional component currently implemented in the electronic device
`with at least one of a list of known acceptable configurations for the
`electronic device and a list of known unacceptable configurations for the
`electronic device.” Id. at 34.
`The Examiner, in response to Applicant’s arguments, issued a Notice
`of Allowability of all pending claims stating:
`The applicant argues that Carrol[l] 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 component to at least one of an acceptable or an
`unacceptable list. Carrol[l], as indicated in the previous
`action compares
`the
`requested component with an
`acceptable list (one of an acceptable and an unacceptable
`
`1 Page numbers to this Exhibit refer to the page number in the original
`Office Action.
`
`5
`
`Page 5 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`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 over the 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:
`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
`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:4359. 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
`The Petition 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”);
`
`
`
`
`6
`
`Page 6 of 22
`
`
`
`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
`121
`§ 103
`Pitzel, Cole, and Elgressy
`121
`
`II. 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);2 see Cuozzo Speed Techs., LLC v. Lee, 136 S.
`Ct. 2131, 2144–46 (2016). We presume a claim term carries its “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. In re
`Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007) (citation
`omitted).
`
`1. “list”
`The independent claims of the ’088 patent recite “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.” Ex. 1001,
`
`2 A recent amendment to this rule does not apply here because the Petition
`was filed 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
`
`Page 7 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`6:5356, 7:4851, 7:5962, 8:5962. 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:68 (“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 argues that “the Board need not construe any term
`in a particular manner in order to arrive at the conclusion that the Petition is
`substantively deficient.” Prelim. Resp. 45.
`Upon review of the arguments presented by Patent Owner, we note
`that Patent Owner distinguishes the asserted prior art on the basis of the
`“list” term. For example, Patent Owner argues that Cole does not disclose
`the recited list of “known acceptable configuration for the electronic device”
`and the list of “known unacceptable configurations for the electronic
`device.” See Prelim. Resp. 610. In particular, Patent Owner argues that
`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 purposes of this
`Decision Patent Owner’s proposed construction of “known” to mean
`previously determined.
`
`2. Other Claim Terms
`On this 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
`
`8
`
`Page 8 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`(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 121 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 on results 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 involves registering the client
`with the server so that the server may automatically send the code updates to
`every client on the list of registered clients. Id. at 1:3035. Alternatively, a
`client can periodically request all updates, and the server will respond
`accordingly. Id. at 1:3738. Because of cost, download time, or other
`reasons, some clients may not wish to obtain the update. Id. at 1:3436,
`1:3840.
`Cole, therefore, describes a server that identifies code updates that are
`consistent with basic system characteristics of the client computer. Id. at
`1:4549. Then, the client computer utilizes a “recognizer” program, which
`the client computer obtains from a server, to determine whether the client
`computer has a version other than a current version of the identified code
`updates. Id. at 1:4954. The client then sends the results of the recognizer
`program to the server computer, which generates a list of code updates that
`are consistent with the basic characteristics representing programs that exist
`on the client computer for which an update would be appropriate. Id. at
`9
`
`
`
`Page 9 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`1:5459. Then the server computer sends the list of code updates to the
`client computer so that a user of the client computer can select a code update
`from the list. Id. at 1:5962. In response, the server computer sends
`addresses of the selected code updates to the client computer and the client
`computer downloads the selected code updates. Id. at 1:6265.
`2. List of Known Acceptable Configurations
`Petitioner argues that Cole, in combination with MacInnis and
`
`Elgressy, teaches the comparing step. Pet. 2028. More specifically as to
`the “list,” Petitioner contends that Cole teaches the “list of known acceptable
`configurations” by providing an example table that lists code updates and
`basic system requirements metadata. Id. 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.DRV is “potentially appropriate for the client.” Id. at
`22 (citing Ex. 1002, 3:654:30). Petitioner also argues that “the device
`driver file named FGHIJ.DRV is inappropriate for the client and is
`eliminated from further consideration, because its required BIOS level (i.e.
`BIOS level 456), does not match the BIOS level of the client.” Id. (citing
`Ex. 1002, 3:654:34; Knutson Decl. ¶ 77).
`Patent Owner argues that Cole does not teach the “list of known
`acceptable configurations,” at least in part because the alleged
`configurations in Cole are not known. Prelim. Resp. 89. In particular,
`Patent Owner points 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 updates are potentially appropriate for” the
`
`
`
`10
`
`Page 10 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`client. Id. at 9 (citing Ex. 1002, 3:624:1). Patent Owner argues that the
`match is, at best, potentially appropriate, and, therefore, is not known that the
`code update is an “acceptable configuration.” Id.
`We are 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:4250. The selection server determines which
`code updates are “consistent with the basic system information of the client
`and which code updates are inconsistent thereby eliminating the vast
`majority of the code updates stored in content server 17 . . . from further
`consideration.” Id. at 3:5660 (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.” Id. at 3:6265.
`Thus, from this description, it appears that Cole performs a comparison
`between some aspects 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 some of the basic system
`information; but Cole describes the selected code updates as “potentially
`appropriate for client 14.” Id. at 3:654:1. Therefore, neither the client nor
`the server anticipates that the selected code updates at this point are actually
`a “known acceptable configuration for the electronic device.” Although the
`code updates at this point match some criteria 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
`
`Page 11 of 22
`
`
`
`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 of its 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 corresponding to the
`potentially appropriate code updates. Id. at 4:3547. Each of the recognizer
`programs is very small, and downloads much faster than the actual code
`update. Id. at 4:4852. This additional step is necessary because Cole states
`that “based on the basic system information alone, the selection update
`program 30 within server 12 is not sure which of the 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.” Id. at
`4:5358 (emphasis added). Thus, none of the potentially appropriate code
`updates may actually 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:57 (emphasis added). Further, Cole
`states that the recognizer program “could also determine if the
`corresponding code update is consistent with aspects of the client other than
`the basic system information, such as other programs within the client.” Id.
`at 5:811. Therefore, Cole’s recognition programs may indicate that the
`“potentially appropriate” code updates were actually not appropriate for the
`
`12
`
`Page 12 of 22
`
`
`
`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 persuaded that 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 121 would have been obvious over
`Pitzel, Cole, and Elgressy. Pet. 4268.
`1. Overview of Pitzel
`Pitzel is directed to a system and method for updating information via
`a network, and particularly, updating computer programs based upon client-
`specific information. Ex. 1005, [54], 1:612. Pitzel explains that typically a
`user visits an “update” server that hosts the improved computer programs.
`Id. at 1:3132. Users are often confused and download the incorrect version
`of the requested software because a number of possible versions are
`available for downloading. Id. at 1:3336. For example, a user may be
`
`
`
`13
`
`Page 13 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`interested in a “French” version, but the user may not know the version of an
`operating system or whether other computer programs are required for
`proper operation of the upgrade. Id. at 1:3642. Thus, Pitzel seeks
`automatic downloading of an appropriate version of a computer program
`without user intervention. Id. at 1:4749.
`Pitzel thus describes a method for installing components on the client
`computer by first having the user at the client computer initiate an upgrade
`request. Id. at 7:1519. The user then accesses a configuration server that
`hosts configuration files. Id. at 7:2124. A configuration file contains the
`configuration information for the installation of one or more components on
`the client computer. Id. at 5:1012. For each component there is associated
`a configuration file. Id. at 5:2022. 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. Id. at
`7:2227. Clicking the hyperlink causes the configuration server to
`download the configuration file to the client computer. Id. at 7:2730. The
`client computer determines the client conditions and forwards the
`configuration file and the client conditions to the component server. Id. at
`7:4044. The client conditions are stored in a computer profile such that
`when a component is designated for installation, a version of the component
`that is compatible with the client conditions may be selected. Id. at 5:4044.
`The client conditions include: a preferred operating language, e.g., French,
`English, German, etc., the name of the operating system of the client
`computer, any version number that may be associated with the operating
`system, the existence of one or more other components of the client
`computer, and/or a user identification number. Id. at 4:4352.
`
`14
`
`Page 14 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`The component server analyzes the upgrade request and determines
`the appropriate version of the component that the user requested. Id. at
`7:4956. In particular, an upgrade handler module in the component server
`“uses the client conditions to select components that are compatibly operable
`with the client computer 104.” Id. at 9:5961. “For example, the upgrade
`handler module 134 selects components and/or version of components 102
`that are in a language which is preferred by the user, i.e., English, French,
`German.” Id. at 9:6165. 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. Id. at 9:6610:2. In one embodiment, the dependency
`information is stored in the component database. Id. at 10:910. After the
`component server makes the selection, it generates an upgrade response
`message that identifies the locations of the components requested by the
`client computer. Id. at 7:5659.
`2. List of Known Acceptable Configurations
`Petitioner asserts that Pitzel teaches the “list of known acceptable
`configurations.” Pet. 4850. Petitioner contends that Pitzel’s component
`server performs two comparisons that meet the claim limitation. As to the
`first comparison, Petitioner contends that the component server stores
`“dependency information” in a database “so that when a version of a
`requested component to be installed on the client requires an additional
`component for proper operation, and that additional component is missing,
`the additional component can be identified and provided to the client.” Id. at
`49. Thus, Petitioner argues, Pitzel discloses comparing the client conditions
`
`
`
`15
`
`Page 15 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`and the additional component with “information about known compatible or
`incompatible configurations.” Id.
`As to the second comparison, Petitioner contends that the client
`conditions identify multiple components of the client. Id. For instance,
`Petitioner argues that the client conditions include a name or 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. Id at 4950. Petitioner argues that each of these
`“client conditions” is both a “device component required to implement the
`reconfiguration request” and an “additional component currently
`implemented in the electronic device.” Id. at 50. According to Petitioner
`then, Pitzel teaches the comparison of one of the components identified in
`the client conditions, and another component identified 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 we find, 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 persuaded that Pitzel supports Petitioner’s assertions
`of a comparison with a “list.” Petitioner asserts that Pitzel’s component
`16
`
`
`
`Page 16 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`server selects components that are compatibly operable with the client. See
`Pet. 48 (citing Ex. 1005, 7:5356). This is not a disclosure of the required
`comparison. From this disclosure, at best, we can infer the result of
`component selection based on compatibility—but this statement does not
`teach how Pitzel performs the 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 and a 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 components that are in a language which is preferred by the user,
`i.e., English, French, German. Ex. 1005, 9:6165. At best Pitzel compares
`a requested component with a client condition, which is alleged to be the
`“additional component currently implemented in the electronic device.” For
`instance, Pitzel may examine the 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 or factual
`support.
`Second, for both alleged comparisons, Petitioner simply restates the
`claim language alluding to “information about known compatible or
`incompatible configurations” as disclosing the recited lists. Pet. 48
`
`17
`
`Page 17 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`(“information about known compatible or incompatible configurations (‘at
`least one of a list of known acceptable configurations for the electronic
`device and a 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 and a list 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. ¶¶ 159, 160. Thus, we accord the
`Knutson Declaration little to no weight on this point. See Verlander v.
`Garner, 348 F.3d 1359, 1371 (Fed. Cir. 2003) (Board has discretion to
`accord little 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 component server database teaches
`the recited comparison with the required “list.” Pitzel states that the upgrade
`handler module examines the client conditions to determine the existence of
`necessary components, and, if missing, to supply these components in
`addition to the requested component. Ex. 1005, 10:510. Pitzel, thus,
`describes identifying missing components, in addition to the component
`requested by the client. If the missing component is the recited “device
`component required to implement the reconfiguration request,” as Petitioner
`contends, then the claim requires comparing that “missing” or dependent
`18
`
`
`
`Page 18 of 22
`
`
`
`IPR2019-00056
`Patent 6,467,088 B1
`component and the “additional component currently 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
`component currently implemented in the electronic device”). Pitzel does not
`describe any other lists or any other selections that arguably constitute
`comparisons with the required list.
`Consequently, we are not persuaded that Petitioner has shown that
`Pitzel alone teaches the comparison limitation because, at a minimum, it
`does not teach the comparison with “a list of 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 may argue that Pitzel
`does not disclose a ‘list of known acceptab