Filed on behalf of: Visa Inc. and Visa USA Inc.
`By: Matthew A. Argenti
`
`Michael T. Rosato
`WILSON SONSINI GOODRICH & ROSATI
`650 Page Mill Road
`Palo Alto, CA 94304-1050
`
`
`
`
`
`
`
`
`
`Paper No. ____
`Filed: August 12, 2019
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________________________
`
`VISA INC. and VISA U.S.A. INC.,
`Petitioners,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`Patent Owner.
`_____________________________
`
`Case No. IPR2018-01350
`Patent No. 8,856,539
`_____________________________
`
`
`PETITIONERS’ REPLY TO PATENT OWNER RESPONSE
`
`

`

`TABLE OF CONTENTS
`
`
`
`I. 
`
`II. 
`
`C. 
`D. 
`
`Page
`CLAIM CONSTRUCTION ..................................................................................... 1 
`A. 
`“Entity” Is Undisputed .......................................................................... 1 
`B. 
`The Claims Do Not Require the Access Restrictions Be “Based
`at Least in Part on the Indication of the Provider and the Time-
`Varying Multicharacter Code of the Transaction Request” .................. 2 
`“Third Party” Need Not Be Construed .................................................. 4 
`“The Provider Requesting the Transaction” Is Not the Same as
`the Provider Sending the Transaction Request ..................................... 4 
`THE ’539 CLAIMS ARE OBVIOUS IN VIEW OF THE PRIOR ART ............................. 6 
`A. 
`Brener’s Shipping Carrier and Bank Both Satisfy Limitation 1.6 ........ 6 
`B. 
`A Person of Ordinary Skill Would Have Had Reason to
`Combine Brener and Weiss, Despite PO’s Mischaracterization
`of Brener’s “Private Key Authorization Code” .................................. 12 
`PO Mischaracterizes the Proposed Combination of Brener and
`Desai to Argue that Such Combination Would “Teach Away or
`Contradict the Invention as Claimed” ................................................. 16 
`PO Improperly Selects and Attacks Specific Implementations of
`Desai Never Proposed in the Petitioner’s Combination. ..................... 19 
`PO’s Arguments Regarding Claims 3 and 24 Mischaracterize
`Brener’s Disclosure of RSA Public Key Encryption. ......................... 21 
`PO FAILS TO ESTABLISH OBJECTIVE INDICIA OF NONOBVIOUSNESS ................. 21 
`A. 
`PO Fails to Demonstrate Long-Felt Need or Failure of Others .......... 21 
`B. 
`PO Fails to Demonstrate Commercial Success ................................... 23 
`IV.  CONCLUSION ................................................................................................... 25 
`V. 
`CERTIFICATE OF COMPLIANCE ........................................................................ 27 
`VI.  APPENDIX – LIST OF EXHIBITS ........................................................................ 28 
`
`C. 
`
`D. 
`
`E. 
`
`III. 
`
`-i-
`
`

`

`
`
`Visa Inc. and Visa U.S.A. Inc., (together, “Petitioner”) request a final
`
`written decision finding claims 1-4, 9, 16, 21-25, 31, 37, and 38 of U.S. Patent No.
`
`8,856,539 to Weiss et al. (“the ’539 patent,” Ex-1001) unpatentable as set forth in
`
`the petition (“Pet.,” Paper 2).1 Petitioners’ rebuttal remarks to the Patent Owner
`
`(“PO”) Response (“Resp.,” Paper 12) are provided herein.
`
`PO fails to show how any claim limitation is missing from the proposed
`
`combination of references. The only element PO alleges the prior art lacks
`
`(limitation 1.6) is taught by Brener in multiple ways. Moreover, PO’s attempts to
`
`rebut Petitioner’s rationale to combine the references repeatedly mischaracterize
`
`the proposed combination. In arguing that the combination would not be
`
`technically feasible, PO refashions a ground of its own design so it has a straw man
`
`to knock down, while completely disregarding the challenge actually presented in
`
`the petition. PO also fails to demonstrate any objective indicia of nonobviousness,
`
`as its arguments on that point lack any connection to the claimed invention.
`
`I.
`
`CLAIM CONSTRUCTION
`A.
`“Entity” Is Undisputed
`PO does not dispute Petitioner’s construction of the term “entity” as
`
`
`
`1 Petitioner also challenged claims 5-8, 17-20, and 26-30. PO then disclaimed
`
`those claims to avoid institution in CBM2018-00023. Ex-2003.
`
`-1-
`
`

