`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`________________
`
`VISA INC. and VISA U.S.A. INC.
`APPLE INC.,
`
`Petitioners,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`
`Patent Owner
`
`________________
`
`Case IPR2018-013501
`
`U.S. Patent No. 8,856,539
`
`________________
`
`PATENT OWNER’S REPLY IN SUPPORT OF ITS MOTION TO AMEND
`
`
`
`
`1 Apple Inc., which filed a petition in IPR2019-00727, has been joined as a party
`to this proceeding.
`
`
`
`TABLE OF CONTENTS
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`Page
`
`I.
`II.
`
`III.
`
`MTA PRESENTS A REASONABLE NUMBER OF CLAIMS .................... 1
`PETITIONER’S ARGUMENTS FOR DENIAL OF MTA BASED
`ON DUTY OF CANDOR VIOLATIONS AND ESTOPPEL LACK
`MERIT ............................................................................................................. 2
`SUBSTITUTE CLAIMS HAVE WRITTEN SUPPORT ............................... 3
`A.
`Limitations 39[c], 48[a], 51[d], 52[pre] Have Written Support............ 3
`B.
`Limitations 46[b] and 52[c] Have Written Description Support .......... 8
`C.
`Limitations 40[b] and 46[d] Have Written Description Support .......... 9
`D.
`Limitation 51[b] Has Written Description Support ............................ 10
`IV. SUBSTITUTE CLAIMS ARE PATENTABLE OVER PRIOR ART ......... 10
`A.
`Brener Teaches Away From Limitations 39[c], 48[a], 51[d],
`52[pre] and Petitioner Further Fails to Explain Why A POSITA
`Would Be Motivated To Combine Brener with Desai ........................ 10
`Desai and Pare Fail to Teach Limitations 39[e] and 47[b] ................. 16
`Brener and Schneier Fail to Disclose Limitations 40[b],
`46[c][d] ................................................................................................ 19
`Brener Fails to Disclose “Public ID Code” (Limitation 52[f][g]) ...... 21
`D.
`THE SUBSTITUTE CLAIMS ARE PATENTABLE UNDER § 101 ......... 23
`V.
`VI. THE SUBSTITUTE CLAIMS SATISFY 35 U.S.C. § 112 .......................... 24
`VII. CONCLUSION .............................................................................................. 25
`
`
`
`B.
`C.
`
`
`
`
`
`i
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`TABLE OF AUTHORITIES
`
`CASES
`
`Page
`
`Becton, Dickinson & Co. v. Tyco Healthcare Grp., LP,
` 616 F.3d 1249 (Fed. Cir. 2010) .................................................................... 21
`
`Continental Circuits LLC v. Intel Corp. et al.,
` No. 2018-1076 ............................................................................................ 6, 7
`
`In re Robertson,
` 169 F.3d 743 (Fed. Cir. 1999) ...................................................................... 21
`
`SDI Technologies, Inc. v. Bose Corp.,
` IPR2014-00346 (June 11, 2015) ..................................................................... 2
`
`Universal Secure Registry, LLC v. Apple, Inc.,
`1:17-cv-00585-JFB-SRF (D. Del. Sep. 18, 2018) .........................................23
`
`RULES AND REGULATIONS
`
`37 C.F.R. § 42.121(a)(3) ............................................................................................ 1
`
`37 C.F.R. § 42.73(d)(3)(i) .......................................................................................... 1
`
`
`
`
`
`
`ii
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`Ex. 2001
`
`Ex. 2002
`Ex. 2003
`Ex. 2004
`
`Ex. 2005
`
`Ex. 2006
`
`Ex. 2007
`
`Ex. 2008
`Ex. 2009
`Ex. 2010
`
`Ex. 2011
`
`Ex. 2012
`
`PATENT OWNER’S LIST OF EXHIBITS
`
`Declaration of Dr. Markus Jakobsson in Support of
`Patent Owner’s Preliminary Response.
`Curriculum Vitae of Dr. Markus Jakobsson.
`Terminal Disclaimer Dated August 17, 2018.
`Declaration of Dr. Markus Jakobsson in Support of
`Patent Owner’s Response.
`Transcript of Dr. J. Douglas Tygar Deposition Dated
`April 19, 2019.
`N. Asokan, et. al, The State of the Art in Electronic
`Payment Systems, IEEE Computer, Vol. 30, No. 9, pp.
`28-35 (IEEE Computer Society Press, Sept. 1997).
`M. Baddeley, Using E-Cash in the New Economy: An
`Economic Analysis of Micropayment Systems, J.
`Electronic Commerce Research, Vol. 5, No. 4, pp. 239-
`253 (Nov. 2004).
`U.S. Application No. 11/768,729.
`U.S. Application No. 09/710,703.
`Declaration of Dr. Markus Jakobsson in Support of
`Motion to Amend.
`Declaration of Dr. Markus Jakobsson in Support of
`Patent Owner’s Reply to Opposition of Conditional
`Motion to Amend
`U.S. District Court for Delaware Report and
`Recommendation.
`
`iii
`
`
`
`
`
`
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Universal Secure Registry LLC (“Patent Owner”) submits this Reply in
`
`support of its Conditional Motion to Amend, Paper 13 (“MTA”), and in response to
`
`Petitioner’s Opposition to the MTA, Paper 17 (“Opp.”).
`
`I. MTA PRESENTS A REASONABLE NUMBER OF CLAIMS
`
`Title 35 U.S.C. § 316(d) allows PO to file one motion to amend having a
`
`reasonable number of substitute claims per instituted IPR proceeding. Here, PO’s
`
`MTA submits one substitute claim for each of challenged claims 1-4, 9, 16, 21-25,
`
`31, 37, and 38, which is presumptively a reasonable number of substitute claims. See
`
`37 C.F.R. § 42.121(a)(3).
`
`Petitioner (“VISA”) complains that if other substitute claims for the ’539
`
`patent are granted in another currently pending IPR proceeding (IPR2018-00812),
`
`Petitioner will have had no opportunity to be heard. See Opp. at 2. VISA has no right
`
`to be heard in a proceeding before this Board for which it is not a petitioner.
`
`Petitioner also wrongly implies that the present MTA is defective because it does
`
`not allegedly “explain whether the requested amendments are patentably distinct
`
`from those sought in the Apple CMTA.” See id. The Rules preclude a patent owner
`
`from obtaining in any patent a claim that is not patentably distinct from a “finally
`
`refused or canceled claim.” 37 C.F.R. § 42.73(d)(3)(i). But a claim is not finally
`
`refused and estoppel does not apply according to § 42.73(d)(3)(i) until the claims at
`
`
`
`1
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`issue have been canceled. SDI Technologies, Inc. v. Bose Corp., IPR2014-00346,
`
`Paper 32 at 7-10 (June 11, 2015). Thus, even if the Board issued a final written
`
`decision in IPR2018-00812 that the claims of the ’539 patent challenged there are
`
`unpatentable, such a decision alone would not trigger § 42.73(d)(3)(i); instead,
`
`Patent Owner’s appeal rights would need to be exhausted and the claims canceled.
`
`II.
`
`PETITIONER’S ARGUMENTS FOR DENIAL OF MTA BASED ON
`DUTY OF CANDOR VIOLATIONS AND ESTOPPEL LACK MERIT
`
`Petitioner argues that (1) the MTA should be denied because PO allegedly
`
`violated its duty of candor with the Board, and (2) PO should be estopped from
`
`amending its claims to include what Petitioner believes is previously disclaimed
`
`subject matter. See Opp. at 2-3. These contentions are premised on the mistaken
`
`belief that once PO has disclaimed claims of a patent having financial terms, PO is
`
`barred from submitting substitute claims during in IPR for that patent that include
`
`financial terms of an entirely different scope. Not surprisingly, Petitioner cites no
`
`authority in support of its misguided positions.
`
`Specifically, Petitioner objects to substitute claim 52 because it recites “the
`
`information including account identifying information that includes a public ID
`
`code that identifies a financial account number…provide the account identifying
`
`information to a third party that uses the public ID code to obtain the financial
`
`account number.” MTA at A5. However, claim 52’s scope is entirely different than
`
`
`
`2
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`disclaimed claims 5-8, 16-19, and 26-30 of the ’539 patent, which generally include
`
`limitations for credit or bank card transactions. Indeed, none of the disclaimed claims
`
`recite a “public ID code that identifies a financial account number” or “a third party
`
`that uses the public ID code to obtain the financial account number.”
`
`Petitioner relies on even shakier footing when it argues that PO is barred from
`
`submitting claim 52 in this proceeding related to the ’539 patent because PO
`
`disclaimed a claim that recited “multidigit public ID code” in a different patent (U.S.
`
`patent no. 9,530,137) that was subject to different CBM and IPR proceedings. Again,
`
`Petitioner cites no authority in support of its meritless positions.
`
`PO has also not taken any “position” in the past that now contradicts its stance
`
`that the present substitute claims are patentable in view of the prior art. For instance,
`
`PO has never stated that the subject matter of disclaimed claims 5-8, 16-19, and 26-
`
`30 were obvious or unpatentable for any reason. See, e.g., Paper 12 (Patent Owner’s
`
`Response) at 1 n.1. Patent Owner is also not estopped from submitting the pending
`
`substitute claims for at least the same reasons.
`
`III. SUBSTITUTE CLAIMS HAVE WRITTEN SUPPORT
`
`A. Limitations 39[c], 48[a], 51[d], 52[pre] Have Written Support
`
`Petitioner falsely alleges that the ’539 patent’s specification “do[es] not
`
`describe…a lack of communications between the USR system and the entity while
`
`
`
`3
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`receiving the transaction request or enabling the transaction.” Opp. at 4. But the
`
`specification clearly describes an embodiment where there are no communications
`
`between the secure registry and the entity during the transaction process. For
`
`example, application no. 11/768,729 (“’729 Application”) describes an embodiment
`
`“for facilitating purchase of goods or services” in connection with FIG. 8 where “the
`
`user initiates a purchase (800), enters a secret code in the electronic ID device (802)
`
`and presents the resultant code to the merchant.” ’729 Application at 17:27-30, FIG.
`
`8. From this point on, the merchant takes over the transaction. Specifically, the
`
`merchant generates its own message that includes a number of different things: a
`
`store number that identifies the merchant, an amount of the purchase, and the code.
`
`Id. at 17:30-18:1. A POSITA would understand that the merchant’s generation of
`
`this new message, which includes additional substantive information provided by
`
`the merchant and not the entity (e.g., store number, sale amount, etc.), and
`
`subsequent transmission to the secure registry means that the merchant—not the
`
`entity—is communicating with the secure registry.2 Furthermore, assuming
`
`arguendo the entity provides the time-varying code to the merchant and that doing
`
`
`2 While not required by the claims, this is true even if it’s assumed that the entity
`
`provides the merchant the time-varying code.
`
`
`
`4
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`so constitutes communication “between” the secure registry and the entity (e.g.,
`
`claim 52[pre] reciting “between”), this would not negate written description support
`
`for limitations 39[c], 48[a] that limit one-way communication from the secure
`
`registry with the entity. See claims 39, 48 (“without the secure registry system
`
`communicating with the entity”). Ex. 2011, Jakobsson Decl. at ¶29.
`
`Petitioner’s citation to the specification’s discussion of the “training process”
`
`(Opp. at 4) is also inapposite because communications between the entity and secure
`
`registry during the training process take place before a transaction is initiated and a
`
`provider makes a request to access secure data. See, e.g., ’729 Application at 14:1-
`
`16:27, FIGS. 5-6. And here the claims expressly specify that “the transaction request
`
`[is] received at the secure registry system without the secure registry system
`
`communicating with the entity.” MTA at B1, B4 (39[c], 48[a]); see also id. at B5
`
`(52[pre]). Claim 51 even expressly distinguishes the “training process”—where the
`
`secure registry and entity do communicate—from the “transaction process” where
`
`they do not. Ex. 2011, Jakobsson Decl. at ¶30.
`
`Petitioner next argues that these claim limitations are allegedly unsupported
`
`because “[t]he user’s device must communicate with the USR because the biometric
`
`verification information is stored in the USR database.” Opp. at 5. As an initial
`
`matter, claim 51 does not recite biometric verification of the entity, and thus
`
`
`
`5
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Petitioner’s argument here must be rejected as to Claim 51. As to claims 39, 48, and
`
`52, Petitioner incorrectly presupposes that the entity must communicate with the
`
`USR to have the entity’s identity verified using the entity’s biometric. This is not
`
`true. First, Petitioner assumes that the biometric verification information must be
`
`“stored in the USR database.” Opp. at 5. While, the specification does describe how
`
`biometric information may be stored at the USR database (see, e.g., Ex. 2008, ’729
`
`Application at 12:20-28), the broadest reasonable interpretation and plain language
`
`of the claims do not require such information to be stored at the USR database. See
`
`Continental Circuits LLC v. Intel Corp. et al., No. 2018-1076, slip op. at 11-13
`
`(Absent “a clear and unmistakable disclaimer” or “expressions of manifest exclusion
`
`or restriction, representing a clear disavowal of claim scope,” an embodiment, even
`
`if preferred, should not limit claim scope). Ex. 2011, Jakobsson Decl. at ¶31.
`
`Second, even if biometric verification information were stored at the secure
`
`registry, Petitioner improperly assumes that entity verification using such
`
`information stored at the secure registry necessarily requires communication
`
`between the entity and the secure registry. Again, the claims should not be construed
`
`so narrowly. The broadest reasonable interpretation of the claims in light of the
`
`specification affords that such verification of the entity’s identity using a biometric
`
`could occur without the entity communicating with the secure registry. See
`
`
`
`6
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Continental Circuits LLC at 11-13. As just one non-limiting example, a POSITA
`
`would understand that the provider (e.g., a merchant at a point of use) may generate
`
`and/or supply the entity’s biometric information that may be communicated to the
`
`secure registry. See, e.g., Ex. 2008, ’729 Application at 5:16-17 (“The identity of the
`
`user possessing the identifying device may be verified at the point of use.”). As
`
`another non-limiting example, a POSITA would understand that verifying the user
`
`at the point of use may allow such biometric information to be communicated as part
`
`of the transaction request that includes other data generated by the provider, such as
`
`a store number and transaction amount. As described above, since such a message
`
`would be generated at the provider, a POSITA would understand that the provider
`
`is communicating with the secure registry and not the entity. As to the latter point,
`
`claims 39[c], 48[a] also specify that the secure registry does not communicate with
`
`the entity, which does not preclude communications from the entity to the secure
`
`registry. Ex. 2011, Jakobsson Decl. at ¶32.
`
`Third, as discussed below, the claims do not imply any timing restrictions as
`
`to when the entity’s biometric is verified. See infra Section III.B. Thus, even if the
`
`claims were read so narrowly as to require that the entity must communicate with
`
`the secure registry to verify the entity’s identity, this verification process could take
`
`place before the transaction request is received at the secure registry. See Continental
`
`
`
`7
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Circuits LLC at 11-13. Indeed, in some cases a POSITA may desire to verify the
`
`identity of the entity first before transaction request generation and receipt at the
`
`secure registry. Ex. 2011, Jakobsson Decl. at ¶33.
`
`B.
`
`Limitations 46[b] and 52[c] Have Written Description Support
`
`Petitioner argues that limitations 46[b] and 52[c], which recite the entity
`
`“having been verified” or “having had its identity verified,” lack written description
`
`support because “[n]either the cited priority documents nor the ’539 patent
`
`contemplate…using a biometric prior to the USR system receiving the transaction
`
`request.” Opp. at 5-6 (emphasis in original). Petitioner’s faulty analysis is premised
`
`on the mistaken belief that the claim language “having been” and “having had”
`
`necessarily indicate timing of biometric verification relative to other steps recited in
`
`the claims, and in particular, require that biometric verification of the user take place
`
`before the transaction request is received. A POSITA reading the language of the
`
`claims as a whole in light of the specification would understand that no timing
`
`requirement—before or after—is implied for biometric verification of the user
`
`relative to other steps in the claim, including receipt of the transaction request at the
`
`secure registry. A POSITA would further understand that these claims have ample
`
`written description support and that the inventor was in possession of the claimed
`
`invention. See, e.g., Ex. 2008, ’729 Application at 5:11-21, 12:20-28; see also MTA
`
`
`
`8
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`at 7-8; Ex. 2011, Jakobsson Decl. at ¶34.
`
`C. Limitations 40[b] and 46[d] Have Written Description Support
`
`The ’729 Application provides unequivocal written description support for
`
`“map the time-varying multicharacter code to the identity of the entity using the
`
`time-varying multicharacter code and the time value.” The specification expressly
`
`states, “Where the number from the electronic ID device is a time varying number,
`
`the merchant may also need to input the time the number was received.
`
`Alternatively, the electronic ID device may encode or encrypt the time with the
`
`number, the USR software being able to extract time when receiving the number
`
`from the merchant.” Ex. 2008 at 19:27-31. The specification also states, “The
`
`merchant transmits to the credit card company (1) the code from the electronic ID
`
`device, (2) the store number, (3) the amount of the purchase (704), and the time of
`
`receipt of the code.” Id. at 17:7-11. A POSITA would unquestionably understand
`
`that the purpose of this timing information is to allow the secure registry to make
`
`proper use of the received “time-varying” number/code, which is time-dependent.
`
`Thus, to be able to map the time-varying code received, the secure registry and the
`
`ID device generating the time-varying code need timing synchronization, and one
`
`way to accomplish that is to receive the timing information along with the time-
`
`varying code. This is further evidenced by the specification’s express disclosure that
`
`
`
`9
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`“The USR software 18 determines if the code…was valid at the time offered.” Ex.
`
`2008 at 17:11-12. This means that the secure registry uses the timing information
`
`received to determine whether the time-varying code’s value at that earlier time
`
`matches and is valid. Thus, the specification supports limitations 40[b], 46[d]. Ex.
`
`2011, Jakobsson Decl. at ¶35.
`
`D. Limitation 51[b] Has Written Description Support
`
`Although the specification expressly describes an entity storing secure data at
`
`a secure registry during a “training process” (see Ex. 2008 at 14:1-15:9, FIG. 5),
`
`Petitioner incredulously argues that limitation 51[b] allegedly lacks support because
`
`“[t]he specifications do not describe a training process involving multiple entities,
`
`rather they merely teach individual training by an individual entity.” Opp. at 7-8.
`
`The disputed claim language recites the training of plural “entities” consistent with
`
`the preceding claim language: “entities with secure data stored in the secure registry
`
`system.” Having admitted ample support for a “training process” for a single entity,
`
`Petitioner’s argument of no written support lacks any reasonable basis. Ex. 2011,
`
`Jakobsson Decl. at ¶36.
`
`IV. SUBSTITUTE CLAIMS ARE PATENTABLE OVER PRIOR ART
`
`A. Brener Teaches Away From Limitations 39[c], 48[a], 51[d],
`52[pre] and Petitioner Further Fails to Explain Why A POSITA
`Would Be Motivated To Combine Brener with Desai
`
`
`
`10
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Petitioner argues that limitations 39[c], 48[a], 51[d], and 52[pre] are obvious
`
`because “Brener discloses sending the transaction request information to the secure
`
`computer by the vendor, rather than the customer.” Opp. at 9 (citing Ex. 1005, Brener
`
`at 2:19-3:11). Petitioner, however, overlooks a fundamental aspect of Brener’s
`
`system that inherently teaches away from these claim limitations: the customer
`
`computer 100 must first login and connect to the secure provider 110 (alleged
`
`secure registry) to anonymously access the vendor web sites 140 and initiate
`
`purchase transactions. Ex. 2011, Jakobsson Decl. at ¶37.
`
`The crux of Brener’s invention is to provide e-commerce customers
`
`“complete anonymity” while carrying out purchase transactions with online vendors.
`
`See, e.g., Ex. 1005, Brener at 2:12-15 (“what is needed is a secure Internet system
`
`that eliminates the need to provide vendors with both customers’ actual identities
`
`and shipping addresses, and accordingly provides customers with complete
`
`anonymity”), 2:15-17 (“It would also be desirable to provide such an e-commerce
`
`system whereby the customer can remain anonymous but still visit web sites as a
`
`character or persona such that he or she is recognized upon return to the vendor web
`
`site.”), 8:3-4, 14:23-24 (“A key aspect of the present invention is the secure and
`
`anonymous shipping protocol used.”), 21:18-20, claims 1 and 9. Ex. 2011,
`
`Jakobsson Decl. at ¶38.
`
`
`
`11
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`The cornerstone of this customer anonymity is Brener’s secure provider
`
`110 (alleged secure registry). Brener explicitly teaches that its “invention desirably
`
`allows a customer to shop on-line at vendor web sites in an anonymous fashion,”
`
`and that “[t]o do so, a customer uses his customer computer 100…to connect the
`
`secure provider computer 110 and login with a certificate based ID and
`
`password.” Ex. 1005, Brener at 8:3-6. Brener further explains that “[o]nce the
`
`customer computer 100 is connected to the secure provider computer 110, a secure
`
`connection pipeline 120 is provided between the customer computer 100 and
`
`the secure provider computer 110 in order to prevent transmissions between the
`
`customer computer 100 and the secure provider computer 110 from being
`
`monitored.” Id. at 8:21-25. The secure provider 110 even sends the customer
`
`computer virtual private network (“VPN”) software “that enables the customer
`
`computer 100 to connect directly to the secure provider computer 100, along a
`
`known, fixed node-to-node route” in order to “protect the privacy of the user.” Id. at
`
`8:25-9:3. The VPN allows the customer computer 100 to hide its address (e.g., IP
`
`address) from the vendor computers 140 and allows “the customer computer 100
`
`[to] anonymously connect to the web sites of various vendor computers 140
`
`using the Internet via the secure provider’s proxy servers.” Id. at 9:3-14.
`
`Annotated FIG. 1 of Brener below illustrates the secure connection pipeline 120.
`
`
`
`12
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`Notably, each and every customer computer 100 is shown to be connected to
`
`(i.e., in communication with) the secure provider 110 and uses the secure
`
`connection pipeline 120 of the secure provider 110 to access the vendor
`
`computers 140 and carry out purchase transactions. Ex. 2011, Jakobsson Decl.
`
`at ¶39.
`
`
`
`The customer computer’s 100 connection to the secure provider 110 is vital
`
`to Brener’s e-commerce system not only because of the anonymity provided by the
`
`secure provider’s proxy servers, but also because the connection is necessary to
`
`establish and use a customer object (e.g., GOLFO) that identifies the customer
`
`computer 100 to vendors 140 without revealing the customer computer’s 100
`
`sensitive information (e.g., real name, real address). See, e.g., Ex. 1005, Brener at
`
`
`
`13
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`10:25-27, 11:11-15, 11:23-12:2, 12:3-6, 12:7-20; Ex. 2011, Jakobsson Decl. at ¶40.
`
`Consequently, Brener’s system requires that the customer computer 100 and
`
`the secure provider 110 establish and maintain communications with each other in
`
`order for the customer 100 to initiate and conduct purchase transactions with vendors
`
`140. As such, Brener teaches away from the amended claims, which require that “the
`
`transaction request is received at the secure registry system without the secure
`
`registry system communicating with the entity on whose behalf a transaction is to
`
`be performed” (38[c], 48[a]). See also Claims 51[d], 52[pre]. Brener never
`
`discloses—nor does Petitioner argue—that the customer computer 100 disconnects
`
`from Brener’s secure provider 110 at any point while the purchase transaction is
`
`carried out by Brener’s vendor 140, bank 150, and secure provider 110. Indeed,
`
`doing so would be completely counter to Brener’s teachings of customer anonymity
`
`provided to the customer by the secure provider’s proxy servers and VPN (see Ex.
`
`1005, Brener at 8:21-9:14, 12:3-6) and use of the customer object. See, e.g., id. at
`
`11:23-25 (“Once the customer joins the web site of the secure provider computer
`
`110, the customer is provided with a customer object identifier.”); see also id. at
`
`10:25-27, 11:11-15, 11:25-12:20. Accordingly, Petitioner’s argument that Brener
`
`teaches limitations 38[c], 48[a], 51[d], 52[pre] because “Brener discloses sending
`
`the transaction request information to the secure computer by the vendor, rather than
`
`
`
`14
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`the customer” is meritless and irrelevant since Brener’s customer computer 100 and
`
`secure provider 110 are continuously in communication with each other during the
`
`transaction process. Ex. 2011, Jakobsson Decl. at ¶41.
`
`Petitioner also argues that Desai purportedly describes—like Brener—that a
`
`transaction request is sent from the merchant to the secure registry. See Opp. at 9-
`
`10. Even if this is true, Petitioner provides absolutely no explanation of how Brener
`
`would be modified so that its customer computer 100 did not remain
`
`communicatively connected to the secure provider 110 during the transaction
`
`process, or why a POSITA would be motivated to change such a fundamental aspect
`
`of Brener’s transaction scheme. See Opp. at 16; Ex. 2011, Jakobsson Decl. at ¶42.
`
`Indeed, Petitioner and its expert have completely failed to address the
`
`ramifications of this core feature of Brener when considering motivation to combine
`
`for these new claim limitations because Petitioner expressly states that “the
`
`additional limitations presented in substitute claim 51 do not alter the reasons
`
`previously provided by Dr. Tygar for combining the teachings of Brener, Desai,
`
`and Weiss.” Opp. at 16 (citing Dr. Tygar’s first declaration (Ex. 1002 at ¶¶57-69)
`
`
`
`15
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`for why a POSITA would combine the same references).3 However, such a change
`
`to Brener—disconnection of the customer computer 100 from the secure provider
`
`110 while initiating and conducting a purchase transaction—would undeniably
`
`require consideration because a POSITA would understand that such changes alter
`
`a fundamental principle of operation of Brener and also frustrate Brener’s purpose
`
`of providing the customer with “complete anonymity.” Ex. 2011, Jakobsson Decl.
`
`at ¶43.
`
`B. Desai and Pare Fail to Teach Limitations 39[e] and 47[b]
`
`Petitioner argues that limitations 39[e] and 47[b] are satisfied by Desai
`
`because allegedly “[e]ach user [in Desai] is validated using…cookies or other
`
`electronic data transfer protocol.” Opp. at 10 (citing Ex. 1007, Desai at 18:63-64).
`
`Tellingly, however, Petitioner does not explain the context of the “cookie technology
`
`and other electronic data transfer protocol” described in Desai at 18:63-64. Opp. at
`
`10. The two lines of Desai referenced to by Petitioner relate to an “AUTH_USER”
`
`field that is part of a “ZKEY” software system. Ex. 1007, Desai at 18:1-11, 18:53-
`
`64. The ZKEY software allows a registered user to, among other things, enter/edit
`
`
`3 Petitioner provides no motivation to combine (even by incorporation by reference)
`
`for claim limitations 39[c], 48[a], and 52[pre], addressing here only limitation 51[d].
`
`
`
`16
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`their own personal information (Id. at FIG. 25, items 816-834) and create/edit
`
`“views” for access to information that the user desires (Id. at FIG. 25, items 836-
`
`848). Notably, nowhere in Desai’s discussion about the ZKEY system does Desai
`
`explain how the AUTH_USER field is used or how “cookies” are used to verify
`
`users of the ZKEY system. In particular, Desai especially does not disclose that
`
`merchants “who access information (rather than stor[e] it)” are “validated using, for
`
`example, cookies or other electronic data transfer protocols” (Opp. at 10). See, e.g.,
`
`Ex. 1007, Desai at 18:1-31:23, FIGS. 16-51; Ex. 2011, Jakobsson Decl. at ¶44.
`
`Instead, Desai describes in detail how third-party merchants access a
`
`registered user’s data from Desai’s information exchange system. See Ex. 1007,
`
`Desai at 14:56-15:12. If a merchant wants to access a user’s data element, it first
`
`locates the desired data element on the information exchange database using the data
`
`element’s unique universal ID and its own identifier. Id. at 14:56-67. Of course, in
`
`the event no matching records are found then access cannot be given. Id. at 15:1-2.
`
`If a matching record is found then the merchant uses its private key to decrypt a
`
`secret key that has been encrypted with the merchant’s public key. Id. at 15:2-12.
`
`Once the secret key has been decrypted, the merchant can use the secret key to
`
`decrypt and access the encrypted data element. Id. Nowhere in this process does
`
`Desai describe the merchant having to validate itself to the information exchange
`
`
`
`17
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`database, much less doing so using “cookies.” Instead, a POSITA would understand
`
`that the system would not need to validate the merchant’s identity prior to executing
`
`a restriction mechanism for the merchant because the public key cryptographic
`
`scheme described by Desai ensures that all sensitive user data is cipher-text and
`
`cannot be accessed unless the merchant attempting to access the data possesses the
`
`correct private key. In effect, possession of the correct private key—which the
`
`merchant would never share with other parties—confirms that the correct party is
`
`accessing the data and there is no need for a extraneous validation step. Ex. 2011,
`
`Jakobsson Decl. at ¶45.
`
`Petitioner also argues that Pare discloses these limitations. Opp. at 10. Even
`
`if Pare’s cross-checking the merchant code in the VAD record constituted provider
`
`validation, Petitioner fails to argue in its Opposition that a POSITA would be
`
`motivated to modify the other prior art references with this alleged teaching in Pare
`
`to arrive at limitations 39[e] and 47[b]. Sections IV.J and IV.K of the Opposition are
`
`proffered by Petitioner in an attempt to show that a POSITA would combine the
`
`prior art references to arrive at the various claim limitations of claims 39, 41-45
`
`(Section IV.J) and claims 39, 40, 46-50 (Section IV.K). However, nowhere in these
`
`sections (or any other) does Petitioner explain how or why a POSITA would modify
`
`Brener, Desai, Weiss, or Schneier with the purported teachings of Pare (e.g., cross-
`
`
`
`18
`
`
`
`Case No. IPR2018-01350
`U.S. Patent No. 8,856,539
`
`
`
`checking the merchant code in the VAD record) to arrive specifically at these claim
`
`limitations.4 Accordingly, Petitioner fails to show that these limitations are obvious
`
`over Pare. Ex. 2011, Jakobsson Decl. at ¶46.
`
`C. Brener and Schneier Fail to Disclose Limitations 40[b], 46[c][d]
`
`Limitations 40[b], 46[c][d] describe a transaction request that includes a time
`
`value representative of when the time-varying code was generated, extracting the
`
`time value from the transactio