IPR2018-01351
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`
`VISA INC. and VISA U.S.A. INC.,
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`Patent Owner
`________________
`
`Case IPR2018-01351
`U.S. Patent No. 8,856,539
`________________
`
`
`
`
`
`
`PATENT OWNER’S EXHIBIT 2001
`
`DECLARATION OF MARKUS JAKOBSSON
`
`IN SUPPORT OF PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`USR Exhibit 2001
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`
`VISA INC. and VISA U.S.A. INC.,
`Petitioner,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`Patent Owner
`________________
`
`Case IPR2018-01351
`U.S. Patent No. 8,856,539
`________________
`
`
`
`
`
`
`PATENT OWNER’S EXHIBIT 2001
`
`DECLARATION OF MARKUS JAKOBSSON
`
`IN SUPPORT OF PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`USR Exhibit 2001
`
`
`
`
`
`
`IPR2018-01351
`
`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
`
`Preliminary 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-01351, U.S. Patent No. 8,856,539, and its file history, and all
`
`other materials cited and discussed in the Petition (including the declaration of Dr.
`
`Justin Tygar) and cited and discussed in this Declaration. I understand the Petition
`
`asserts that claims 1-9, 16-31, 37, and 38 are obvious WO 01/13275 A1 (“Junda”)
`
`in view of U.S. Pub. No. 2001/0029485 A1 (“Brody”) under pre-AIA 35 U.S.C. §
`
`103(a) (together “the Challenged Claims”).
`
`3.
`
`The statements made herein are based on 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 2001, Page 1
`
`
`
`IPR2018-01351
`
`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 studies and 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
`
`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 2001, Page 2
`
`
`
`IPR2018-01351
`
`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 the 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 2001, Page 3
`
`
`
`IPR2018-01351
`
`commercializes technology to protect enterprises, their partners and customers
`
`from advanced email phishing attacks. At Agari, my research studied and
`
`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 2001, Page 4
`
`
`
`IPR2018-01351
`
`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 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 2001, Page 5
`
`
`
`• the levels of education and experience of persons working in the
`
`IPR2018-01351
`
`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. Justin Tygar, including his
`
`opinions regarding the Person of Ordinary Skill in the Art. Ex. 1002 at ¶¶ 41-46.
`
`My description of the level of ordinary skill in the art is essentially the same as that
`
`of the Dr. Tygar, except that Dr. Tygar’s 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
`
`in 2001. Regardless if I do not explicitly state that my statements below are based
`
`
`
`
`USR Exhibit 2001, Page 6
`
`
`
`IPR2018-01351
`
`on this 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.
`
`19.
`
`Legal Principles
`
`I am not a lawyer and will not provide any legal opinions.
`
`20. 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
`
`21.
`
`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.
`
`22.
`
`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 2001, Page 7
`
`
`
`IPR2018-01351
`
`23.
`
`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.
`
`24.
`
`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
`
`25.
`
`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.
`
`
`
`
`USR Exhibit 2001, Page 8
`
`
`
`IPR2018-01351
`
`III. OVERVIEW OF THE ’539 PATENT
`
`A. The ’539 Patent Specification
`
`26.
`
`I have reviewed the ’539 patent. The ’539 patent provides a unique
`
`and highly 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 without requiring the entity to share
`
`personal or otherwise sensitive information with the provider. See Ex. 1001 at
`
`2:64-3:1, 3:24-27, 12:19-54. The 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 id. at 3:44-54. As another example, the system allows a
`
`person seeking medical treatment to identify themselves before a medical provider,
`
`and also have the system provide insurance data, medical history data, and other
`
`medical information to the medical provider once the medical provider has
`
`established itself as an authorized recipient. See id. at 3:55-60.
`
`27. Referring to FIGS. 1 and 3 of the ’539 patent, the 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. Id. at 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,
`
`
`
`
`USR Exhibit 2001, Page 9
`
`
`
`IPR2018-01351
`
`address information, credit card information, medical information, job application
`
`information, and/or tax information. Id. at 7:57-63. The validation information 32
`
`is information about the user and is used by the main unit’s software 18 to validate
`
`that the person attempting to access the information is authorized to receive it. Id.
`
`at 8:10-14. In particular, the validation information 32 contains information that
`
`enables the software 18 to validate a person that has presented the system with a
`
`one-time nonpredictable code uniquely associated with the user. See id. at 8:17-35.
`
`The access information 34 allows different levels of security to attach to different
`
`types of information stored in each entry 30 so that the user can specify which
`
`particular individuals or organizations can have access to what specific data (e.g.,
`
`credit card numbers, medical information, and tax information). See id. at 8:62-
`
`9:11.
`
`28. Referring to FIG. 8, one aspect of using the system includes the useful
`
`ability to purchase goods or services from a merchant without revealing to the
`
`merchant account information relating to the user’s credit card. Id. at 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, which generates a one-time nonpredictable code that is
`
`provided to the merchant. Id. at 12:21-24. The merchant in turn may transmit the
`
`one-time nonpredictable code, a store number, and a purchase amount to the secure
`
`
`
`
`USR Exhibit 2001, Page 10
`
`
`
`IPR2018-01351
`
`registry. Id. at 12:24-26. The secure registry system may then determine whether
`
`the code received is valid, and if valid, accesses from the secure registry’s database
`
`24 the user’s actual credit card information. See id. at 12:27-29. The secure registry
`
`system next transmits to the credit card company the credit card number, the store
`
`number, and the purchase amount. Id. at 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. Id. at 12:40-43. The credit card company notifies the secure
`
`registry system the transaction result and the secure registry system may in turn
`
`notify the merchant. Id. at 12:43-46.
`
`29. Thus, the ’539 patent’s 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 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 2001, Page 11
`
`
`
`IPR2018-01351
`
`30. Besides purchase transactions, the technology described in the ’539
`
`patent can be applied to a host of other applications that can benefit from secure
`
`identity verification systems and distributed secure data storage. As one example,
`
`such a system allows a patient to obtain medical treatment from a medical care
`
`provider without having to directly supply the medical care provider her medical
`
`history, which may not be with the patient herself. According to another example,
`
`the user may facilitate shipment of goods purchased from a merchant without
`
`having to provide the merchant their shipping address.
`
`B.
`
`The ’539 Patent Claims
`
`31. The ’539 patent includes 38 claims. Claims 1, 22, 37, and 38 are
`
`independent. I have reviewed the claims in detail.
`
`IV. OVERVIEW OF THE CITED ART
`
`A.
`
`32.
`
`Junda
`
`Junda discusses “a system and a method for enabling a customer… to
`
`make purchases and take delivery of goods or services while keeping some or all
`
`of the user’s personal information confidential and secure throughout the purchase
`
`and delivery transactions.” Ex. 1008, Junda at 3:27-31.
`
`33. FIG. 1 of Junda is instructive of this method and system. The process
`
`begins when “a user 120 registers with the proxy agent 140 for obtaining proxy
`
`user data that he or she can use when making purchases and taking delivery of
`
`goods or services.” Ex. 1008, Junda at 11:11-13. Specifically, the user may have “a
`
`
`
`
`USR Exhibit 2001, Page 12
`
`
`
`IPR2018-01351
`
`credit or debit card for which he or she requests proxy user data.” Id. at 11:26-27.
`
`The user may fill out an electronic form to provide the proxy agent 140 its real
`
`name, shipping address, and email address. Id. at 11:29-33. In the case where the
`
`proxy agent 140 was not the entity that issued the user 120 its credit or debit card
`
`account, the user 120 would also provide the proxy agent 140 its real credit or
`
`debit card number. Id. at 12:33-36. The proxy agent 140 generates proxy user data
`
`corresponding to this data and stores all of this information in its user database
`
`144. See id. at 13:9-33. The proxy agent 140 may then provide the generated proxy
`
`user data to the user 120 for subsequent use by the user 120 with, for example, a
`
`merchant 130. Id. at 13:35-14:2. To reduce the risk that such proxy user data may
`
`be intercepted and used by an “unscrupulous individual,” Junda discusses that the
`
`proxy user data may be “valid for only a limited number of purchases or requiring
`
`the user to make a purchase only within a limited period of time.” Id. at 14:30-33.
`
`34. The user 120 may then take the proxy user data and present it to an
`
`online merchant 130 instead of the real data (e.g., real credit card number) when
`
`desiring to make a purchase. Id. at 15:27-35. The merchant 130 then logs onto an
`
`authorization network 112 to request authorization to charge the user’s credit/debit
`
`card account for the selected purchase. Id. at 16:1-3. The proxy agent 140 receives
`
`the proxy user data, such as the proxy credit/debit card number, from the merchant
`
`130 and—in the case the proxy agent 140 did not issue the underlying credit/debit
`
`
`
`
`USR Exhibit 2001, Page 13
`
`
`
`IPR2018-01351
`
`card account—translates the proxy number to the real credit/debit account number
`
`and forwards the real account number to the card issuer 170 that issued the real
`
`account number. See id. at 16:3-23.
`
`35. The card issuer 170 sends an authorization response authorizing or
`
`denying the transaction to the authorization proxy agent 140 over the authorization
`
`network 112. Id. at 16:25-26. The proxy agent 140 then substitutes out the real
`
`account numbers with the proxy numbers before sending the authorization
`
`information back to the merchant 130. Id. at 16:26-31. The merchant 130 lets the
`
`user 120 know the outcome (approval/denial) of the transaction. See id. at 16:31-
`
`37. In this fashion, “the user 120 is not required to send any real user data to the
`
`merchant 130” and “the proxy agent 140 does not reveal any of the real user data
`
`stored in the user database 144 to the merchant 130.” Id. at 17:1-6.
`
`36.
`
`Junda’s system and method also includes delivery of goods using
`
`proxy user data. For example, not knowing the user’s shipping address, the
`
`merchant 130 sends the goods to a delivery provider 150 that in turn ships the
`
`goods to the user 120. Id. at 18:14-24. Next, the delivery provider visits the proxy
`
`agent site 142 and requests the real user data (e.g., shipping address) corresponding
`
`to the proxy user data provided. Id. at 18:26-28. The proxy agent 140 looks up the
`
`user’s real shipping address based on the proxy data and provides the real shipping
`
`address to the delivery provider 150. Id. at 18:28-32.
`
`
`
`
`USR Exhibit 2001, Page 14
`
`
`
`IPR2018-01351
`
`37.
`
`Junda makes no disclosure that the proxy user data provided to the
`
`user is time-varying or that a restriction mechanism is executed to determine
`
`compliance with any access restrictions for the merchant or delivery provider to
`
`secure data.
`
`B.
`
`Brody
`
`38. Brody discusses an anonymous transaction server (ATS) that
`
`generates pseudo-random credit card attributes, such as a pseudo-random credit
`
`card number, name, billing zip code, or expiration date, which are provided to
`
`consumers for subsequent use with merchants to purchases goods and services
`
`anonymously. See Ex. 1009, Brody at [0009]-[0011]. FIG. 1 of Brody is instructive
`
`of this method and system.
`
`39. Brody’s system first requires a consumer 15 desiring to transact
`
`anonymously with a merchant 10 to communicate with the ATS 20 and provide the
`
`ATS 20 with their real credit card attributes (e.g., real card number, expiration
`
`date, name, etc.). Id. at [0028]. “The ATS stores the consumer’s 15 true credit card
`
`attributes… and maps the consumer’s true credit card attributes to pseudo-random
`
`anonymous credit card attributes provided to the consumer 15 by the ATS 20.” Id.
`
`The pseudo-random card generated includes routing attributes that indicate the
`
`card has been produced by the ATS 20. Id. Armed with the pseudo-random
`
`
`
`
`USR Exhibit 2001, Page 15
`
`
`
`IPR2018-01351
`
`anonymous card (“anonymous card”), the consumer 15 may now purchase goods
`
`and services from a merchant 10 using the anonymous card. Id. at [0029].
`
`40. Upon receipt of the anonymous card information from the consumer
`
`15, the merchant 10 processes the anonymous card the same way it would any
`
`other card because the merchant 10 may not be aware that the card it’s processing
`
`is an anonymous card. See id. “In processing a transaction involving the
`
`anonymous card, the anonymous credit card’s routing attributes will cause the
`
`transaction information to be delivered either directly or indirectly to the ATS 20
`
`for processing.” Id. When the ATS 20 receives the anonymous card information in
`
`connection with a purchase transaction, the ATS 20 verifies that the anonymous
`
`card and transaction satisfy “configuration options” associated with the anonymous
`
`card (e.g., transaction amount is acceptable, card is still active, among others), and
`
`if it does, it looks up and transmits the corresponding real card number to the bank
`
`25 that issued the real card account. Id. The bank 25 then processes the real card
`
`information (e.g., authorize or deny) just like any other card. Id.
`
`V. CLAIM CONSTRUCTION
`
`A.
`
`41.
`
`“Based at least in part on the indication of the provider and the
`time-varying multicharacter code of the transaction request”
`
`I understand that Petitioner argues that 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 read to modify the phrase “completing the
`
`
`
`
`USR Exhibit 2001, Page 16
`
`
`
`IPR2018-01351
`
`transaction” instead of “access restrictions for the provider.” See Petition at 17. I
`
`disagree.
`
`42.
`
`In my opinion 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.” This would be consistent
`
`with the plain language of the claims and in view of the specification.
`
`43. The specification of the ’539 patent explains that 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 at
`
`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 at 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 at 8:62-9:11.
`
`44. The specification further provides that during “training” of the USR
`
`database 24, the user “specif[ies] the type of access restrictions and/or whom
`
`
`
`
`USR Exhibit 2001, Page 17
`
`
`
`IPR2018-01351
`
`should be allowed to access the advanced personal data.” Ex. 1001 at 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 at 10:40-48. Thus, the context of
`
`“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).
`
`45. Therefore, a person of ordinary skill in the art would understand
`
`claims 1 and 22 to 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.
`
`46.
`
`I understand that Petitioner argues that the phrase at issue 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.’” Petition at 17 (citing Ex. 1001, 11:49-65,
`
`12:19-31, 12:55-13:8, 13:35-57). First, each portion of the ’539 patent cited to by
`
`
`
`
`USR Exhibit 2001, Page 18
`
`
`
`IPR2018-01351
`
`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 in my opinion. 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 an indication of the provider and time-varying
`
`multicharacter code. In my view, Petitioner’s argument ignores the portion of the
`
`claim language that specifically make these recitations, and its limiting, improper
`
`interpretation and grammatical manipulations of the claim language runs counter to
`
`the ’539 patent’s specification.
`
`47. For these reasons, a person of ordinary skill in the art would
`
`understand that 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.”
`
`B.
`
`48.
`
`“Provider”
`
`I believe that a person of ordinary skill in the art would understand the
`
`term “provider” as used in the ’539 patent to mean “the party that engages in a
`
`
`
`
`USR Exhibit 2001, Page 19
`
`
`
`IPR2018-01351
`
`transaction with an entity having secure data stored at a secure registry, the party
`
`providing a good or service to the entity and/or requesting information about the
`
`entity.”
`
`49. This construction is consistent with the ’539 patent’s claims, which
`
`recite a “provider” and an “entity” engaging in a transaction. The claims state that
`
`the entity has “secure data stored in a secure registry” and that the provider
`
`“request[s] the transaction.”
`
`50. Turning to the specification and figures, various types of parties, such
`
`as merchants, service providers, medical personnel, potential employers, financial
`
`institutions, delivery service providers, law enforcement, tax agencies, and
`
`potential landlords, may be parties (i.e., providers) that engage in a transaction
`
`with the entity and provide a good (e.g., merchant selling goods), service (e.g.,
`
`merchant selling services, medical personnel rendering aid, etc.) to the entity,
`
`and/or request information (e.g., medical information, tax information, financial
`
`information, identification information, job application or rental application
`
`information, etc.) about the entity. See Ex. 1001 at 7:57-67, 8:62-9:13, FIGS. 3 and
`
`4 (describing various types of secure data of the entity that can be stored at the
`
`secure registry and the various types of provider parties that may request access to
`
`such stored secure data); see id. at 11:46-13:13, FIGS. 7-9 (describing transactions
`
`between merchant providers and entities having secure data stored at secure
`
`
`
`
`USR Exhibit 2001, Page 20
`
`
`
`IPR2018-01351
`
`registry); see id. at 14:4-58, FIG. 11 (describing a delivery service provider
`
`engaging in a delivery transaction with the entity); see id. at 16:17-25, FIG. 14
`
`(describing law enforcement provider requesting identity information pertaining to
`
`the entity); see id. at 16:26-51, FIG. 15 (describing medical service providers,
`
`among others, requesting information pertaining to the entity); see id. at 16:63-
`
`17:5, FIG. 16 (describing a potential employer or landlord that provides
`
`employment or housing requesting information (e.g., data associated with a
`
`job/rental application) from the entity); see id. at 17:6-28 (describing additional
`
`types of providers).
`
`51. Therefore, in my opinion the term “provider” in light of the
`
`specification and ordinary language of the claims should be construed to mean “the
`
`party that engages in a transaction with an entity having secure data stored at a
`
`secure registry, the party providing a good or service to the entity and/or requesting
`
`information about the entity.”
`
`C.
`
`52.
`
`“Access restrictions for the provider”
`
`In my opinion, under the broadest reasonable interpretation standard,
`
`a person of ordinary skill in the art would understand the claim limitation “access
`
`restrictions for the provider” as used in the ’539 patent to mean “access restrictions
`
`that are specific to the provider.” This construction is consistent with the plain and
`
`ordinary meaning of the language as found in the ’539 patent’s claims, which
`
`
`
`
`USR Exhibit 2001, Page 21
`
`
`
`IPR2018-01351
`
`recite t
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
