Patent Owner’s Demonstrative Slides
`U.S. Patent No. 8,856,539
`
`VISA Inc., VISA U.S.A. Inc., and Apple Inc., Petitioners
`v.
`Universal Secure Registry, LLC, Patent Owner
`Case No. IPR2018-01350
`United States Patent and Trademark Office
`November 21, 2019
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`1
`
`
`U.S. Patent No. 8,856,539
`
`VISA Inc., VISA U.S.A. Inc., and Apple Inc., Petitioners
`v.
`Universal Secure Registry, LLC, Patent Owner
`Case No. IPR2018-01350
`United States Patent and Trademark Office
`November 21, 2019
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`1
`
`
`
`Roadmap
`
`Overview Of ‘539 Patent & Prior Art
`
`Limitation 1.1: “time-varying multicharacter code”
`
`Limitation 1.4: “access restrictions”
`
`Limitation 1.6: Secure Registry “providing AII to a third party”
`
`USR’s Substitute Claims Are Patentable
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`2
`
`
`
`Roadmap
`
`Overview Of ‘539 Patent & Prior Art
`
`Limitation 1.1: “time-varying multicharacter code”
`
`Limitation 1.4: “access restrictions”
`
`Limitation 1.6: Secure Registry “providing AII to a third party”
`
`USR’s Substitute Claims Are Patentable
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`3
`
`
`
`Overview Of The ’539 Patent
`
`’539 Patent
`
`US 8,856,539
`Universal Secure Registry
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Challenged Claims 1-4,
`9, 16, 21-25, 31, and 37-
`38 of the ’539 Patent are
`at issue.
`
`• Petitioner’s Sole Ground
`is 35 U.S.C. Section 103
`Obviousness: Brener,
`Weiss and Desai.
`
`• Petitioner Has Not
`Shown the Challenged
`Claims are Obvious over
`Brener in view of Weiss
`and Desai.
`
`POR at 1, 22-57.
`
`4
`
`
`
`Overview Of The ’539 Patent: Limitations At Issue
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`Limitation 1.1: “time-varying
`multicharacter code.”
`
`Limitation 1.4: “access
`restrictions.”
`
`Limitation 1.6: “account
`identifying information [AII] is
`not provided to the provider
`and the AII is provided to a
`third-party to enable or deny
`the transaction with the
`provider without providing the
`AII to the provider.”
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`5
`
`Ex. 1001, ’539 Patent at Cl. 1
`
`Ex. 1001, ’539 Patent at Cl. 1
`
`
`
`Overview Of Prior Art: WO 00/14648 “Brener”
`
`Brener
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Brener is directed to a
`centralized system that
`generates static
`customer objects that are
`used by customers to
`anonymously shop at
`vendor websites.
`
`US 5,930,767
`
`Electronic Commerce With
`Anonymous Shopping And
`Anonymous Vendor Shipping
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`POR at 9-10.
`
`6
`
`
`
`Brener’s Static Customer Object Includes Public Key and Private
`Key Authorization Code
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`Brener:
`
`• Brener teaches that its
`static customer object
`may include a public key
`and a private key
`authorization code.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`7
`
`Ex. 1005 at 13:18-19.
`
`POR at 27-32.
`
`
`
`Customer Logs Into Brener’s Secure Provider with Static ID/password
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• Brener’s system requires
`that a customer log into
`the secure provider with
`a static ID/password to
`authenticate the
`customer’s identity
`before the customer can
`anonymously shop
`vendor websites.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 8:3-6.
`
`Sur-reply at 17-18.
`
`8
`
`
`
`Brener’s Bank Obtains Linking Information to Map Customer Object to
`Customer’s Personal Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• To execute a purchase
`transaction, the vendor
`forwards the customer
`object to the bank.
`
`• The bank obtains “linking
`information” that it uses
`to map the customer
`object to the customer’s
`personal information.
`
`• The bank then
`determines whether to
`enable/deny the
`purchase transaction.
`POR at 23-25;
`Sur-reply at 5-9.
`
`9
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 9:19-29.
`
`
`
`Brener’s Shipping Carrier Ships the Goods After the Bank Enables the
`Transaction
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• After the bank
`determines whether to
`enable or deny the
`purchase transaction, the
`shipping carrier ships the
`goods (if transaction is
`enabled by bank).
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 13:25-26, 14:16-22.
`
`POR at 22-23;
`Sur-reply at 2-5.
`
`10
`
`
`
`Overview Of Prior Art: U.S. Pat. 6,820,204 B1 “Weiss”
`
`Weiss
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Weiss describes a
`“predetermined algorithm
`[that] constantly
`generates new unique
`and verifiable non-
`predictable codes, which
`are derived from the fixed
`data and at least one
`dynamic variable, such
`as the time of day.”
`
`Method and Apparatus for Synchronizing
`Generation of Separate, Free Running, Time
`Dependent Equipment
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`POR at 10-11.
`
`11
`
`
`
`Weiss’s Time-varying Codes are Used to Positively Identify an Entity
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Weiss:
`
`• Weiss’s time-varying
`codes are used for the
`purpose of positively
`identifying a person—i.e.,
`confirming that they are
`who they say they are—
`before granting access to
`a system.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1006 at 1:15-21.
`
`Sur-reply at 16-17.
`
`12
`
`
`
`Weiss’s Time-varying Codes are Meant to Replace Static Usernames
`or Passwords
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner’s Expert, Dr. Tygar, on Weiss:
`
`• Weiss’s time-varying
`codes are meant to
`replace static, fixed
`codes that are
`susceptible to
`interception and copying,
`such as a username or
`password.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1002, Tygar Decl. at ¶35 (citing Ex. 1006 at 1:36-40).
`
`Sur-reply at 16-17.
`
`13
`
`
`
`Overview Of Prior Art: U.S. Pat. 6,820,204 B1 “Desai”
`
`Desai
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Desai discloses a system
`that “provid[es] users
`with granular control over
`arbitrary information that
`allows for selective, real-
`time information sharing
`in a communications
`network.”
`
`System and Method for Selective
`Information Exchange
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`POR at 11 (citing Ex. 1006 at Abstract).
`
`14
`
`
`
`Desai’s Key Management System Allows a Party to Access Stored
`Data Encrypted for That Party Using the Party’s Private Key
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`• Key management system
`(KMS) generates public-
`private key pairs for
`every registered user and
`generates a secret key
`for each discrete data
`element that is used to
`encrypt and decrypt data
`element.
`
`• Party desiring access to
`stored data must use its
`private key to access the
`secret key used to
`decrypt the stored data.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`POR at 46-47 (citing Ex. 1007 at 12:18-15:11); FIG. 5.
`
`POR at 46-47.
`.
`
`15
`
`
`
`Roadmap
`
`Overview Of ‘539 Patent & Prior Art (Brener, Weiss & Desai)
`
`Limitation 1.1: “time-varying multicharacter code”
`
`Limitation 1.4: “access restrictions”
`
`Limitation 1.6: Secure Registry “providing AII to a third party”
`
`USR’s Substitute Claims Are Patentable
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`16
`
`
`
`Limitation 1.1: Transaction Request Includes Time-varying
`Multicharacter Code
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`• All claims include a time-
`varying multicharacter
`code used to identify each
`entity.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1001, ‘539 patent at Claim 1.
`
`POR at 25-42;
`Sur-reply at 9-20.
`
`17
`
`
`
`Petitioner Abandoned Original Argument in Favor of New Argument
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner’s Original Argument in Petition:
`
`Petitioner’s New Argument in Reply:
`
`Ex. 1002, Tygar Decl. at ¶63; Petition at 28-29.
`
`• Petitioner changed its
`argument from “modifying
`Brener’s…private key
`authorization code to
`utilize a dynamic non-
`predictable, time-varying
`code” to “appending the
`time-varying portion to
`the…private key
`authorization code.”
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Reply at 14.
`
`Sur-reply at 14-16.
`
`18
`
`
`
`Petitioner Changed Its Argument Because PO Debunked Petitioner’s
`Original Argument That PKAC Would Be Modified to Vary In Time
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Patent Owner Showed that:
`
`1. Private Key Authorization Code is a Digital Certificate.
`
`2. A Time-varying Digital Certificate Would Cripple Brener.
`
`POR at 27-37.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`19
`
`
`
`Private Key Authorization Code is a Digital Certificate
`
`Brener:
`
`Dr. Jakobsson:
`
`Ex. 1005 at 13:18-19.
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Skilled artisan would
`understand that a Private
`Key Authorization Code is
`a standard digital
`certificate that allows a
`recipient of the customer’s
`public key to confirm that
`the public key actually
`belongs to the customer.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 2004, Jakobsson Decl. at ¶65.
`
`POR at 27-32;
`Sur-reply at 13.
`
`20
`
`
`
`Private Key Authorization Code is a Digital Certificate
`
`Brenner:
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Brener teaches that the
`bank computer 150 would
`use such a digital
`certificate and the
`customer’s public key in
`the customer object to
`verify the customer’s
`digital signature during a
`purchase transaction.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 16:14-23.
`
`POR at 27-32;
`Sur-reply at 13.
`
`21
`
`
`
`Private Key Authorization Code is a Digital Certificate
`
`Petitioner’s Expert (Dr. Tygar) Agrees PKAC is a
`
`Digital Certificate:
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Dr. Tygar admitted that the
`private key authorization
`code is a digital certificate
`issued by a certificate
`authority.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 2005 at 39:2-40:4.
`
`POR at 32-33;
`Sur-reply at 11-12.
`
`22
`
`
`
`Private Key Authorization Code is Not the Customer’s Private Key
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Dr. Tygar’s other “Possibility” Makes No Sense:
`
`• Dr. Tygar’s alternative
`explanation—that the
`private key authorization
`code is the customer’s
`private key—makes no
`sense.
`
`• Customers don’t share
`their private keys with
`vendors (or anyone else).
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 2005 at 39:2-40:4.
`
`POR at 32-33;
`Sur-reply at 11-12.
`
`23
`
`
`
`Petitioner’s Time-Varying Digital Certificate Would Cripple Brener
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Dr. Jakobsson:
`
`• Varying the digital
`certificate in time would
`render the digital
`certificate void and
`useless.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 2004, Jakobsson Decl. at ¶67.
`
`POR at 33-36;
`Sur-reply at 11-14.
`
`24
`
`
`
`Petitioner’s Time-Varying Digital Certificate Would Cripple Brener
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Dr. Jakobsson:
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 2004, Jakobsson Decl. at ¶72.
`
`• Varying the digital
`certificate in time would
`also require the certificate
`authority to do something
`it normally never does—
`involve itself in each
`transaction to generate
`and supply updated
`certificates.
`
`• The result would be
`taxing, slow, costly, and
`render Brener’s system
`unusable.
`
`POR at 33-36;
`Sur-reply at 11-14.
`
`25
`
`
`
`Petitioner Does Not Dispute That Varying a Digital Certificate in Time Is
`Unworkable – Presents New Argument Instead
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner Does Not Dispute That Varying a Digital
`
`Certificate Would Not Work:
`
`• Instead of disputing PO’s
`position, Petitioner
`abandoned its original
`argument that the PKAC
`would be “modified” in
`favor or a new argument:
`that a skilled artisan would
`append a time-varying
`portion to the PKAC,
`leaving Brener’s PKAC
`unmodified.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`26
`
`Reply at 14.
`
`Sur-reply at 13-16.
`
`
`
`Panel Should Disregard Petitioner’s New “Appended” Argument
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Customer Object with “Modified” Time-varying PKAC:
`
`Customer Object with Time-varying Code Appended to PKAC:
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`• Petitioner first argued a
`skilled artisan would
`modify the PKAC.
`
`• Petitioner now argues that
`a skilled artisan would
`append a time-varying
`portion to an unmodified,
`static PKAC.
`
`• Panel should disregard
`Petitioner’s new argument.
`
`Sur-reply at 14-16.
`
`27
`
`
`
`Skilled Artisan Would Not Be Motivated to Append Weiss’s Time-varying
`Code to Brener’s Customer Object During a Transaction Request
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Weiss:
`
`• Weiss’s time-varying
`codes are used for the
`purpose of positively
`identifying a person—i.e.,
`confirming that they are
`who they say they are—
`before granting access to
`a system.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1006 at 1:15-21.
`
`Sur-reply at 16-17.
`
`28
`
`
`
`Skilled Artisan Would Not Be Motivated to Append Weiss’s Time-varying
`Code to Brener’s Customer Object During a Transaction Request
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner’s Expert Dr. Tygar on the Purpose of
`
`Weiss’s Time-varying Code:
`
`• Dr. Tygar agrees that
`Weiss’s time-varying
`codes were meant to
`replace static, fixed codes
`that are susceptible to
`interception and copying,
`such as a customer’s user
`name or password.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1002, Tygar Decl. at ¶35 (citing Ex. 1006 at 1:36-40).
`
`Sur-reply at 16-17.
`
`29
`
`
`
`Skilled Artisan Would Not Be Motivated to Append Weiss’s Time-varying
`Code to Brener’s Customer Object During a Transaction Request
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• Brener’s system requires
`that a customer log into
`the secure provider with a
`static ID/password to
`authenticate its identity.
`
`• Petitioner’s proposed
`combination does not
`consider that the customer
`is already authenticated
`and has access to the
`customer’s personal
`information before a
`transaction is initiated.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 8:3-6.
`
`Sur-reply at 17-18.
`
`30
`
`
`
`Skilled Artisan Would Not Be Motivated to Append Weiss’s Time-varying
`Code to Brener’s Customer Object During a Transaction Request
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• Brener requires that the
`customer log into secure
`provider 110 with a static
`ID/password to
`authenticate itself and
`connect to secure provider
`110.
`
`• At this point the customer
`is already authenticated
`and has access to secure
`data stored at the registry.
`
`Sur-reply at 17-18; see also MTA Reply at 13 (citing Ex. 1005 at FIG. 1).
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Sur-reply at 17-20.
`
`31
`
`
`
`Skilled Artisan Would Not Be Motivated to Append Weiss’s Time-varying
`Code to Brener’s Customer Object During a Transaction Request
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• Providing a customer
`object with an appended
`time-varying code during
`the transaction serves no
`purpose:
`– Customer is already
`authenticated and has
`access to secure data;
`
`– Static portion of the
`customer object already
`uniquely identifies the
`customer and allows the
`secure provider to identify
`the customer’s personal
`information.
`
`Sur-reply at 17-20.
`
`32
`
`Sur-reply at 17-18; see also MTA Reply at 13 (citing Ex. 1005 at FIG. 1).
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`
`
`Roadmap
`
`Overview Of ‘539 Patent & Prior Art (Brener, Weiss & Desai)
`
`Limitation 1.1: “time-varying multicharacter code”
`
`Limitation 1.4: “access restrictions”
`
`Limitation 1.6: Secure Registry “providing AII to a third party”
`
`USR’s Substitute Claims Are Patentable
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`33
`
`
`
`Limitation 1.4: Determining Compliance with Access Restrictions
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`• Before the secure registry
`accesses and provides
`account identifying
`information to a third
`party, the secure registry
`determines whether the
`provider complies with
`access restrictions based
`on the indication of the
`provider and the time-
`varying multicharacter
`code of the transaction
`request.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1001, ‘539 patent at Cl. 1; see also Cls. 22, 37.
`
`POR at 42-49;
`Sur-reply at 20-24.
`
`34
`
`
`
`Board Disagreed Brener Alone Teaches Limitation 1.4
`
`Board Previously Rejected Petitioner’s Assertion as Being
`Based on a Flawed Claim Construction:
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Institution Decision at 8-9, 14; Ex. 1001 at Cl. 1.
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• The Board determined
`that the claim language
`“all but requires” that
`determining compliance
`with access restrictions
`must be “based at least in
`part on the indication of
`the provider and the time-
`varying multicharacter
`code of the transaction
`request.”
`
`• Petitioner does not argue
`that Brener discloses the
`claimed “access
`restrictions” under this
`construction.
`POR at 42-43 (citing ID at 8-9).
`
`35
`
`
`
`Petitioner Provides No Evidence That Proposed Combination Would
`Release Data to Third Party After Vendor Satisfies Access Restrictions
`’267
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner Only Argues That Vendor Gains Access To Data
`When The Vendor Satisfies Access Restrictions:
`
`• Claim language requires
`secure registry to release
`account identifying
`information to a third party
`after the requesting
`vendor satisfies access
`restrictions.
`
`• Petitioner neither argues
`nor provides evidence
`showing that its
`Brener/Desai combination
`results in a secure registry
`that releases data in this
`manner.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Petition at 36.
`
`POR at 42-49;
`Sur-reply at 20-24.
`
`36
`
`
`
`Petitioner Provides No Evidence That Proposed Combination Would
`Release Data to Third Party After Vendor Satisfies Access Restrictions
`’267
`’812
`
`ASSERTED PATENT
`
`’598
`
`Desai Teaches A Vendor-Based Security System, Where Each
`Vendor Acquires Data Access Based On Permissions Granted
`To That Vendor:
`
`• Petitioner neither argues
`nor provides evidence
`showing that Desai
`teaches clearing access
`restrictions for a vendor to
`then release account
`identifying information to a
`separate third party.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Petition at 60.
`
`POR at 42-49;
`Sur-reply at 20-24.
`
`37
`
`
`
`Petitioner Provides No Evidence That Proposed Combination Would
`Release Data to Third Party After Vendor Satisfies Access Restrictions
`’267
`’812
`
`ASSERTED PATENT
`
`’598
`
`On Reply, Petitioner Argues That Adding Desai to Brener
`Does Not Change the Security Structure of Brener:
`
`• Brener restricts data flow
`based on category
`(vendor, bank, shipper) of
`recipient.
`
`• Desai does not change
`this approach, only adding
`greater granularity with
`individual private keys.
`
`• Desai does not teach
`clearing access
`restrictions for a vendor to
`then release account
`identifying information to a
`separate third party.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Reply at 20.
`
`POR at 42-49;
`Sur-reply at 20-24.
`
`38
`
`
`
`Petitioner’s New Argument Fails to Provide a Secure Registry That Releases Data
`to Third Party After Vendor Satisfies Access Restrictions
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner’s New “Appended Merchant’s Key” Argument on Reply:
`
`• New argument not raised
`in Petition.
`
`• Still deficient, as would
`result in a secure registry
`that determines access
`restrictions for each party
`(e.g., vendor, bank,
`shipper), using that
`party’s private key, to
`release data only to that
`party.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Reply at 20.
`
`POR at 42-49; Sur-reply at 20-24.
`
`39
`
`
`
`Petitioner Fails to Provide Sufficient Detail Explaining How a Skilled
`Artisan Would Combine Desai’s Granularity Mechanism Into Brener
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petition Only Provides Generalized Discussion Of Combination:
`
`• Petitioner only provides
`high-level purported
`benefits of the proposed
`combination
`
`• Provides no technical
`explanation of how a
`skilled artisan would
`incorporate Desai’s public-
`private key-based
`information exchange
`database into Brener’s
`architecture to create the
`claimed invention.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Petition at 60.
`
`POR at 46-49;
`Sur-reply at 22-24.
`
`40
`
`
`
`Petitioner Fails to Provide Sufficient Detail Explaining How a Skilled
`Artisan Would Combine Desai’s Granularity Mechanism Into Brener
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner’s Proposed Combination Fails to Explain How the
`Resulting Secure Registry Would:
`
`1. Prevent each vendor from using its own private key to
`access the account identifying information.
`2. Determine that a vendor having the private key complies
`with access restrictions (based on time-varying
`multicharacter code), but then releases the account
`identifying information to a third party different from
`the vendor.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`POR at 46-49; Sur-reply at 22-24.
`
`• Petitioner does not explain
`how modifying Brener to
`include Desai’s key
`management system
`would satisfy at least two
`separate claim
`requirements.
`
`• Failure to explain how the
`combined system would
`satisfy these claim
`requirements eliminates
`any showing that a skilled
`artisan would have a
`reasonable expectation of
`success.
`
`POR at 46-49;
`Sur-reply at 22-24.
`
`41
`
`
`
`Petitioner’s Proposed Combination Fails to Explain How to Avoid
`Releasing Account Identifying Information to a Provider
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Desai:
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`POR at 46-47 (citing Ex. 1007 at 12:18-15:11); FIG. 5.
`
`• In Desai, data is encrypted
`so that each user can use
`their own private key to
`access data specifically
`stored for that user.
`
`• Permitting use of a
`vendor’s private key to
`access data upon the
`vendor’s compliance with
`access restrictions would
`necessarily permit the
`release of account
`identifying information to
`that vendor.
`
`POR at 46-49;
`Sur-reply at 23-24.
`
`42
`
`
`
`Roadmap
`
`Overview Of ‘539 Patent & Prior Art (Brener, Weiss & Desai)
`
`Limitation 1.1: “time-varying multicharacter code”
`
`Limitation 1.4: “access restrictions”
`
`Limitation 1.6: Secure Registry “providing AII to a third party”
`
`USR’s Substitute Claims Are Patentable
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`43
`
`
`
`Limitation 1.6: Secure Registry of Claimed Invention Provides Account
`Identifying Information To Third Party
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`• Secure registry of claimed
`invention provides account
`identifying information to
`the third party to enable or
`deny the transaction with
`the provider.
`
`• Account identifying
`information is not provided
`to the provider.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1001, ‘539 patent at Cl. 1; see also Cls. 22, 37, 38.
`
`POR at 22-25;
`Sur-reply at 2-9.
`
`44
`
`
`
`Brener’s Secure Provider Does Not Provide Third Party Bank With
`Account Identifying Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Citing Brener at 9:19-10:2, Petition Incorrectly Argues:
`
`• Petition alleges that
`Brener’s secure provider
`is the claimed “secure
`registry,” and Brener’s
`bank is the claimed “third
`party.”
`
`• Petition incorrectly argues
`that Brener at 9:19-10:2
`discloses that the bank
`receives “account
`information” from the
`secure provider. It does
`not.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Petition at 40.
`
`POR at 23-25;
`Sur-reply at 5-9.
`
`45
`
`
`
`Brener’s Secure Provider Does Not Provide Third Party Bank With
`Account Identifying Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• Bank 150 obtains only
`linking information,
`which is not claimed
`account identifying
`information.
`
`• This embodiment omits
`any mention of secure
`provider 110.
`
`• This embodiment does not
`disclose how bank 150
`obtains linking information.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 9:19-29
`
`POR at 23-25;
`Sur-reply at 5-9.
`
`46
`
`
`
`Brener’s Secure Provider Does Not Provide Third Party Bank With
`Account Identifying Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Institution Decision cites this portion of Brener:
`
`Brener:
`
`Ex. 1005 at 3:30-4:2.
`
`• Again, bank only obtains
`linking information,
`which is not account
`identifying information.
`
`• Bank acts as secure
`registry—not the claimed
`“third party”—by receiving
`customer object from
`vendor and “ascertaining
`the identity” of the
`customer using “linking
`information.”
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 3:25-29.
`
`POR at 23-25;
`Sur-reply at 5-9.
`
`47
`
`
`
`Brener’s Linking Information is Not the Claimed Account Identifying
`Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener Defines “Linking Information”:
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 8:11-20.
`
`• Linking information is the
`relational information
`stored in a “table” that
`“matches up each
`customer object with the
`customer’s personal
`information.”
`
`• Linking information is not
`the “customer’s personal
`information” that the
`customer wants shielded
`from the vendor (i.e.,
`account identifying
`information).
`
`POR at 23-25;
`Sur-reply at 5-9.
`
`48
`
`
`
`Brener’s Linking Information is Not the Claimed Account Identifying
`Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner Identifies Brener’s Account Identifying Information:
`
`Board Similarly Held in Related Case:
`
`The construction for “[A]ccount identifying information” as meaning
`“personal information about an entity such as name, address, or account
`number” “is supported by the Specification.”
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`49
`
`Petition at 38; POR at 23-25, Sur-reply at 5-9; IPR2018-00812, Paper 45 at 8.
`
`
`
`Brener’s Linking Information is Not the Claimed Account Identifying
`Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Petitioner Uses “Linking Information” to Map Customer
`Object to Customer:
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`50
`
`Petition at 32; POR at 23-25, Sur-reply at 5-9.
`
`
`
`Brener’s Linking Information is Not the Claimed Account Identifying
`Information
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener’s
`“Linking Information”
`
`Claimed “Account
`Identifying Information”
`
` Relational information
`stored in a Table that maps
`customer object to
`customer’s personal
`information.
`
` Customer’s personal
`information.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`51
`
`POR at 23-25;
`Sur-reply at 5-9.
`
`
`
`Brener’s Bank Acts Like Secure Registry—Not Claimed “Third Party”—
`By Mapping Customer Object to the Customer
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`• Petitioner relies on Brener
`embodiment where bank
`150 serves as “secure
`registry” by using linking
`information to map the
`customer object to the
`customer’s identity to
`access customer’s
`information.
`
`• Claim does not permit
`bank serving as both
`“secure registry” and “third
`party.”
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1001 at Cl. 22;
`see also Cls. 1, 37, 38.
`
`POR at 23-25;
`Sur-reply at 5-9.
`
`52
`
`
`
`Brener’s Shipping Carrier is Not the Claimed “Third Party”
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`Brener:
`
`• Claimed third party must
`“enable or deny” the
`transaction.
`
`• Brener’s shipper merely
`ships the package once
`the transaction has been
`enabled—it has no
`authority to deny the
`transaction.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 14:20-22, FIG. 2.
`
`POR at 22-23;
`Sur-reply at 2-5.
`
`53
`
`
`
`Brener’s Shipping Carrier is Not the Claimed “Third Party”
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`Brener:
`
`• Shipping carrier cannot be
`claimed “third party”
`because Brener’s bank
`has already enabled or
`denied the transaction
`before the shipping carrier
`can get involved.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at 13:25-26, 14:16-22.
`
`POR at 22-23;
`Sur-reply at 2-5.
`
`54
`
`
`
`Brener’s Shipping Carrier is Not the Claimed “Third Party”
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`PTAB:
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Paper 7 (Inst. Dec.) at 16-17.
`
`• At institution stage,
`Petitioner failed to carry
`burden under lower burden
`of proof standard.
`
`• Petitioner has not
`introduced new evidence
`that overcomes this failure
`of proof.
`
`• Shipper cannot be “third
`party” because:
`
`– Brener’s bank already has
`determined whether to
`enable or deny the
`transaction;
`
`– It is not disclosed that
`shipper ever denies the
`transaction.
`POR at 22-23; Sur-reply at 2-5.
`
`55
`
`
`
`Brener’s Shipping Carrier is Not the Claimed “Third Party”
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`Claim 25:
`
`• Claim 25’s recitation that
`the “service includes
`delivery” or that the “third
`party receives the address
`for delivery of an item” is
`consistent with Patent
`Owner’s position that
`Brener’s shipping carrier is
`not the claimed “third
`party” that enables or
`denies the transaction.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1001 at Cl. 25.
`
`Sur-reply at 2-5.
`
`56
`
`
`
`Roadmap
`
`Overview Of ‘539 Patent & Prior Art (Brener, Weiss & Desai)
`
`Limitation 1.1: “time-varying multicharacter code”
`
`Limitation 1.4: “access restrictions”
`
`Limitation 1.6: Secure Registry “providing AII to a third party”
`
`USR’s Substitute Claims Are Patentable
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`57
`
`
`
`USR’s Substitute Claims are Patentable
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`Claim 51 has written description support and is nonobvious
`
`Claims 39, 40, 46, 48, and 52 have written description support
`
`Desai and Pare fail to disclose limitations 39[e] and 47[b]
`
`Brener and Schneier fail to disclose limitations 40[b], 46[c][d]
`
`Brener fails to disclose limitations 52[f][g]
`
`Duty of candor/estoppel
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`58
`
`
`
`USR’s Substitute Claims are Patentable
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`Claim 51 has written description support and is nonobvious
`
`Claims 39, 40, 46, 48, and 52 have written description support
`
`Desai and Pare fail to disclose limitations 39[e] and 47[b]
`
`Brener and Schneier fail to disclose limitations 40[b], 46[c][d]
`
`Brener fails to disclose limitations 52[f][g]
`
`Duty of candor/estoppel
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`59
`
`
`
`Substitute Claim 51
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• The specification
`provides written
`description support for
`Claim 51.
`
`• Brener, Desai, and Weiss
`fail to disclose the
`amendments to Claim
`51.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`60
`
`MTA at A4-A5.
`
`MTA at 2-8; MTA Reply at 3-8, 10.
`
`
`
`Claim 51[b]: ’539 Specification Provides Written Support
`
`“secure data stored…during a training process by establishing
`
`communications between the secure registry and the entities”:
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Specification describes
`that communications are
`established between a
`secure registry and an
`entity during a training
`process to allow the
`entity to store its secure
`data at the secure
`registry.
`
`Ex. 2008 at FIGS. 3, 5.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`MTA at 4-5, 8; MTA Reply at 10.
`
`61
`
`
`
`Claim 51[d]: Specification Provides Written Support
`
`“transaction request received…during a transaction process
`
`initiated after completion of the training process and termination
`
`of communications between the secure registry and the entity”:
`
`ASSERTED PATENT
`
`’267
`
`’812
`
`’598
`
`• Specification provides
`multiple examples of
`transaction processes
`initiated after completion
`of the training process
`when communications
`between the secure
`registry and the entity
`have been terminated.
`
`‘729 Application at FIG. 7, 14:29-15:4.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`MTA at 4-5, 8; MTA Reply at 3-8.
`
`62
`
`
`
`Secure Registry Receiving Time-varying Code from Merchant
`is Not a Communication between Secure Registry and Entity
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`Time-varying
`Code to
`merchant
`
`Entity
`
`Merchant
`
`Secure Registry
`
`Transaction Request
`Message
`
`Transaction Request Message includes store number, sale amount, and time-
`varying code.
`
`• No communication
`between entity and
`secure registry because
`merchant generates new
`message when
`communicating time-
`varying code along with
`other merchant-specific
`and transaction-specific
`values.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`MTA Reply at 3-5.
`
`63
`
`
`
`Secure Registry Receiving Time-varying Code from Merchant is Not
`Communication between Secure Registry and Entity
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Dr. Jakobsson:
`
`• No communication
`between entity and
`secure registry because
`merchant generates new
`message when
`communicating time-
`varying code along with
`other merchant-specific
`and transaction-specific
`values.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`64
`
`Ex. 2011 at ¶29.
`
`MTA Reply at 3-5.
`
`
`
`Brener Teaches Away from Limitation 51[d] Because Customer
`Remains Connected to Secure Provider During Transaction
`
`’267
`
`ASSERTED PATENT
`
`’812
`
`’598
`
`Brener:
`
`• Brener requires that
`customer computer 100
`and secure provider 110
`establish and maintain
`communications via a
`“secure connection
`pipeline” throughout
`transaction process.
`
`• Brener does not
`disclose—nor does
`Petitioner argue—that
`such communications are
`ever terminated while the
`transaction is carried out.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`Ex. 1005 at FIG. 1.
`
`MTA Reply at 11-16.
`
`65
`
`
`
`Customer’s Connection to Secure Provider During Transaction is Vital
`to Maintain Customer’s Anonymity
`
`’267
`
`’812
`
`ASSERTED PATENT
`
`’598
`
`Brener:
`
`• Secure connection
`pipeline and use of
`secure provider’s proxy
`servers are essential to
`maintain customer’s
`anonymity (e.g., address)
`from vendors.
`
`DEMONSTRATIVE EXHIBIT ONLY – NOT EVIDENCE
`
`66
`
`Ex. 1005 at 8:30-9:11.
`
`MTA Reply
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
