UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`
`IPR2020-00023
`Patent 6,467,088
`
`
`_________________
`
`
`PETITIONER’S REPLY TO
`PATENT OWNER’S RESPONSE TO PETITION
`
`
`
`
`
`
`
`
`
`
`
`
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`
`IPR2020-00023
`Patent 6,467,088
`
`
`_________________
`
`
`PETITIONER’S REPLY TO
`PATENT OWNER’S RESPONSE TO PETITION
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2020-00023
`Patent 6,467,088
`
`TABLE OF CONTENTS
`
`V.
`
`Page(s)
`EXHIBIT LIST ......................................................................................................... iv
`I.
`INTRODUCTION ........................................................................................... 1
`II.
`PATENT OWNER OFFERS NO
`EXPERT, RELIES ON ATTORNEY ARGUMENT .................................... 1
`III. PATENT OWNER OFFERS NO
`COMPETING POSITA PROPOSAL ............................................................. 2
`IV. PATENT OWNER OFFERS NO
`COMPETING CLAIM CONSTRUCTION .................................................... 2
`PATENT OWNER’S ASSERTIONS REGARDING APFEL’S
`TEACHINGS MISCONSTRUE BOTH THE REFERENCE AND
`THE PETITION, AND THE PETITION’S OBVIOUSNESS SHOWING .... 3
`A. Apfel Clearly Teaches Evaluating “Determined Component”
`Needed For Upgrade And “At Least One Additional
`Component Currently Implemented In The Electronic Device” .......... 3
`B. Apfel Clearly Teaches
`Determining That Certain Upgrades
`Are Known To Be Compatible With Certain
`Configurations In Determining Configurations
`That “Should Result In Their Download” By A User ........................... 4
`C. Apfel’s Related Disclosures Of “Require[d]
`Upgrade Packages” That The User “Should Install” ............................ 9
`D. Apfel Is Not Cumulative To The
`Apple IPR’s Primary Cited Reference ................................................ 10
`
`
`
`Page i
`
`
`
`IPR2020-00023
`Patent 6,467,088
`
`B.
`
`C.
`
`VI. PATENT OWNER’S ASSERTIONS
`REGARDING APFEL’S COMBINATION WITH TODD
`AND LILLICH MISCONSTRUE THE REFERENCES, THE
`PETITION, AND THE ’088 PATENT’S OWN DESCRIPTION,
`ARE CONFUSING, AND DO NOT REBUT THE CLAIMS’
`OBVIOUSNESS OVER APFEL, LILLICH, AND TODD .......................... 15
`A.
`Patent Owner Misconstrues Lillich’s
`Teachings And Their Combination With Apfel .................................. 15
`Patent Owner Likewise Misconstrues Todd’s
`Teachings And Their Combination With Apfel .................................. 19
`Patent Owner’s Assertion That Apfel Is Limited
`To “One Specific Computer Application” Is Incorrect ....................... 23
`Patent Owner’s Assertion That Lillich And
`Todd Were Only Presented As Alternatives Is Simply Wrong .......... 26
`Patent Owner’s Critique Of The Lillich/Todd
`Combination Is Incorrect, As The Board Has Already Found ............ 27
`Patent Owner’s Critique Of The Apfel/Lillich/Todd/Pedrizetti
`Combination Waived Any Additional Substantive Challenges .......... 27
`VII. CONCLUSION .............................................................................................. 28
`CERTIFICATE OF COMPLIANCE WITH
`TYPE-VOLUME LIMITATION PURSUANT TO 37 C.F.R. § 42.24 .................. 29
`CERTIFICATE OF SERVICE
`
`
`D.
`
`E.
`
`F.
`
`
`
`Page ii
`
`
`
`TABLE OF AUTHORITIES
`
`IPR2020-00023
`Patent 6,467,088
`
`Page(s)
`
`Cases
`Elbit Sys. of Am., LLC v. Thales Visionix, Inc.,
`881 F.3d 1354 (Fed. Cir. 2018) .............................................................................. 2
`Icon Health & Fitness, Inc. v. Strava, Inc.,
`849 F.3d 1034 (Fed. Cir. 2017) .............................................................................. 2
`In re Bond,
`910 F.2d 831 (Fed. Cir. 1990) ..............................................................................22
`Inwood Labs., Inc. v. Ives Labs., Inc.,
`456 U.S. 844 (1982) ............................................................................................... 2
`Trs. of Columbia Univ. v. Illumina, Inc.,
`620 Fed. Appx. 916 (Fed. Cir. 2015) ..................................................................... 2
`Statutes
`35 U.S.C. § 103 ........................................................................................................28
`
`
`
`
`
`
`
`Page iii
`
`
`
`IPR2020-00023
`Patent 6,467,088
`
`EXHIBIT LIST
`LIST OF NEWLY FILED EXHIBITS
`
`Concurrently filed with Petitioner’s Reply to Patent Owner’s Response to Petition:
`
`No.
`1016
`
`Description
`Supplemental Declaration of John Villasenor, signed and dated
`September 27, 2020 (“Villasenor Supp.”)
`
`
`LIST OF PREVIOUSLY FILED EXHIBITS
`
`Description
`No.
`1001 U.S. Patent No. 6,467,088, “Reconfiguration manager for
`controlling upgrades of electronic devices,” issued October 15,
`2002 (the “’088 patent or “’088”)
`File History for U.S. Patent No. 6,467,088, Application No.
`09/343,607 (the “’088 FH”)
`1003 Declaration of John Villasenor (“Villasenor”), including Appendix
`A thereto
`
`1002
`
`1004 U.S. Patent No. 5,974,454, “Method and system for installing and
`updating program module components,” issued October 26, 1999
`from an application filed November 14, 1997 (“Apfel”)
`1005 U.S. Patent No. 5,613,101, “Method and apparatus for determining
`at execution compatibility among client and provider components
`where provider version linked with client may differ from provider
`version available at execution,” issued March 18, 1997 from an
`application filed June 7, 1995 (“Lillich”)
`1006 U.S. Patent No. 5,867,714, “System and method for distributing
`configuration-dependent software revisions to a computer system,”
`
`
`
`Page iv
`
`
`
`No.
`
`IPR2020-00023
`Patent 6,467,088
`
`Description
`issued February 2, 1999 from an application filed October 31, 1996
`(“Todd”)
`1007 U.S. Patent No. 6,151,708, “Determining program update
`availability via set intersection over a sub-optical pathway,” issued
`November 21, 2000 from an application filed December 19, 1997
`(“Pedrizetti”)
`Complaint in Uniloc 2017 LLC v. Microsoft Corporation, 8:19-cv-
`00956 (C.D. Cal.), filed May 20, 2019 (“Uniloc Complaint”)
`Plaintiff’s “Disclosure of Asserted Claims And Infringement
`Contentions”, dated July 29, 2019, including Exhibit B thereto
`(“Uniloc Contentions”)
`Petition in Apple Inc. v. Uniloc 2017 LLC, IPR2019-00056
`(P.T.A.B.), filed October 17, 2018 (“Apple IPR Petition”)
`Patent Owner Preliminary Response in Apple Inc. v. Uniloc 2017
`LLC, IPR2019-00056 (P.T.A.B.), filed February 8, 2019 (“Apple
`IPR POPR”)
`PTAB Decision in Apple Inc. v. Uniloc 2017 LLC, IPR2019-00056
`(P.T.A.B.), issued April 29, 2019 (“Apple IPR Decision”)
`List of Uniloc Asserted Patents, downloaded from Docket
`Navigator on October 7, 2019 (“Uniloc Patent List”)
`List of IPRs involving Uniloc Patents, downloaded from Docket
`Navigator on October 7, 2019 (“Uniloc IPR List”)
`Stipulation to Extend Time to Respond To Initial Complaint By
`Not More Than 30 Days (L.R. 8-3) in Uniloc 2017 LLC v.
`Microsoft Corporation, 8:19-cv-00956 (C.D. Cal.), filed May 24,
`2019 (“Stipulated Extension of Time”)
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`
`
`
`
`
`Page v
`
`
`
`IPR2020-00023
`Patent 6,467,088
`
`I.
`
`INTRODUCTION
`Uniloc’s Patent Owner Response To Petition (Paper 10, “POR”) contains
`
`several assertions that appear to misapprehend the cited references, the Petition’s
`
`statements regarding them, or both. Further, the POR attempts to improperly inject
`
`added elements into the claims, or to implicitly interpret the claims in a manner
`
`inconsistent with the undisputed explicit proper interpretation of the claim language
`
`set forth in the Institution Decision, which Patent Owner does not dispute.
`
`Taken in context, it is clear that the reference combinations cited in the
`
`Petition clearly teach or suggest the combined elements of the challenged claims, as
`
`those elements would have been understood by a POSITA.
`
`II.
`
`PATENT OWNER OFFERS NO EXPERT,
`RELIES ON ATTORNEY ARGUMENT
`In its Petition (Paper 2, “Petition”), Petitioner proffered the expert testimony
`
`of Dr. John Villasenor (“Villasenor”), establishing his credentials. Dr. Villasenor
`
`was subject to cross-examination, and his credentials are subject to the Board’s
`
`scrutiny.
`
`Rather than cross-examine him, Patent Owner’s Response relies on attorney
`
`argument to rebut Dr. Villasenor’s conclusions. Patent Owner offers no expert.
`
`Dr. Villasenor testified as a sworn declarant subject to cross-examination; Patent
`
`Owner’s attorneys cannot. Dr. Villasenor’s qualifications and the evidentiary basis
`
`for his conclusions are both clearly established.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 1
`
`
`
`IPR2020-00023
`Patent 6,467,088
`It is the PTAB’s province to weigh the credibility of witnesses. See Trs. of
`
`Columbia Univ. v. Illumina, Inc., 620 Fed. Appx. 916, 922 (Fed. Cir. 2015); Inwood
`
`Labs., Inc. v. Ives Labs., Inc., 456 U.S. 844, 856 (1982). This includes weighing
`
`relative merits of expert testimony and mere attorney argument. Petitioner’s
`
`admissible expert evidence cannot be rebutted by Patent Owner’s unsworn attorney
`
`argument. Elbit Sys. of Am., LLC v. Thales Visionix, Inc., 881 F.3d 1354, 1359 (Fed.
`
`Cir. 2018); Icon Health & Fitness, Inc. v. Strava, Inc., 849 F.3d 1034, 1043 (Fed.
`
`Cir. 2017).
`
`III. PATENT OWNER OFFERS NO
`COMPETING POSITA PROPOSAL
`The Board’s Institution Decision (Paper 7, “Decision”) adopted Petitioner’s
`
`articulation of a POSITA. Patent Owner offers no competing proposal.
`
`IV. PATENT OWNER OFFERS NO
`COMPETING CLAIM CONSTRUCTION
`In the Decision, the Board adopted the following constructions proposed in
`
`the Petition:
`
` “list”
`
`“known . . . for the electronic device”
`
`any stored representation of
`information indicative of component
`compatibility
`The term “known” means “previously
`determined” and the phrase “for the
`electronic device” does not require that
`the “list” of known acceptable and
`known unacceptable configurations be
`specific to the electronic device
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 2
`
`
`
`“at least one of”
`
`IPR2020-00023
`Patent 6,467,088
`
`To be read in accordance with the plain
`meaning of the phrase, namely as
`conjunctive lists of their respective
`elements, i.e., “at least one of [a] and at
`least one of [b].”
`
`Decision, 8. Again, Patent Owner offers no competing proposal.
`
`V.
`
`PATENT OWNER’S ASSERTIONS REGARDING APFEL’S
`TEACHINGS MISCONSTRUE BOTH THE REFERENCE AND
`THE PETITION, AND THE PETITION’S OBVIOUSNESS SHOWING
`A. Apfel Clearly Teaches Evaluating “Determined
`Component” Needed For Upgrade And “At Least One Additional
`Component Currently Implemented In The Electronic Device”
`The POR states that the Petition fails to prove obviousness of the “comparing”
`
`/ “compare” limitations, and states that the claims “expressly differentiate ‘the
`
`determined component’ from the ‘information specifying at least one additional
`
`component currently implemented in the electronic device’ at least in that only the
`
`latter element is identified as being ‘currently implemented in the electronic
`
`device.’” POR, 14. Patent Owner goes on to state that the “determined component
`
`… is a new component required to implement a requested reconfiguration of that
`
`device.” Id., 14–15.
`
`The Petition clearly sets forth Apfel’s consideration of both elements. First,
`
`the Petition identifies the determined components in Apfel as requested “upgrade
`
`packages”, e.g., “upgrade package[s] for the Web Authoring Components program
`
`module,” Petition, 37–38, quoting Apfel, 9:30–35, citing Villasenor ¶¶ 79–80;
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 3
`
`
`
`IPR2020-00023
`Patent 6,467,088
`Apfel, 6:49–53, 6:63–7:9, 8:53–66, 9:30–42. Second, the Petition points to an
`
`additional component as “as many as five different components that make up the
`
`configuration for the requesting computer” Petition, 39–40, citing Villasenor ¶¶ 81–
`
`82, quoting Apfel, 8:39–46, 53–66.
`
`B. Apfel Clearly Teaches Determining That Certain
`Upgrades Are Known To Be Compatible With
`Certain Configurations In Determining Configurations
`That “Should Result In Their Download” By A User
`The POR asserts that Petitioner’s inherency theory regarding the “known
`
`good” comparing step is flawed, because it relies on Apfel’s disclosure of identifying
`
`updates that “should” be installed. POR, 16–17, but then conflates this language with
`
`the inherency requirement for a result that “necessarily must be present.” Id., 16.
`
`The element that must “necessarily be present”––and which the Petition
`
`demonstrates is “necessarily present” in Apfel––is comparing to a list of “known
`
`acceptable configurations.” See, e.g., Petition, 41-42. As the Petition makes clear, in
`
`order to identify upgrade packages and corresponding configurations which
`
`“should” result in their download, Apfel’s system must necessarily have
`
`information on which proposed downloads are known to work with which existing
`
`configurations. Id.
`
`The POR addresses the term “should,” appearing in Apfel in column 9,
`
`stating:
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 4
`
`
`
`IPR2020-00023
`Patent 6,467,088
`The Petition acknowledges, however, that the cited portion
`of Apfel states “the database server 80a maintains a
`database of upgrade packages and corresponding
`configurations which should result in their download.”
`Id. (emphasis and underlining by Petitioner). The quoted
`statement provides
`an
`explicit
`acknowledgement
`concerning a “result” that only “should” occur—and
`hence admittedly may not. This indecisive “should result”
`language is itself independently fatal to the unsupported
`speculation that Apfel inherently discloses a given
`upgrade necessarily will download and operate as
`intended.
`
`
`
`The equivocating disclosure in Apfel concerning a “result”
`that only “should” occur, and hence admittedly will not
`necessarily occur, is cumulative with what the Board had
`considered, and found to be distinguishable, in related
`matter Apple Inc. v. Uniloc 2017 LLC, IPR2019-00056,
`Decision Denying Institution (Paper 7) (PTAB April 29,
`2019).
`
`POR, 17 (emphasis in original).
`
`The footnote accompanying this text states:
`
`Petitioner misleadingly states, without explanation, that
`Apfel’s use of the word “should” in this context refers to
`what “‘should’ be installed.” Pet. 42. But in the quoted
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 5
`
`
`
`IPR2020-00023
`Patent 6,467,088
`statement from Apfel, the word “should” modifies the
`word “result”
`that
`immediately
`follows,
`thereby
`expressing equivocation as to whether the result will
`occur.
`
`POR, 17, n. 2 (emphasis in original).
`
`Patent Owner’s assertion that the “should result” language is “independently
`
`fatal” to the use of Apfel as an invalidating reference is simply wrong. Patent
`
`Owner’s apparent assertion that this language raises uncertainty as to whether a
`
`given configuration presented to the user is known to be acceptable because it
`
`“express[es] equivocation as to whether the result will occur” (POR, 17) is likewise
`
`wrong.
`
`The action that “should result” is not determining that a given configuration
`
`is compatible or “comparing to a known list of acceptable configurations.” To the
`
`contrary, at the point that this choice on whether to perform a download(s) is
`
`presented to the user, the compatibility determination for the proposed downloads
`
`that “should result in their download” has already been performed. The “speculative”
`
`result in question is whether the user chooses to actually download the
`
`recommended upgrade. Villasenor Supp. ¶¶ 12–14.
`
`Nowhere in the Petition did Petitioner assert that “a given upgrade necessarily
`
`will download.” POR, 17 (emphasis in original). What Apfel does teach—and what
`
`Petition does rely on Apfel’s disclosure for—is that if the user chooses to download
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 6
`
`
`
`IPR2020-00023
`Patent 6,467,088
`the requested update, it has been previously identified as a “known good” update,
`
`one that works with the existing configuration of the user’s computer that is provided
`
`for consideration by the server as part of the reconfiguration request. Petition, 41–
`
`42.
`
`The independent claims do not require that an upgrade “necessarily” must
`
`occur, but rather require “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.” Claim 1 states, in pertinent part:
`
`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; 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.
`
`Villasenor Supp. ¶ 16, quoting claim 1.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 7
`
`
`
`IPR2020-00023
`Patent 6,467,088
`A given request can be approved or denied, but these claims do not require
`
`any actual download necessarily must occur.1 Claim 1 and the other independent
`
`claims require a list of configurations that are known to be acceptable. That is exactly
`
`what Apfel shows. Apfel makes this clear at least by the text in column 9 (including
`
`9:28–57) as well as Figures 4A and 4B. For instance, box 427 in Figure 4A identifies
`
`whether there is an upgrade. If the answer to the question “Is there an upgrade?” is
`
`“yes”, then in box 442 in Figure 4B the user is given the option to proceed with the
`
`upgrade or not to proceed. Villasenor Supp. ¶ 17.
`
`If the user does approve proceeding with the upgrade, it is downloaded and
`
`installed. There is no requirement in Apfel that the user elect to proceed with the
`
`upgrade, but Apfel is clear that if that election to proceed is made, then the upgrade–
`
`
`1 Petitioner notes that while claims 3 and 13 of the ’088 patent do require a method
`
`and an apparatus, respectively, for “download[ing] the determined component to the
`
`electronic device if the determined component and the additional component are
`
`consistent with a given one of the known acceptable configurations,” nowhere does
`
`Patent Owner specifically dispute the Petition’s demonstration that these additional
`
`dependent claim steps are shown in the cited reference combinations. Villasenor
`
`Supp. ¶ 15.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 8
`
`
`
`IPR2020-00023
`Patent 6,467,088
`—which is already known to be compatible by virtue of the fact that the choice to
`
`install it was given to the user––will be installed. Villasenor Supp. ¶¶ 17–18.
`
`C. Apfel’s Related Disclosures Of
`“Require[d] Upgrade Packages” That The User “Should Install”
`The POR takes issue with the Petition’s further citation of “require[d]”
`
`upgrade packages identified in Dr. Villasenor’s declaration:
`
`Not only are there certain upgrades that “should” be
`installed, but certain computer configurations, according
`to Apfel “require” certain upgrade packages. Apfel, 6:65-
`67. (“[E]ach configuration of computer 20 may require a
`different upgrade package and, therefore, a different
`URL.”)
`
`POR, 19; see also Villasenor Supp. ¶ 27, citing Villasenor ¶ 84.
`
`This is a fully accurate characterization of Apfel, as Dr. Villasenor explains.
`
`Apfel recognizes the requirement to ensure that an identified upgrade package is
`
`compatible with the configuration of the computer where it will ultimately be
`
`installed (if the user elect to proceed). Apfel further teaches that different
`
`configurations may require different upgrade packages. Finally, Apfel teaches that a
`
`user should, but does not have to, actually install the identified upgrade packages.
`
`Villasenor Supp. ¶ 28.
`
`In instances when it is determined that an upgrade should be installed, it is a
`
`precondition in Apfel that the upgrade be compatible with the configuration of the
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 9
`
`
`
`IPR2020-00023
`Patent 6,467,088
`destination computer, as Dr. Villasenor explains. Villasenor Supp. ¶¶ 27–29, citing
`
`Villasenor ¶¶ 84–85.
`
`D. Apfel Is Not Cumulative To
`The Apple IPR’s Primary Cited Reference
`Patent Owner contends that Apfel is cumulative to the Cole reference in the
`
`Apple IPR, which the Board did not institute. POR, 17–21. Patent Owner’s assertion
`
`is incorrect, as the Board already implicitly found in instituting this IPR. Decision,
`
`17–19.
`
`Apfel’s teaching of ensuring compatibility is different in an important way
`
`from the teaching in the primary reference cited in the Apple IPR. See POR, 10–11.
`
`There, the Board considered the reference’s teaching that the corresponding code
`
`updates were “potentially appropriate.” POR, 11 quoting Apple Inc. v. Uniloc 2017
`
`LLC, IPR2019-00056, Decision Denying Institution (Paper 7), 11–12. In reviewing
`
`Apple’s contention that this teaching in Cole taught or suggested the required “list
`
`of known acceptable configurations,” the Board wrote that “[t]he indecisive
`
`language ‘potentially’ is not the required decisive language of ‘known’—a
`
`difference that Petitioner does not explain persuasively, if at all.” Id.
`
`Thus, the Board in the Apple IPR made a distinction between known
`
`compatibility in the ’088 patent and potentially appropriate code updates in the Cole
`
`reference cited in the Apple petition, because the Board found that the citations in
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 10
`
`
`
`IPR2020-00023
`Patent 6,467,088
`Apple’s Petition left open the possibility that the Cole code updates were not
`
`appropriate, and therefore not “‘known’ to be acceptable configurations.” Id. No
`
`such uncertainty exists in Apfel. Villasenor Supp. ¶¶ 19–20.
`
`Apfel specifically describes that “different update packages may be provided
`
`for different version combinations” and that “each configuration of computer 20 may
`
`require a different upgrade package”:
`
`In the exemplary embodiment, the database server 80a
`uses the information received in the HTTP query at step
`415 to determine if an upgrade package is available, such
`as by a database lookup. Different update packages may
`be provided for different version combinations, different
`operating systems, and different languages. Thus, the
`database server 80a maintains a database of upgrade
`packages and corresponding configurations which
`should result in their download.
`
` …
`
`Not only are there certain upgrades that “should” be
`installed, but certain computer configurations, according
`to Apfel “require” certain upgrade packages. Apfel, 6:65-
`67. (“[E]ach configuration of computer 20 may require a
`different upgrade package and, therefore, a different
`URL.”)
`
`Petition, 41–42, quoting Apfel, 9:32–40, 6:65–67, citing Villasenor ¶¶ 83–84.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 11
`
`
`
`IPR2020-00023
`Patent 6,467,088
`Apfel also clearly teaches determining that certain upgrade packages may be
`
`inappropriate for a given configuration and “should not be downloaded,” such as
`
`where they are “somehow incompatible with computer”:
`
`The servers are responsible for assessing whether an
`upgrade is available and whether it should be downloaded
`based on the information sent by computer 20. For
`example, even if an upgrade is available, it should not be
`downloaded if the computer 20 already has the upgrade or
`if the upgrade is somehow incompatible with computer
`20.
`
`Petition, 45, quoting Apfel, 7:13–19, citing Villasenor ¶ 90.
`
`In Apfel, then, there is no uncertainty with regard to the compatibility of the
`
`upgrade. As Figures 4A and 4B and the above description from Apfel make clear,
`
`that compatibility was definitively established upon a “yes” output from box 427.
`
`Villasenor Supp. ¶ 21. The servers are responsible for determining compatibility,
`
`and even if an upgrade is available, the servers further determine whether it should
`
`be downloaded. Apfel makes clear that the servers will assess that it “should not”
`
`be downloaded it if is incompatible with the user’s computer. Thus, a POSITA
`
`reading Apfel would understand that once the option is presented to the user to
`
`perform the upgrade at step 427, at that point the responsible servers have already
`
`determined based on
`
`the
`
`information provided
`
`to
`
`them––including both
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 12
`
`
`
`IPR2020-00023
`Patent 6,467,088
`configuration information about the user’s computer and information regarding the
`
`availability of requested updates––that the upgrade should be performed. And, if the
`
`user approves the installation of the upgrade, it will be installed. The fact that the
`
`user “should”—but is not obligated to—approve this installation in no way alters the
`
`fact that the upgrade is already known to be compatible based on the above-described
`
`determination made by the servers. Id.
`
`In short, in Apfel there is no uncertainty regarding the compatibility of an
`
`upgrade that has been approved for and presented to the user. The “should result in
`
`their download” language pointed to by Patent Owner refers to an aspect of Apfel
`
`that occurs after the compatibility of an upgrade has already been decisively
`
`established, namely: a user should, but is not obligated to, proceed with the
`
`download of the known compatible upgrade. Villasenor Supp. ¶22.
`
`The POR states:
`
`Here, the Petition similarly fails to establish that the
`indecisive language in Apfel, which is explicitly directed
`to an expected “result” that only “should” occur, allegedly
`renders obvious the “required decisive language” recited
`as “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 . . . .
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 13
`
`
`
`IPR2020-00023
`Patent 6,467,088
`
`POR, 19 (emphasis in original); Villasenor Supp. ¶ 23.
`
`Patent Owner’s focus on whether a download actually occurs is misplaced.
`
`As noted earlier, Apfel decisively and unambiguously identifies (upon a “yes” output
`
`from box 427 in Figure 4A) a known compatible upgrade. Dr. Villasenor previously
`
`explained how this inherently teaches the comparing to a list of “known acceptable
`
`configurations” as required by the ’088 patent claims. Villasenor Supp. ¶ 24;
`
`Villasenor ¶ 85.
`
`In focusing on the language in Apfel stating that the download of the
`
`configuration “should” occur after its known compatibility is established by the
`
`servers, the POR offers no rebuttal to the unambiguous disclosure in Apfel that the
`
`configuration is known to be compatible by virtue of it being evaluated by the servers
`
`and recommended to the user. Villasenor Supp. ¶ 25.
`
`As Dr. Villasenor previously explained, Apfel inherently determines that
`
`compatibility, writing, for example, that Apfel “determines whether an appropriate
`
`upgrade is available.” Villasenor ¶ 83, emphasis added. See also id., quoting
`
`description from Apfel (9:30–42) describing box 427. Villasenor Supp. ¶ 26.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 14
`
`
`
`IPR2020-00023
`Patent 6,467,088
`VI. PATENT OWNER’S ASSERTIONS REGARDING APFEL’S
`COMBINATION WITH TODD AND LILLICH MISCONSTRUE THE
`REFERENCES, THE PETITION, AND THE ’088 PATENT’S OWN
`DESCRIPTION, ARE CONFUSING, AND DO NOT REBUT THE
`CLAIMS’ OBVIOUSNESS OVER APFEL, LILLICH, AND TODD
`Patent Owner Misconstrues Lillich’s
`A.
`Teachings And Their Combination With Apfel
`The POR criticizes the addition of Lillich’s “compatibility range” to the
`
`compatibility determination set forth in Apfel, stating:
`
`the “comparing” / “compare” limitations (recited in each
`challenged claim) at least require specific comparative
`consideration of (1) “the determined component” required
`to implement a requested reconfiguration of an electronic
`device; (2) “information specifying at least one additional
`component currently implemented in the electronic
`device;” and (3) the interoperability of these specific
`components with a list of configurations known to be either
`acceptable or unacceptable.
`
`POR, 22 (emphasis in original); Villasenor Supp. ¶ 30.
`
`First, Patent Owner is incorrect that the claims require consideration of “the
`
`interoperability of” these [“determined” and “additional”] components with a list
`
`of configurations known to be either acceptable or unacceptable.” There is no
`
`determination of interoperability with the list(s). Rather, component interoperability
`
`is determined using the list(s). The list(s) are used to determine interoperability of
`
`specific components with each other. So, in the example given in the specification,
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 15
`
`
`
`IPR2020-00023
`Patent 6,467,088
`the “list” sets forth that version 1.1 of component A and version 1.5 of component
`
`B “work well together or are otherwise compatible” and are therefore tagged as a
`
`“known good configuration”:
`
`A solid line between a given pair of components in the
`exemplary list 16 indicates that the pair of components
`corresponds to a known “good” configuration, i.e., the
`components work well
`together or are otherwise
`compatible. The pair including version 1.1 of component
`A and version 1.5 of component B is an example of a
`known good configuration.
`
`’088, 3:52–58 (emphasis added); see also FIG. 1 (selected portion):
`
`’088 patent, FIG. 1 (selected portion, annotation added). Villasenor Supp. ¶¶ 30–31.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 16
`
`
`
`
`
`IPR2020-00023
`Patent 6,467,088
`Just like the ’088, Lillich provides a list that provides information on
`
`components that are compatible. Such a list could readily be applied by the servers
`
`described in Apfel to determine which components (or ranges of components) are
`
`compatible with one another as part of these servers “determining compatibility,” as
`
`Dr. Villasenor previously explained. Villasenor Supp. ¶ 32, citing Villasenor ¶¶ 59–
`
`61.
`
`Second, Patent Owner argues that the verification technique in Lillich
`
`“applies to the clearly distinguishable context of a client program and a provider
`
`program that are both currently installed and executing locally in memory of the
`
`same computer system.” POR, 24. But, Apfel already teaches both “the determined
`
`component” and “the additional component” and determining their compatibility, as
`
`described above. See supra, Sections V.A-C. Villasenor Supp. ¶ 33.
`
`Lillich, on the other hand, is cited for its use of a “list” of compatible
`
`component version numbers. The step of determining compatible or incompatible
`
`version numbers by comparing them to a list is agnostic as to whether those
`
`components are currently installed or not (or, if installed, whether they are
`
`“executing locally” or not). Lillich’s “list” simply identifies components that are
`
`compatible. Similarly, the “list” in the ’088 patent, an example of which is shown
`
`above, places no requirements on the install status of the relevant components.
`
`Components are either known to be compatible, or they are not. If they are known
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 17
`
`
`
`IPR2020-00023
`Patent 6,467,088
`to be compatible, they are listed as such. They are compatible together whether they
`
`are currently installed, are not yet installed, or are a mix of the two (e.g., an already-
`
`installed component can be known to be compatible with a component that is not yet
`
`installed). The status of their installation is immaterial. Villasenor Supp. ¶34.
`
`Finally, Patent Owner’s conclusory statement at the end of its discussion of
`
`the Apfel/Lillich combination regarding “changing [the] fundamental principles of
`
`operation” of Apfel (POR, 24) offers no explanation of how any principle of
`
`operation in Apfel would be modified. As the Board has already noted, Lillich
`
`discloses a compatibility check using a list, and Apfel discloses servers that check
`
`for compatibility. Decision, 21. As shown in the Petition, Apfel either inherently
`
`discloses or implicitly suggests doing so using a list. And, as stated above, that
`
`“compatibility list” in Apfel, like the “known go
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