`

`
`
`“purchasing party to a transaction who has data stored in the secure registry,” nor
`
`does PO offer its own construction for the term. See Resp. 13.
`
`B.
`
`The Claims Do Not Require the Access Restrictions Be “Based at
`Least in Part on the Indication of the Provider and the Time-
`Varying Multicharacter Code of the Transaction Request”
`In view of the various embodiments disclosed by the ’539 patent, as well as
`
`the plain language of the claim itself, the clause “based at least in part on an
`
`indication of the provider and the time-varying multicharacter code of the
`
`transaction request” should be read to modify the element that immediately
`
`precedes it: “completing the transaction.” See Pet., 15-17. PO argues that the
`
`access restrictions themselves must be based on the indication of the provider and
`
`the time-varying multicharacter code. Resp., 13-16. Although the challenged
`
`claims are unpatentable under either interpretation of this limitation, construction
`
`of this term determines whether Brener alone teaches this limitation or whether the
`
`combination of Brener and Desai is necessary. Regardless, under either
`
`construction, the prior art teaches this limitation.
`
`Although, as acknowledged by the Board, the specification describes
`
`“different levels of security to attach to different types of information stored,” and
`
`“provides that the user ‘specif[ies] the type of access restrictions and/or whom
`
`should be allowed to access the advanced personal data,” the specification does not
`
`require such granular access restrictions. Institution Decision (“D.I.”, Paper 7), 8.
`
`-2-
`
`

`

`
`
`For example, “[a]s shown in FIG. 6, the database will generally allow anyone to
`
`access basic personal data on anyone without performing any authorization check
`
`(600).” Ex-1001, 10:35-39.
`
`Moreover, the specification provides examples where application of access
`
`restrictions does not involve consideration of the requestor’s identity but rather is
`
`based solely on whether the user’s electronic ID code is valid. See Pet., 16-17
`
`(citing Ex-1001 12:19-31, 11:49-65, 12:55-13:8, 13:35-57); Ex-1002, ¶53. These
`
`embodiments equally map to the subject claim language, giving meaning to the
`
`term “access restrictions for the provider,” because the system provides role-based
`
`access restrictions allowing a bank access to the user’s credit card number but
`
`protecting the information from access by a vendor. See, e.g., Ex-1001 12:19-31;
`
`12:55-13:8.
`
`PO’s rebuttal arguments should be rejected. PO’s expert declined to offer an
`
`opinion as to whether the ’539 patent describes access to information based solely
`
`on validity of the electronic ID code. Ex-1015, 50:1-11, 52:22-53:5. In addition,
`
`while his declaration testimony cites to the inclusion of a “store number” in the
`
`transaction request as evidence that access must be based on vendor identity, he
`
`later admitted that “there might be multiple purposes” for including the store
`
`number and at least one embodiment of the ’539 patent includes a store number
`
`where no information is communicated from the secure registry to the merchant,
`
`-3-
`
`

`

`
`
`undermining PO’s argument that the store number must be included to determine
`
`access restrictions. Ex-2004, ¶42; Ex-1015, 53:7-22, 59:17-60:2, 65:13-18; Ex-
`
`1001, 11:46-12:18, Fig. 7.
`
`C.
`“Third Party” Need Not Be Construed
`PO does not identify how its proposed construction would affect an issue in
`
`this proceeding. PO contends “third party” should be construed to mean “a party
`
`other than the entity, the provider, and the secure registry.” Resp., 16-18 (citing
`
`Ex-2004, Jakobsson, ¶45). Brener discloses numerous third parties, none of which
`
`are the customer or vendor. See, e.g., Pet., 39 (“Brener teaches providing to a third
`
`party, such as a shipping carrier or bank, the customer’s actual name and address
`
`without providing said information to the provider....”).2 Because PO’s proposed
`
`construction does not present a material dispute, no construction is necessary for
`
`“third party.”
`
`D.
`
`“The Provider Requesting the Transaction” Is Not the Same as
`the Provider Sending the Transaction Request
`PO argues that the term “the provider requesting the transaction” in claims 1
`
`and 22 should be construed to mean “the provider that sent the transaction
`
`request.” Resp., 19. As explained below in section II.A., PO’s construction does
`
`not support its attempt to distinguish the prior art. While PO argues that the
`
`
`2 All emphasis added unless otherwise noted.
`
`-4-
`
`

`

`
`
`transaction request must be sent directly from the provider to the secure registry,
`
`nothing in its construction excludes the request passing through an intermediary
`
`such as a financial institution before arriving at the secure registry. However, even
`
`without reading a “sent directly” requirement into the construction, it is flawed for
`
`multiple reasons: it is inconsistent with the Board’s construction of a related patent,
`
`the plain language of the ’539 claims, and the specification.
`
`As PO acknowledges, its proposed construction is inconsistent with the
`
`Board’s interpretation of the same language in IPR2018-00812. Resp., 18-19.
`
`There, the Board found this limitation “does not mandate that the provider
`
`‘requesting a transaction’ play any role in generating the transaction request or
`
`passing it to the secure registry.” IPR2018-00812, Paper 9, 11.
`
`PO’s position is also inconsistent with claims 1 and 22, which require only
`
`receipt of a transaction request by the secure registry without ever specifying
`
`which party sends the transaction request. Had PO intended to limit the claim to
`
`an embodiment where the provider sends the transaction request, the claims could
`
`have been phrased to require “receiving a transaction request” from the provider.
`
`Indeed, PO requests substitute claims containing just such a limitation. Paper 13,
`
`App’x B (claim 39[b]). But the claims as presently written leave the sender of the
`
`transaction request unspecified. A transaction may be requested by a provider
`
`even where the provider does not itself deliver the transaction request.
`
`-5-
`
`

`

`
`
`The ’539 specification further undermines PO’s construction. The
`
`specification describes an embodiment wherein the user initiates a request, the
`
`merchant passes the transaction information to the credit card company, and then
`
`the credit card company delivers the transaction request to the secure registry. Ex-
`
`1001, 11:51-61, Fig. 7. Thus, the specification does not limit the party sending the
`
`transaction request to just the merchant/provider.
`
`II. THE ’539 CLAIMS ARE OBVIOUS IN VIEW OF THE PRIOR ART
`A. Brener’s Shipping Carrier and Bank Both Satisfy Limitation 1.6
`Brener discloses that “the account identifying information is not provided to
`
`the provider and the account identifying information is provided to a third party to
`
`enable or deny the transaction with the provider without providing the account
`
`identifying information to the provider,” as required by claims 1, 22, 37, and 38.
`
`See, e.g., Pet., 39-40. The petition cites two aspects of Brener as each
`
`independently disclosing this limitation: disclosure of confidential customer
`
`information to a shipping carrier and separately, to a bank. Id. In response, PO
`
`relies on an improperly narrow claim construction to avoid the shipping
`
`embodiment and mischaracterization of Brener to avoid the bank embodiment.
`
`First, PO narrows construction of the term “to enable transactions” to mean
`
`approving only the financial aspect of the transaction rather than encompassing the
`
`shipping steps of a customer’s purchase of goods or services, without providing
`
`-6-
`
`

`

`
`
`any basis for adopting this unstated construction. Resp., 22-23 (arguing that “the
`
`transaction has already been approved and enabled by the time the shipping carrier
`
`180 gets involved by receiving the account identifying information”).
`
`As an initial matter, PO’s argument improperly reads an “approval”
`
`requirement into the limitation, rather than simply enabling the transaction as the
`
`plain language requires. In doing so, PO contends that once the transaction has
`
`been approved by a financial institution, no other entity can likewise satisfy the
`
`“enable or deny” requirement. This is simply unsupported by the claim. Under the
`
`broadest reasonable interpretation, just because one entity such as a bank has
`
`enabled the transaction does not mean other entities cannot also subsequently do
`
`so.
`
`Moreover, PO’s argument is directly at odds with its own expert’s views and
`
`the ’539 specification, which explicitly discloses shipping carriers such as “[the]
`
`post office, UPS, FedEx” as third parties that may access confidential address
`
`information stored in the USR system in order to enable completion of the
`
`transaction via delivery. Ex-1001, 14:4-58 (“the invention … will enable the user
`
`to receive parcels without requiring the user to provide the merchant with the
`
`address information.”); see also id., 3:31-40 (“[E]nabling anonymous identification
`
`will enable the person to receive mail, other delivered parcels, and other items
`
`without providing the recipient’s address information to the sender.”), 3:44-50,
`
`-7-
`
`

