throbber
Trials@uspto.gov
`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
`
`
`
`
`
`
`
`

`

`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:69. The ’088 patent explains that prior art systems developed
`for updating components of electronic devices rely on a central computer
`system that tracks all software configurations for a number of remote
`systems. Id. at 1:3136. These prior art systems updated software by the
`central computer transmitting patches to each of the remote systems. Id. at
`1:3942; see also 2:410 (explaining that a distributed system transmits
`patches to mobile units). Other known techniques for software update
`involve assuming that each desktop computer has a set of resources
`determined in accordance with a set of enterprise policies or a central server
`maintaining a master list that is used to keep files on a remote device
`
`
`
`2
`
`

`

`IPR2019-00056
`Patent 6,467,088 B1
`updated to the latest version. Id. at 1:4952, 1:6065. According to the
`’088 patent, all of the above techniques fail to avoid potential conflicts and
`ensure compatibility because they do not account for interdependencies of
`the resources required by the desktops or the files resident in the remote
`devices. Id. at 1:4145, 1:5256, 1:652:3, 2:1014.
`The ’088 patent solves the problem by providing a list or listing, that
`indicates “which of a set of software components supported by the manager
`10 are known to work well together or are otherwise compatible.” Id. at
`3:3642. For instance, Figure 1 of the ’088 patent, reproduced below,
`illustrates reconfiguration manager 10 that includes a listing 16 of known
`configurations, and a repository 18 of software components. Id. at 3:2729.
`
`
`
`
`3
`
`
`
`

`

`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:1416.
`When reconfiguration manager 10 receives a request for an upgrade from
`Device X, the request indicates that the device wants to upgrade to version
`2.0 of software component A, and includes a list of the components
`currently on the device, i.e., version 1.1 of component A, version 2.0 of
`component C, and version 2.3 of component B. Id. at 4:1219.
`Reconfiguration manager 10 processes the request, and if appropriate,
`delivers the requested version 2.0 of software component A. Id. at 4:2226.
`Processing the request involves generating a potential upgrade configuration
`that will satisfy the received request, and searching through a set of known
`“bad” configurations. Id. at 4:6266. A known “bad” configuration is
`indicated in Figure 1 as a dashed line between components that are not
`compatible. Id. at 4:5861. For example, the pair including version 1.8 of
`component A and version 1.0 of component C is an example of a known bad
`configuration. Id. at 3:6163.
`If the upgrade configuration corresponds to a bad configuration, the
`reconfiguration manager attempts to find a set or sets of potential upgrade
`configurations from a set of known “good” configurations. Id. at 4:675:3.
`A known “good” configuration is indicated in Figure 1 by a solid line
`between a given pair of components indicating that the components work
`well together or are otherwise compatible. Id. at 3:5255.
`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
`
`

`

`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 23. 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 34.
`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
`
`

`

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

`

`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
`121
`§ 103 Pitzel, Cole, and Elgressy
`121
`
`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
`
`

`

`IPR2019-00056
`Patent 6,467,088 B1
`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 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. 45.
`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. 610. 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
`
`

`

`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 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 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:3035. Alternatively, a
`client can periodically request all updates, and the server will respond
`accordingly. Id. at 1:3738. Because of cost, download time, or other
`reasons, some clients may not wish to obtain the update. Id. at 1:3436,
`1:3840.
`Cole, therefore, describes a server that identifies code updates that are
`consistent with basic system characteristics of the client computer. Id. at
`1:4549. 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:4954. 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
`
`
`
`

`

`IPR2019-00056
`Patent 6,467,088 B1
`1:5459. 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:5962. 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:6265.
`2. List of Known 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 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:654: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:654: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. 89. 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
`
`

`

`IPR2019-00056
`Patent 6,467,088 B1
`client. Id. at 9 (citing Ex. 1002, 3:624: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:4250. 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: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.” Id. at 3:6265.
`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:654: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
`
`

`

`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:3547. Each of the recognizer
`programs is very small, and downloads much faster than the actual code
`update. Id. at 4:4852. 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:5358 (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:57 (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:811. Therefore, Cole’s recognition programs may indicate 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 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 121 would have been obvious over
`Pitzel, Cole, and Elgressy. Pet. 4268.
`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:612. Pitzel explains that typically a
`user visits an “update” server that hosts the improved computer programs.
`Id. at 1:3132. 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:3336. For example, a user may be
`
`
`
`13
`
`

`

`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:3642. Thus, Pitzel seeks
`automatic downloading of an appropriate version of a computer program
`without user intervention. Id. at 1:4749.
`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:1519. The user then accesses a configuration server that
`hosts configuration files. Id. at 7:2124. A configuration file contains the
`configuration information for the installation of one or more components on
`the client computer. Id. at 5:1012. For each component there is associated
`a configuration file. Id. 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. Id. at
`7:2227. Clicking the hyperlink causes the configuration server to
`download the configuration file to the client computer. Id. at 7:2730. The
`client computer determines the client conditions and forwards the
`configuration file and the client conditions to the component server. Id. at
`7:4044. 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:4044.
`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:4352.
`
`
`
`14
`
`

`

`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:4956. 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:5961. “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: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. Id. at 9:6610:2. In one embodiment, the dependency
`information is stored in the component database. Id. at 10:910. 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:5659.
`2. List of Known 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 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
`
`

`

`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 4950. 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
`
`
`
`

`

`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
`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:6165. 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
`
`

`

`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:510. 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
`
`
`
`

`

`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 acceptable configurations for the
`electronic device and a

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

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

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

throbber

A few More Minutes ... Still Working

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

Thank you for your continued patience.

This document could not be displayed.

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

Your account does not support viewing this document.

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

Your account does not support viewing this document.

Set your membership status to view this document.

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

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

Become a Member

One Moment Please

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

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

Your document is on its way!

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

Sealed Document

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

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


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket