IPR2018-01350
`
`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 IPR2018-01350
`U.S. Patent No. 8,856,539
`________________
`
`
`
`
`
`PATENT OWNER’S EXHIBIT 2004
`DECLARATION OF DR. MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S RESPONSE
`
`
`
`
`
`
`
`USR Exhibit 2004
`
`
`
`
`
`
`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 IPR2018-01350
`U.S. Patent No. 8,856,539
`________________
`
`
`
`
`
`PATENT OWNER’S EXHIBIT 2004
`DECLARATION OF DR. MARKUS JAKOBSSON
`IN SUPPORT OF PATENT OWNER’S RESPONSE
`
`
`
`
`
`
`
`USR Exhibit 2004
`
`
`
`
`
`
`IPR2018-01350
`
`1.
`
`I have been retained on behalf of Universal Secure Registry LLC
`
`(“Patent Owner”) in connection with the above-captioned inter partes review
`
`(IPR). I have been retained to provide my opinions in support of USR’s Patent
`
`Owner Response. I am being compensated for my time at the rate of $625 per hour.
`
`I have no interest in the outcome of this proceeding.
`
`2.
`
`In preparing this declaration, I have reviewed and am familiar with the
`
`Petition for IPR2018-01350, U.S. Patent No. 8,856,539, (“the ’539 patent”) and its
`
`file history, and all other materials cited and discussed in the Petition (including
`
`the declaration of Douglas Tygar, Ph.D) and cited and discussed in this
`
`Declaration. I understand the Petition proffers one invalidity ground for the ’539
`
`patent (Ex. 1001): (1) Claims 1-9, 16-31, 37 and 38 are allegedly obvious over
`
`WO 00/14648 (“Brener”) (Ex. 1005), U.S. Patent No. 4,885,778 (“Weiss”) (Ex.
`
`1006) and U.S. Patent No. 6,820,204 B1 (“Desai”) (Ex. 1007).
`
`3.
`
`The statements made herein are based upon my own knowledge and
`
`opinion. This Declaration represents only the opinions I have formed to date. I may
`
`consider additional documents as they become available or other documents that
`
`are necessary to form my opinions. I reserve the right to revise, supplement, or
`
`amend my opinions based on new information and on my continuing analysis.
`
`
`
`
`USR Exhibit 2004, Page 1
`
`
`
`IPR2018-01350
`
`I.
`
`QUALIFICATIONS
`
`4. My qualifications can be found in my Curriculum Vitae, which
`
`includes my detailed employment background, professional experience, and list of
`
`technical publications and patents. Ex. 2002.
`
`5.
`
`I am currently the Chief of Security and Data Analytics at Amber
`
`Solutions, Inc., a cybersecurity company that develops home and office automation
`
`technology. At Amber, my research addresses abuse, including social engineering,
`
`malware and privacy intrusions. My work primarily involves identifying risks,
`
`developing protocols and user experiences, and evaluating the security of proposed
`
`approaches.
`
`6.
`
`I received a Master of Science degree in Computer Engineering from
`
`the Lund Instituted of Technology in Sweden in 1993, a Master of Science degree
`
`in Computer Science from the University of California at San Diego in 1994, and a
`
`Ph.D. in Computer Science from the University of California at San Diego in 1997,
`
`specializing in Cryptography. During and after my Ph.D. studies, I was also a
`
`Researcher at the San Diego Supercomputer Center, where I did research on
`
`electronic payment schemes, authentication and privacy.
`
`7.
`
`From 1997 to 2001, I was a Member of Technical Staff at Bell Labs,
`
`where I did research on authentication, privacy, multi-party computation, contract
`
`exchange, digital commerce including crypto payments, and fraud detection and
`
`
`
`
`USR Exhibit 2004, Page 2
`
`
`
`IPR2018-01350
`
`prevention. From 2001 to 2004, I was a Principal Research Scientist at RSA Labs,
`
`where I worked on predicting future fraud scenarios in commerce and
`
`authentication and developed solutions to those problems. During that time I
`
`predicted the rise of what later became known as phishing. I was also an Adjunct
`
`Associate Professor in the Computer Science department at New York University
`
`from 2002 to 2004, where I taught cryptographic protocols.
`
`8.
`
`From 2004 to 2016, I held a faculty position at Indiana University at
`
`Bloomington, first as an Associate Professor of Computer Science, Associate
`
`Professor of Informatics, Associate Professor of Cognitive Science, and Associate
`
`Director of the Center for Applied Cybersecurity Research (CACR) from 2004 to
`
`2008; and then as an Adjunct Associate Professor from 2008 to 2016. I was the
`
`most senior security researcher at Indiana University, where I built a research
`
`group focused on online fraud and countermeasures, resulting in over 50
`
`publications and two books.
`
`9. While a professor at Indiana University, I was also employed by
`
`Xerox PARC, PayPal, and Qualcomm to provide thought leadership to their
`
`security groups. I was a Principal Scientist at Xerox PARC from 2008 to 2010, a
`
`Director and Principal Scientist of Consumer Security at PayPal from 2010 to
`
`2013, a Senior Director at Qualcomm from 2013 to 2015, and Chief Scientist at
`
`Agari from 2016 to 2018. Agari is a cybersecurity company that develops and
`
`
`
`
`USR Exhibit 2004, Page 3
`
`
`
`IPR2018-01350
`
`commercializes technology to protect enterprises, their partners and customers
`
`from advanced email phishing attacks. At Agari, my research addressed trends in
`
`online fraud, especially as related to email, including problems such as Business
`
`Email Compromise, Ransomware, and other abuses based on social engineering
`
`and identity deception. My work primarily involved identifying trends in fraud and
`
`computing before they affected the market, and developing and testing
`
`countermeasures, including technological countermeasures, user interaction and
`
`education.
`
`10.
`
`I have founded or co-founded several successful computer security
`
`companies. In 2005 I founded RavenWhite Security, a provider of authentication
`
`solutions, and I am currently its Chief Technical Officer. In 2007 I founded
`
`Extricatus, one of the first companies to address consumer security education. In
`
`2009 I founded FatSkunk, a provider of mobile malware detection software; I
`
`served as Chief Technical Officer of FatSkunk from 2009 to 2013, when FatSkunk
`
`was acquired by Qualcomm and I became a Qualcomm employee. In 2013 I
`
`founded ZapFraud, a provider of anti-scam technology addressing Business Email
`
`Compromise, and I am currently its Chief Technical Officer. In 2014 I founded
`
`RightQuestion, a security consulting company.
`
`11.
`
`I have additionally served as a member of the fraud advisory board at
`
`LifeLock (an identity theft protection company); a member of the technical
`
`
`
`
`USR Exhibit 2004, Page 4
`
`
`
`IPR2018-01350
`
`advisory board at CellFony (a mobile security company); a member of the
`
`technical advisory board at PopGiro (a user reputation company); a member of the
`
`technical advisory board at MobiSocial dba Omlet (a social networking company);
`
`and a member of the technical advisory board at Stealth Security (an anti-fraud
`
`company). I have provided anti-fraud consulting to KommuneData (a Danish
`
`government entity), J.P. Morgan Chase, PayPal, Boku, and Western Union.
`
`12.
`
`I have authored five books and over 100 peer-reviewed publications,
`
`and have been a named inventor on over 100 patents and patent applications.
`
`13. My work has included research in the area of electronic payments,
`
`applied security, privacy, cryptographic protocols, authentication, malware, social
`
`engineering, usability and fraud.
`
`II. LEGAL UNDERSTANDING
`
`A. The Person of Ordinary Skill in the Art
`
`14.
`
`I understand that a person of ordinary skill in the relevant art (also
`
`referred to herein as “POSITA”) is presumed to be aware of all pertinent art, thinks
`
`along conventional wisdom in the art, and is a person of ordinary creativity—not
`
`an automaton.
`
`15.
`
`I have been asked to consider the level of ordinary skill in the field
`
`that someone would have had at the time the claimed invention was made. In
`
`deciding the level of ordinary skill, I considered the following:
`
`
`
`
`USR Exhibit 2004, Page 5
`
`
`
` the levels of education and experience of persons working in the
`
`IPR2018-01350
`
`field;
`
` the types of problems encountered in the field; and
`
` the sophistication of the technology.
`
`16. A person of ordinary skill in the art relevant to the ’539 patent at the
`
`time of the invention would have a Bachelor of Science degree in electrical
`
`engineering and/or computer science, and three years of work or research
`
`experience in the fields of secure transactions and encryption, or a Master’s degree
`
`in electrical engineering and/or computer science and two years of work or
`
`research experience in related fields.
`
`17.
`
`I have reviewed the declaration of Dr. Tygar, including his opinions
`
`regarding the Person of Ordinary Skill in the Art. My description of the level of
`
`ordinary skill in the art is essentially the same as that of the Dr. Tygar, except that
`
`his description requires two years of work or research experience (as compared to
`
`three years). The opinions set forth in this Declaration response would be the same
`
`under either my or Dr. Tygar’s proposal.
`
`18.
`
`I am well-qualified to determine the level of ordinary skill in the art
`
`and am personally familiar with the technology of the ’539 Patent. I was a person
`
`of at least ordinary skill in the art at the time of the priority date of the ’539 patent.
`
`Regardless if I do not explicitly state that my statements below are based on this
`
`
`
`
`USR Exhibit 2004, Page 6
`
`
`
`IPR2018-01350
`
`timeframe, all of my statements are to be understood as a POSITA would have
`
`understood something as of the priority date of the ’539 patent.
`
`B.
`
`Legal Principles
`
`19.
`
`I am not a lawyer and will not provide any legal opinions. Though I
`
`am not a lawyer, I have been advised that certain legal standards are to be applied
`
`by technical experts in forming opinions regarding the meaning and validity of
`
`patent claims.
`
`1. Obviousness
`
`20.
`
`I understand that to obtain a patent, a claimed invention must have, as
`
`of the priority date, been nonobvious in view of prior art in the field. I understand
`
`that an invention is obvious when the differences between the subject matter
`
`sought to be patented and the prior art are such that the subject matter as a whole
`
`would have been obvious at the time the invention was made to a person having
`
`ordinary skill in the art.
`
`21.
`
`I understand that to prove that prior art, or a combination of prior art,
`
`renders a patent obvious, it is necessary to: (1) identify the particular references
`
`that singly, or in combination, make the patent obvious; (2) specifically identify
`
`which elements of the patent claim appear in each of the asserted references; and
`
`(3) explain how the prior art references could have been combined to create the
`
`inventions claimed in the asserted claim.
`
`
`
`
`USR Exhibit 2004, Page 7
`
`
`
`IPR2018-01350
`
`22.
`
`I understand that a patent composed of several elements is not proved
`
`obvious merely by demonstrating that each of its elements was, independently,
`
`known in the prior art, and that obviousness cannot be based on the hindsight
`
`combination of components selectively culled from the prior art to fit the
`
`parameters of the patented invention.
`
`23.
`
`I also understand that a reference may be said to teach away when a
`
`person of ordinary skill, upon reading the reference, would be discouraged from
`
`following the path set out in the reference, or would be led in a direction divergent
`
`from the path that was taken by the applicant. Even if a reference is not found to
`
`teach away, I understand its statements regarding preferences are relevant to a
`
`finding regarding whether a skilled artisan would be motivated to combine that
`
`reference with another reference.
`
`2. My Understanding of Claim Construction Law
`
`24.
`
`I understand that in this inter partes review the claims must be given
`
`their broadest reasonable interpretation, but that interpretation must be consistent
`
`with the patent specification. In this Declaration, I have used the broadest
`
`reasonable interpretation (“BRI”) standard when interpreting the claim terms.
`
`III. OVERVIEW OF THE ’539 PATENT
`
`A. The ’539 Patent Specification
`
`25. The ’539 patent provides a unique and highly secure anonymous
`
`
`
`
`USR Exhibit 2004, Page 8
`
`
`
`IPR2018-01350
`
`identification system that uses a time-varying multicharacter code for both
`
`verifying the identity of an entity and enabling transactions between the entity and
`
`a provider without requiring the entity to share personal or otherwise sensitive
`
`information with the provider. See Ex-1001, ’539 patent, 2:64-3:1, 3:24-27, 12:19-
`
`54. As one example, the system, referred to as a Universal Secure Registry (USR)
`
`system, allows a person to purchase goods from a brick and mortar or online
`
`merchant without publicly providing credit card information to the merchant for
`
`fear that the credit card information may be stolen or used fraudulently. See Ex-
`
`1001, ’539 patent, 3:44-54.
`
`26. FIG. 1 depicts one embodiment of the USR system. The USR
`
`system’s main unit 12, which may be connected to a wide area network, includes a
`
`database 24 that stores data entries 30 related to different people or entities. Ex-
`
`1001, ’539 patent, 7:11-13; 7:40-41. Each entry 30 may contain different types of
`
`information such as, but not limited to, validation information, access information,
`
`publicly available information, address information, credit card information,
`
`medical information, job application information, and/or tax information. Ex-
`
`1001, ’539 patent, 7:57-63. “The validation information [32] is information about
`
`the user of the database to whom the data pertains and is to be used by the USR
`
`software 18 to validate that the person attempting to access the information is the
`
`person to whom the data pertains or is otherwise authorized to receive it.” Ex-
`
`
`
`
`USR Exhibit 2004, Page 9
`
`
`
`IPR2018-01350
`
`1001, ’539 patent, 8:10-14. In particular, the validation information 32 contains
`
`information that enables the USR software 18 to validate a person that has
`
`presented the system with a one-time nonpredictable code uniquely associated with
`
`the user. See Ex-1001, ’539 patent, 8:17-35. The access information 34 allows
`
`“different levels of security to attach to different types of information stored in the
`
`entry 30” so that the user can specify which particular individuals or companies
`
`can have access to what specific data such as credit card numbers, medical
`
`information, and tax information. See Ex-1001, ’539 patent, 8:62-9:11. As such,
`
`the USR system may execute a restriction mechanism to determine compliance
`
`with any access restrictions for the provider to secure data of the user.
`
`27. FIG. 8 depicts an embodiment of using the USR system “to purchase
`
`goods or services from a merchant without revealing to the merchant account
`
`information relating to the person’s bank or credit card.” Ex-1001, ’539 patent,
`
`9:46-50. A user desiring to make a purchase at a merchant without providing their
`
`financial information, such as a credit or debit card number, may enter a secret
`
`code into their electronic ID device (any type of electronic device that may be used
`
`to obtain access to the USR database (Ex-1001, ’539 patent, 8:45-47)), which
`
`generates a one-time nonpredictable code that is provided to the merchant. Id.,
`
`12:21-24. The merchant in turn may transmit the one-time nonpredictable code, a
`
`store number, and a purchase amount to the USR. Ex-1001, ’539 patent, 12:24-26.
`
`
`
`
`USR Exhibit 2004, Page 10
`
`
`
`IPR2018-01350
`
`The USR may then determine whether the code received is valid, and if valid,
`
`accesses from the USR database the user’s actual credit card information. Ex-
`
`1001, ’539 patent, 12:27-29. The USR next transmits to the credit card company
`
`the credit card number, the store number, and the purchase amount. Ex-1001, ’539
`
`patent, 12:29-31. The credit card company then processes the transaction, such as
`
`by checking the credit worthiness of the person, and either declines the card or
`
`debits the user’s account and transfers money to the merchant’s account. Ex-1001,
`
`’539 patent, 12:40-43. The credit card company notifies the USR the transaction
`
`result and the USR may in turn notify the merchant. Ex-1001, ’539 patent, 12:43-
`
`46.
`
`28. Hence, the USR system provides a secure anonymous identification
`
`system that uses a time-varying multicharacter code for both verifying the identity
`
`of an entity and also enabling transactions between the entity and a provider, such
`
`as a merchant, without requiring the entity to share personal or otherwise sensitive
`
`information with the provider. In one case, this allows a user to purchase goods or
`
`services from a merchant without providing the merchant the user’s credit card
`
`number. Advantageously, the USR system also allows such secure transactions to
`
`be transparent to the credit card company and thus requires no or minimal
`
`cooperation from the credit card company to implement.
`
`
`
`
`USR Exhibit 2004, Page 11
`
`
`
`IPR2018-01350
`
`B.
`
`The ’539 Patent Claims
`
`29. The ’539 patent has four independent claims: 1, 22, 37 and 38. All of
`
`the claims relate to communicating authentication information from an electronic
`
`ID device.
`
`IV. OVERVIEW OF CITED ART
`
`A. Brener (Ex. 1005)
`
`30. Brener is directed to a centralized system that generates and
`
`distributes static objects to a vendor that allow for anonymous shopping. Brener
`
`emphasizes that a goal of its invention is “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.”
`
`Ex-1005, Brener, 2:15-17.
`
`31. To accomplish this goal, Brener touts that the “customer object” (i.e.,
`
`screen name persona like “GOLFO”) it uses to act as a proxy for the
`
`user/purchaser’s real identity can be remembered by the vendor (e.g., using
`
`cookies) so the vendor may “develop a relationship with the customer through his
`
`persona” and promote goods/services that the vendor may believe the customer
`
`would be interested in based on prior purchases/site visits. Ex-1005, Brener, 12:7-
`
`20.
`
`32.
`
`In particular, Brener teaches its’ customer object comprises a
`
`public/private key pair wherein the public key includes the user’s account number.
`
`USR Exhibit 2004, Page 12
`
`
`
`
`IPR2018-01350
`
`Ex-1005, Brener, 16:8-9 (“The public key will contain information such as a
`
`customer object and a customer bank account or credit card number.”). And,
`
`Brener further teaches that the public key is sent to the vendor 140. Id., 16:15-16
`
`(“When a customer computer 100 enters the web site of the vendor computer 140,
`
`the vendor computer 140 is provided with the public key.”).
`
`33. Brener also discloses that in a preferred embodiment the bank
`
`computer 150 keeps a blind eye to “the transactional information of the customer”
`
`and that “the bank need not know what is being purchased and from where, only
`
`that the customer has the money or credit to cover the transaction.” Ex-1005,
`
`Brener, 13:26-14:4 (emphasis added)
`
`B. Weiss (Ex. 1006)
`
`34. Weiss is directed to a code-generation system that synchronizes
`
`generation of separate, free running, time dependent equipment. Ex-1006, Weiss,
`
`Title. In particular, Weiss discloses a distribution architecture that includes the
`
`capability of every system participant to generate the same authentication code at
`
`the same time. Ex-1006, Weiss, Abstract. Most importantly, the invention uses 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.” Ex-1006, Weiss, 1:63-65. Moreover,
`
`
`
`
`USR Exhibit 2004, Page 13
`
`
`
`Weiss requires the algorithm that generates the authentication code to be secret.
`
`IPR2018-01350
`
`Ex-1006, Weiss, Abstract, line 3.
`
`C. Desai (Ex. 1007)
`
`35. 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.” Ex-1007, Desai, Abstract, lines 1-3 (emphasis
`
`added). Specifically, Desai teaches providing user-by-user and element-by-
`
`element restrictions to data. Ex-1007, Desai, Abstract, lines 17-21 (“Each
`
`registered user may selectively control the granting and denying of access to each
`
`of its associated data elements by other respective user, on an element-by-element,
`
`and user-by-user basis.”); see id., 3:38-40 (“Each user of the system and method
`
`has granular control over its own user profile information, and can control access
`
`to each stored data element”). Moreover, in Desai, the stored information is
`
`released directly to the vendor once the vendor establishes that it has the proper
`
`permissions. Ex-1007, Desai, 4:16-18 (“the vendors will not receive this
`
`information unless and until the registered user provides access to the vendor.”).
`
`V. CLAIM CONSTRUCTION
`
`A.
`
`“Based at least in part on the indication of the provider and the
`time-varying multicharacter code of the transaction request”
`
`36.
`
`I understand that Petitioner argues the phrase “based at least in part on
`
`the indication of the provider and the time-varying multicharacter code of the
`
`
`
`
`USR Exhibit 2004, Page 14
`
`
`
`IPR2018-01350
`
`transaction request” should be read to modify the terms “completing the
`
`transaction” instead of “access restrictions for the provider.” See Pet., 17.
`
`37. Consistent with the plain language of the claims and in view of the
`
`specification, the phrase “based at least in part on the indication of the provider and
`
`the time-varying multicharacter code of the transaction request” should be
`
`construed to modify “determining compliance with any access restrictions for the
`
`provider to secure data of the entity.”
`
`38.
`
`In particular, the specification of the ’539 patent explains that the
`
`USR system’s main unit 12, which may be connected to a wide area network, and
`
`include a database 24 that stores data entries 30 related to different people or
`
`entities. Ex-1001, ’539 patent, 7:11-13; 7:40-41. Among other things, each
`
`database entry 30 may contain “access information 34” and certain pieces of data
`
`such as “Credit Card and Other Financial Information,” “Medical Information,”
`
`Job Application Information,” and “Tax Information.” Ex-1001, ’539 patent, FIG.
`
`3, 7:57-63. The access information 34 allows “different levels of security to attach
`
`to different types of information stored in the entry 30” so that the user can specify
`
`which particular individuals or companies can have access to what specific data
`
`such as credit card numbers, medical information, and tax information. See Ex-
`
`1001, ’539 patent, 8:62-9:11.
`
`
`
`
`USR Exhibit 2004, Page 15
`
`
`
`IPR2018-01350
`
`39. The specification further provides that during “training” of the USR
`
`database 24, the user “specif[ies] the type of access restrictions and/or whom
`
`should be allowed to access the advanced personal data.” Ex-1001, ’539 patent,
`
`10:23-25. Referring to FIG. 6 of the ’539 patent, once the database 24 has been
`
`trained, “USR software 18 queries whether the requester has the right to
`
`access the type of requested data,” and “determining the requestor’s rights
`
`(602) typically involves validating the requestor’s identity and correlating the
`
`identity, the requested information and the access information 34 provided by
`
`the person to the USR database during the training process.” Ex-1001. ’539
`
`patent, 10:40-48 (emphasis added). Thus, the context that “access rights” and
`
`compliance therewith is discussed in the specification and figures of the ’539
`
`patent explicitly ties in the identity of the requestor (e.g., provider).
`
`40. As such, claims 1 and 22 specify that compliance with any access
`
`restrictions for the provider to secure data of the entity for completing the
`
`transaction are based at least in part on the indication of the provider (i.e., who the
`
`requesting provider is) and the time-varying multicharacter code.
`
`41.
`
`I understand that Petitioner argues the phrase should only modify
`
`“completing the transaction” because some embodiments of the ’539 patent
`
`allegedly describe access to information “based solely on a determination whether
`
`‘the [electronic ID] code is valid.’” Pet., 17. I disagree.
`
`
`
`
`USR Exhibit 2004, Page 16
`
`
`
`IPR2018-01350
`
`42. First, each portion of the ’539 patent cited by Petitioner explicitly
`
`recites that the provider’s request includes a store number (i.e., one example of
`
`“indication of the provider”) before the transaction is approved or denied. Thus,
`
`Petitioner’s statement that these embodiments associated with FIGS. 7-10 are
`
`“based solely on a determination whether the ‘the [electronic ID] code is valid’”
`
`lacks merit.
`
`43. Second, even if embodiments in the ’539 patent did not require an
`
`indication of the provider to be sent, the claims at issue recite and require that an
`
`indication of the provider is provided and that compliance with access restrictions
`
`is based on such an indication of the provider and time-varying multicharacter
`
`code. Petitioner’s argument ignores the portion of the claim language that
`
`specifically makes these recitations, and its limiting, improper interpretation and
`
`grammatical manipulations of the claim language runs counter to the ’539 patent’s
`
`specification.
`
`44. For these reasons, proper construction of the phrase “based at least in
`
`part on the indication of the provider and the time-varying multicharacter code of
`
`the transaction request” should be construed to modify the terms “determining
`
`compliance with any access restrictions for the provider to secure data of the
`
`entity.”
`
`
`
`
`USR Exhibit 2004, Page 17
`
`
`
`IPR2018-01350
`
`B.
`
`“Third party”
`
`45. The ’539 patent includes four independent claims 1, 22, 37, and 38,
`
`which all recite the term “the third party.” Consistent with the context of the
`
`claims in which they appear, “third party” should be construed to mean “a party
`
`other than the entity, the provider, and the secure registry.”
`
`46. Such construction is supported by the context of the claims in which
`
`the term “third party” appears. All of the Challenged Claims already recite “a
`
`secure registry,” “a provider,” and “an entity.” Ex-1001, ’539 patent, 18:29-60
`
`(claim 1); 20:4-31 (claim 22); 21:25-22:13 (claim 37); 22:14-40 (claim 38). Thus,
`
`the “third party” should reasonably be interpreted to be a party other than one of
`
`these other parties already recited in the claims otherwise two or more of these
`
`terms would be duplicative.
`
`47. Moreover, my construction is consistent with the specification, where
`
`the third party to whom account identifying information, such as a credit card or
`
`bank account number, is sent to is a party that is not the user entity, provider, or the
`
`secure registry. For example, FIGS. 7, 8, and 9, and the corresponding written
`
`description, all describe how the secure registry accesses and then transmits the
`
`user’s credit card or bank account number to the credit card company (CCC) or
`
`bank, respectively. Ex-1101, ’539 patent, 11:61-65; 12:29-31; 13:3-7; FIG. 7
`
`(708); FIG. 8 (808); FIG. 9 (908). The examples described with respect to FIGS.
`
`
`
`
`USR Exhibit 2004, Page 18
`
`
`
`IPR2018-01350
`
`7, 8, and 9 also include a user entity, a provider (a merchant in the given
`
`examples), and a secure registry that perform different functions from the CCC or
`
`bank. See id., FIGS. 7-9. Thus, in these examples neither the CCC nor the bank is
`
`the user entity, the provider, or the secure registry, and instead the CCC and the
`
`bank are separate parties that receive the account identifying information from the
`
`secure registry. See id.
`
`C.
`
`“The Provider Requesting The Transaction” (Claims 1 and 22)
`
`48.
`
`Independent claims 1 and 22 each require the secure registry system
`
`to receive a transaction request that includes an indication of “the provider
`
`requesting the transaction.” I maintain that “the provider requesting the
`
`transaction” should be construed to mean “the provider that sent the transaction
`
`request.”
`
`49.
`
`Indeed, the plain language of the claims strongly supports my
`
`construction. For example, the claims recite that the secure registry “receive[s] a
`
`transaction request” that indicates “the provider requesting the transaction”:
`
`a processor configured to receive a transaction request including at
`
`least the time-varying multicharacter code for the entity on whose
`
`behalf a transaction is to be performed and an indication of the
`
`provider requesting the transaction.
`
`Ex-1101, ‘539 patent, 18:38-44 (Claim 1), 20:9-14 (Claim 22). One skilled in the
`
`art would understand that the provider requests the transaction by sending a
`
`
`
`
`USR Exhibit 2004, Page 19
`
`
`
`IPR2018-01350
`
`transaction request. Thus, one skilled in the art would understand that the provider
`
`requesting the transaction refers to the provider that sent the transaction request.
`
`50. Other claim language confirms my construction. For example, both
`
`claims 1 and 22 recite that the secure registry enables a transaction between a
`
`“provider” and an “entity.” Ex-1001, ’539 patent, 18:28-33 (Claim 1), 22:4-8
`
`(Claim 22). The claims identity the “entity” as the party on whose “behalf” the
`
`transaction is requested and the “provider” as the party “requesting the
`
`transaction.” Ex-1001, ’539 patent, 18:38-44 (Claim 1), 20:9-14 (Claim 22). This
`
`language further confirms the provider is not merely a party that desires to have the
`
`transaction completed on its behalf, but rather the provider is the party that makes
`
`the transaction request.
`
`51. The specification also consistently discloses that the provider (e.g., a
`
`merchant) sends the claimed transaction request. For example, FIGS. 7-10, and the
`
`corresponding written description, all disclose that the merchant sends a
`
`transaction request that includes a time-varying code from the electronic ID device
`
`and an indication of the merchant sending the transaction request. See, e.g., Ex-
`
`1001,’539 patent, 11:56-65 (“merchant transmit… (1) the code from the electronic
`
`ID device, (2) the store number”), 12:24-26 (same), 12:62-13:2 (same), 13:35-40
`
`(same); see also id., Figs. 7-10 (steps 704, 804, 904, 1002). Thus, the
`
`
`
`
`USR Exhibit 2004, Page 20
`
`
`
`IPR2018-01350
`
`specification, like the claim language confirms that the provider requesting the
`
`transaction is the provider that sent the transaction request.
`
`VI. PETITION’S ARGUMENTS: BRENER, WEISS AND DESAI
`
`52.
`
`I understand that the Petition alleges the Challenged Claims are
`
`obvious over Brener in light of Weiss and Desai. I disagree.
`
`A. The Petition Has Failed To Prove Brener Discloses Limitation 1.6
`
`53. Limitation 1.6 recites “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.” Ex-1001, ’539 patent, Cl. 1.
`
`54.
`
`I understand that the Petition alleges Brener discloses Limitation 1.6.
`
`However, to a POSITA, neither cited section of Brener disclose Limitation 1.6.
`
`55. First, I understand that Petitioner argues Brener teaches that a
`
`shipping carrier can be the claimed “third party” as required by Limitation 1.6.
`
`Pet., 39-40. However, the problem with Petitioner’s argument is that the
`
`transaction has already been approved and enabled by the time the shipping
`
`carrier 180 gets involved by receiving the account identifying information. E.g.,
`
`Ex-1005, Brener, 10:3-20 (“Once a purchase by the customer has been approved,
`
`the vendor arranges for the package to be picked up by a third party carrier.”)
`
`(emphasis added). Thus, the shipping carrier does not “enable or deny the
`
`
`
`
`USR Exhibit 2004, Page 21
`
`
`
`IPR2018-01350
`
`transaction with the provider” after it receives the account identifying information,
`
`as required by the claims, and instead receives the alleged account identifying
`
`information (e.g., shipping address) after the transaction has already been
`
`approved by the provider. Id.
`
`56. Second, at p. 39, Petitioner cites the following portion of Brener as
`
`teaching Limitation 1.6:
`
`To facilitate the verification process, the vendor computer 140
`
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