`

`
`
`4:61-65 (“enabling the on-line merchant to ship the goods to a virtual address),
`
`13:28-14:3. Indeed, dependent claim 25 specifically recites an application of the
`
`claimed invention “wherein the transaction includes a service provided by the
`
`provider, wherein the service includes delivery, wherein the account identifying
`
`information is associated with an address to which an item is to be delivered for
`
`the entity, and wherein the third party receives the address for delivery of an item
`
`provided by the provider.” Id. at 29:41-48. In fact, PO’s expert Dr. Jakobsson
`
`completely undermined PO’s position during cross-examination, agreeing that
`
`anonymous shipping constitutes enabling the transaction Ex-1015 69:9-71:7
`
`(stating “there are descriptions in Brener of things that enable the transaction …
`
`when the shipper comes to pick up the package”) (discussing Ex-1005, 10:7-12).
`
`Once PO’s narrow interpretation of the claim is rejected, Brener plainly
`
`discloses the limitation through its anonymous shipping. Brener teaches providing
`
`the customer’s actual name and address to a shipping carrier without providing that
`
`information to the vendor, to enable completion of the transaction between the
`
`vendor and the customer (i.e., delivery of the purchased good or service). See Pet.
`
`39-40; Ex-1002, ¶¶96-98. In this way, “while the secure provider and/or the bank
`
`and the shipping company know who the customer is, advantageously, the
`
`customer’s actual identity is shielded from the vendor.” Id. (citing Ex-1005, at
`
`14:28-15:10); Ex-1002, ¶96.
`
`-8-
`
`

`

`
`
`Second, Brener additionally teaches claim limitation 1.6 where the bank
`
`retrieves and receives from the secure provider the customer’s information using
`
`linking information. Pet. 39-40. PO contends that Brener’s bank does not satisfy
`
`the limitation because Brener “discusses how the vendor sends the customer object
`
`to the third party financial institution, which then looks up the linking
`
`information.” Resp. 24. PO’s argument is flawed with respect to both claim
`
`interpretation and the characterization of Brener.
`
`As to claim interpretation, USR’s argument relies on its claim construction
`
`for “the provider requesting the transaction.”3 Resp. 24. As discussed above in
`
`section I.D., that construction should be rejected. Moreover, PO fails to address a
`
`disconnect between the proposed construction and its limitation 1.6 argument.
`
`While PO construes “the provider requesting the transaction” to mean “the
`
`provider that sent the transaction request,” PO then stretches the construction with
`
`respect to limitation 1.6 to mean the secure registry must receive the transaction
`
`
`
`3 PO’s expert admitted he did not provide an opinion whether the bank in
`
`Brener satisfies the “third party” requirement if PO’s construction is rejected. Ex-
`
`1015, 75:2-8. Additionally, despite PO’s assertion that the arguments for
`
`limitation 1.6 apply to each independent claim (Resp. 22), this argument depends
`
`on a claim construction only proposed for claims 1 and 22 (see Resp. 18).
`
`-9-
`
`

