throbber
Paper No. 20
`
`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

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