`

`
`
`request directly from the provider, without it passing through any intermediary.
`
`Resp. 24-25. This is unsupported by PO’s own construction or any aspect of the
`
`’539 patent cited in PO’s response. See Resp. 18-20 (arguing only that the
`
`provider “makes” or “sends” the transaction request). In fact, the ’539
`
`specification clearly describes that transmission of the transaction request to the
`
`secure provider may be indirect. See, e.g., Ex-1001, 11:51-61 (“The merchant
`
`transmits [request] to the credit card company.”). Accordingly, it is irrelevant
`
`whether the transaction request in Brener goes directly from the vendor to the
`
`secure provider or first passes through the bank.
`
`Moreover, PO is wrong in arguing that Brener only discloses that “the
`
`vendor sends the customer object to the third party financial institution.” Resp. 24.
`
`While limitation 1.6 is silent about which entity receives the transaction request
`
`(contrary to PO’s contention), limitation 1.2 requires that the secure registry
`
`system receive the request. For that limitation, Brener demonstrates that the secure
`
`provider can receive the transaction request, including the customer object, directly
`
`from the vendor. See, e.g., Pet. 29-30 (citing Ex-1005, 2:19-3:11 (“sending the
`
`transaction identifier together with the customer object to the secure computer by
`
`the vendor computer”), 14:16-22 (describing secure computer “transmit[ting]
`
`information about the request for payment to bank computer”); see also Ex-1005,
`
`14:5-6.
`
`-10-
`
`

`

`
`
`What’s more, even where Brener discloses sending a transaction request
`
`from a vendor to a bank rather than directly to the secure provider computer,
`
`limitation 1.6 is still met because the bank sends the request to the secure provider,
`
`which then provides account identifying information to the bank via the linking
`
`table stored in the database of the secure provider computer. Pet. 39-40; Ex-1005,
`
`9:23-26 (“The bank computer 150 obtains … the linking information to link the
`
`customer object with personal information about the customer, including customer
`
`account information.”); see also Ex-1005, 8:9-20 (cited at Pet. 31-32) (“This
`
`linking information is stored, in one embodiment, in a linking table stored in the
`
`database 130 of the secure provider computer 110. … Using this linking table, the
`
`secure provider computer 110 or the bank computer 150 can determine which
`
`customer a given customer object represents.”).4 In addition, even where the
`
`vendor sends the transaction request to the bank, Brener explains that it is also sent
`
`from the vendor directly to the secure provider. See Ex-1005, 3:1:4 (vendor sends
`
`
`
`4 PO’s expert did not consider whether Brener discloses the bank receiving
`
`customer identity and account information from the secure provider. Ex-1015,
`
`73:8-12.
`
`
`
`-11-
`
`

`

`
`
`transaction request to secure computer), 3:25-30 (“[T]he above methods further
`
`comprise sending” request from vendor to financial institution computer.).
`
`Accordingly, in view of these teachings, PO’s arguments that Brener fails to
`
`teach limitation 1.6 should be rejected.
`
`B. A Person of Ordinary Skill Would Have Had Reason to Combine
`Brener and Weiss, Despite PO’s Mischaracterization of Brener’s
`“Private Key Authorization Code”
`A person of ordinary skill would have been motivated to utilize a time-
`
`varying multicharacter code, as taught by Weiss, to identify and authenticate a user
`
`of an anonymous transaction system like the one in Brener. Pet., 57-59. The
`
`proposed modification encompasses “incorporat[ing] a time-varying aspect into
`
`Brener’s customer objects, resulting in a time-varying code that corresponds to the
`
`user’s identity via the linking information stored in the secure database.” Id., 57.
`
`As one way to implement this, Petitioner explained that Brener’s private key
`
`authorization code could be modified “to utilize a dynamic non-predictable, time-
`
`varying code.” Pet., 57. PO attacks the proposed modification by arguing the
`
`private key authorization code can only be a digital certificate, which cannot be
`
`time-varying. Resp. 26-38. As an initial matter, PO’s argument is misplaced, as
`
`modification to Brener’s private key authorization code was only discussed as one
`
`“example” of how the combination could be achieved. See Pet. 57. PO does not
`
`respond to Petitioner’s broader proposal to incorporate a time-varying aspect into
`
`-12-
`
`

`

`
`
`the customer object and attacking a single example of how this could be
`
`accomplished does not rebut the combination proposed.
`
`However, even PO’s arguments as to the private key authorization code are
`
`baseless. While Brener’s “private key authorization code” may be a digital
`
`certificate, private key, or an authorization code generated by a private key such as
`
`a digital signature, PO incorrectly argues that it can only be a digital certificate.
`
`See Resp., 33. This argument flies in the face of Brener’s express disclosure.
`
`As Dr. Tygar explained during his deposition, “[o]ne possibility is this is
`
`Brener using terminology in an idiosyncratic way to indicate that this is the private
`
`pair of the asymmetric key pair.” Id., 32-33 (quoting Ex-2005, 39:24-40:1). PO
`
`disputes Dr. Tygar’s explanation, arguing that using a private key for the private-
`
`key authorization code is “nonsensical.” Resp., 33. Yet PO’s argument directly
`
`contradicts the express teachings of Brener. Brener describes that “this [customer]
`
`object may have both a public and private segment to a digital certificate or key.”
`
`Brener 10:27-28. In other words, Brener explicitly teaches that the private key
`
`may be disseminated to specific parties to the transaction as part of the private
`
`segment of the customer object. See also Ex-2005 40:24-41:1 (“Brener would be
`
`thinking that only a portion of the customer object was made public while a portion
`
`was kept private.”). PO’s argument to the contrary would have the Board ignore
`
`the plain teachings of the prior art.
`
`-13-
`
`

`

`
`
`What’s more, PO’s own expert opined in his first declaration that ‘[t]he
`
`‘private key authorization code’ discussed in Brener is a digital signature.” Ex.
`
`2001 ¶63; see also, e.g., Ex-1005, 13:6-10. He subsequently admitted that a digital
`
`signature is not the same thing as a digital certificate and explained that if the term
`
`“digital signature” is used to describe “something that the user generates as a
`
`digital signature, it would not be understood by a person of skill in the art that this
`
`is a certificate.” Ex-1015, 86:22-87:2, 87:16-88:11. This, of course, is exactly
`
`what Brener describes. See, e.g., Ex-1005, 16:1-6. It simply cannot be the case
`
`that Brener’s private key authorization code is limited to a digital certificate.
`
`Second, even where the “private key authorization code” is a digital
`
`certificate, PO’s rebuttal is misplaced. PO’s argument is premised on an assertion
`
`that a time-varying digital certificate would be infeasible. See, e.g., Resp. 33
`
`(“[A]ttempts to modify [a digital certificate] so that it varies over time … would be
`
`crippling.”); 34 (discussing “varying the digital certificates in real time”); 36
`
`(“time-varying digital certificate”). This does not respond to the proposed
`
`modification. As explained by Dr. Tygar, a person of ordinary skill would have
`
`incorporated a time-varying aspect into Brener’s customer object by appending the
`
`time-varying portion to the existing information, such as the private key
`
`authorization code, not by replacing it. Ex-2005, 55:12-56:10. (“The modification
`
`does not change … the digital signature portion of that private-key authorization
`
`-14-
`
`

`

`
`
`code, but appends to it this time-varying portion.”). The Board similarly
`
`recognized in the institution decision that the proposed combination is “not one
`
`that makes Brener’s entire customer object time varying” but rather one that
`
`incorporates a time-varying aspect. D.I., 13 (citing Pet., 28). PO has no response
`
`other than to mischaracterize the proposed combination.
`
`Rather than address the actual ground of challenge PO attacks a straw man,
`
`arguing that the “proposed modification would require that the certificate authority
`
`be tasked with varying the digital certificates in real time since only it has access to
`
`its private key, which is needed to generate the private key authorization code (i.e.,
`
`digital certificate) by the certificate authority.” Resp. 34. Yet appending the time-
`
`varying aspect to the digital certificate, as explained by Dr. Tygar, can be done by
`
`the user’s computer and does not require the certificate authority’s involvement at
`
`all. See Ex-1002 ¶64; Ex-2005, 48:13-19, 56:2-10. Because the digital certificate
`
`portion is unaffected, the certificate authority or the bank could still verify the
`
`unmodified digital certificate.
`
`PO also mischaracterizes the proposed combination of Brener and Weiss in
`
`arguing that the combination would eliminate the ability to track returning
`
`customers. Resp., 38-40. In doing so, PO assumes, without support, that the
`
`public key portion of the customer object must serve as the element that allows a
`
`vendor to identify returning customers. However, Brener clearly states that the
`
`-15-
`
`

`

`
`
`customer object name or “persona” (such as “GOLFO”) identifies returning
`
`customers. See, e.g., Ex-1005, 8:6-11, 11:13-17. Nowhere in Brener is “GOLFO”
`
`referred to as a public key.
`
`Additionally, even if the public key were to be used to track returning
`
`customers, nothing about the proposed modification would eliminate that
`
`functionality. Again, as Dr. Tygar explained, if the time-varying element is
`
`appended to the existing customer object information, it would not compromise the
`
`functionality of other portions of the customer object. Ex-2005, 59:1-11 (“[I]t
`
`would be obvious to one of ordinary skill in the art that if you appended
`
`information that was varying to a static portion of a customer object and that static
`
`portion were unique, then the recognition function that you described would still be
`
`retained.”); see also id. 48:16-19 (“So, as an example, if one were to append
`
`information to -- to a value that would in no way compromise the ability of -- to
`
`use a digital certificate to verify information.”).
`
`C.
`
`PO Mischaracterizes the Proposed Combination of Brener and
`Desai to Argue that Such Combination Would “Teach Away or
`Contradict the Invention as Claimed”
`Rather than directly challenge the proffered rationale to combine Brener
`
`and Desai, PO attacks their combination by arguing that the references would
`
`teach away from the claimed invention. Resp., 43-46. In PO’s view, this is
`
`because “Petitioner consistently provides reasons why a POSITA would modify
`
`-16-
`
`

`

`
`
`Brener to further disclose user information to vendors—information that the
`
`present claims specifically require not be disclosed to a provider.” Resp. 44
`
`(emphasis original). This is a mischaracterization of the claimed invention and
`
`the references, all of which allow user information to be disclosed to vendors.
`
`The ’539 patent outlines a scheme for hiding one type of information
`
`(“account identifying information”) from the merchant during a transaction while
`
`other information must be shared (such as the user’s selection of goods for
`
`purchase). PO admits in claim construction arguments that the specification
`
`provides that “USR software 18 queries whether the requestor has the right to
`
`access the type of requested data,” where the requestor is the provider (e.g.,
`
`vendor). Resp., 14-15 (citing Ex-1001, ’539 patent, 10:40-48). This is directly
`
`analogous to Brener, which provides an anonymous shopping and shipping system.
`
`The fact that Brener also describes sharing non-account identifying information
`
`(such as a customer’s shopping preferences) does not contradict or teach away
`
`from the claimed invention. See Pet., 59-62 (citing Ex-1002, 66-69). Moreover,
`
`nothing in the claims requires that the account identifying information be withheld
`
`from all providers, only “a provider.”
`
`PO also argues that Desai’s teaching of determining if an individual vendor
`
`has access rights to the data is a “running flaw in Petitioner’s proposed
`
`combination.” Resp., 45 (citing Ex-1007, Desai, 4:16-18 (“the vendors will not
`
`-17-
`
`

`

`
`
`receive this information unless and until the registered user provides access to the
`
`vendor.”). According to PO, the problem is that “Desai does not disclose that the
`
`stored information can be released instead to another party unrelated to the
`
`vendor making the request.” Resp., 45. But this is only a “problem” because PO
`
`mischaracterizes the combination of Desai and Brener. In other words, PO
`
`attacks each reference in isolation rather than addressing the proposed combination
`
`of Brener, Desai, and Weiss. PO attacks Desai for not allowing a user to
`
`selectively grant access to its stored data to a third party, but that is not reflective
`
`of the combination presented in the petition. PO does not dispute that Brener
`
`discloses a system providing anonymous transactions on vendor websites, while
`
`permitting other third parties access to customer information. Pet., 18-22. The
`
`proposed combination does not eliminate Brener’s anonymity, but merely
`
`combines Brener’s secure provider system with Desai’s granular access controls.
`
`See, e.g., Pet., 22-23, 39-40, 56-62.
`
`As outlined in the petition, combining granular control over what data may
`
`be divulged to particular parties during online transactions, as described in Desai,
`
`with an anonymous online transaction system such as described in Brener would
`
`have been nothing more than a combination of known elements from prior art
`
`according to known methods to yield predictable results. Pet., 22-23; see also id.,
`
`60 (citing Ex-1002, ¶¶66-67). Such a combination would result in a remote secure
`
`-18-
`
`

`

`
`
`database system combining the anonymous transaction benefits of Brener, which
`
`provide a design that “shields personal information from the vendor,” with Desai’s
`
`element-by-element and user-by-user access controls. Id. Thus, the combination
`
`would not run counter to Brener’s teachings, but rather would have been consistent
`
`with, and enhanced, Brener’s stated purpose of enabling selective access to
`
`information to provide anonymous shopping, shipping, and other transactions. Id.
`
`(citing Ex-1002, ¶67); see also Pet. 36 (citing Ex-1005, 4:3-7 and explaining
`
`combination is consistent with Brener’s disclosure of allowing customer to
`
`selectively reveal customer information to vendors); Pet. 59-61. Furthermore, PO
`
`mischaracterizes Desai itself, which describes allowing multiple third parties to
`
`access the user’s data. See Pet., 11 (citing Ex-1007, 9:10-14; Ex-1002 ¶38); Pet.,
`
`35 (citing Ex-1007, 9:1-18; Ex-1002 ¶90).
`
`D.
`
`PO Improperly Selects and Attacks Specific Implementations of
`Desai Never Proposed in the Petitioner’s Combination.
`PO argues that “[a] close review of Brener and Desai reveals that a POSITA
`
`would not have had a reasonable expectation of success of making the combination
`
`proposed by Petitioner to achieve the claimed invention.” Resp., 46. But PO’s
`
`“close review” involves cherry-picking and mischaracterizing specific
`
`implementations of Desai not relied upon in the proposed combination.
`
`PO argues that combining Brener and Desai requires that “someone
`
`attempting to access the stored data must have the merchant’s private key—but the
`
`-19-
`
`

`

`
`
`only party that would have acces