`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________________________
`
`VISA INC. and VISA USA, INC.,
`Petitioners,
`
`v.
`
`UNIVERSAL SECURE REGISTRY LLC,
`Patent Owner.
`_____________________________
`
`Case No. IPR2018-01350
`Patent No. 8,856,539
`_____________________________
`
`
`SECOND DECLARATION OF JUSTIN DOUGLAS TYGAR, PH.D.
`
`
`
`
`VISA - EXHIBIT 1021
`Visa Inc. et al. v. Universal Secure Registry LLC
`IPR2018-01350
`
`

`

`
`
`B. 
`
`C. 
`
`TABLE OF CONTENTS
`
`I. 
`SCOPE OF WORK.......................................................................................... 1 
`LEGAL STANDARDS ................................................................................... 2 
`II. 
`III.  USR’S PROPOSED CLAIM AMENDMENTS ............................................. 5 
`IV.  SUBSTITUTE CLAIMS 39-52 OF THE ’539 PATENT LACK
`SUFFICIENT WRITTEN DESCRIPTION SUPPORT ................................ 14 
`A.  USR’s proposed claim limitations 39[c], 48[a], 51[d], and
`52[pre] regarding a lack of communication between the secure
`registry system and the entity lack written description support. .......... 14 
`USR’s proposed claim limitations 46[b] and 52[c] regarding an
`identity of an entity having been verified using a biometric lack
`sufficient written description support. .................................................. 20 
`USR’s proposed claim limitations 40[b] and 46[d] regarding
`mapping the time-varying multicharacter code to an identity of
`the entity using the time-varying multicharacter code and the
`time value lacks sufficient written description support. ....................... 23 
`D.  USR’s proposed claim limitation 51[b] regarding a training
`process by establishing communications between the secure
`registry system and the entities lacks sufficient written
`description support. ............................................................................... 25 
`SUBSTITUTE CLAIMS 39-52 ARE OBVIOUS IN VIEW OF THE
`PRIOR ART ................................................................................................... 27 
`A. 
`The prior art discloses receiving from the provider a transaction
`request ................................................................................................... 29 
`The prior art discloses receiving the transaction request without
`communication or after terminating communications between
`the secure registry system with the entity ............................................. 31 
`The prior art discloses validating an identity of the provider ............... 33 
`The prior art discloses the identity of the entity is verified using
`a biometric ............................................................................................. 34 
`-i-
`
`C. 
`D. 
`
`V. 
`
`B. 
`
`

`

`
`
`E. 
`
`F. 
`
`H. 
`
`G. 
`
`The prior art discloses the transaction request further including a
`time value representative of when the time-varying
`multicharacter code was generated and extracting the time value
`from the transaction request .................................................................. 37 
`The prior art discloses mapping the time-varying multicharacter
`code to an identity of the entity using the time-varying
`multicharacter code and the time value ................................................ 39 
`The prior art discloses the secure data stored at the database
`during a training process by establishing communications
`between the secure registry system and the entities ............................. 42 
`The prior art discloses providing the account identifying
`information to a third party that uses the public ID code to obtain
`the financial account number associated with the entity to enable
`or deny the transaction without providing the account identifying
`information to the provider ................................................................... 44 
`Substitute claim 51 is obvious in view of Brener, Desai, and
`Weiss. .................................................................................................... 47 
`Substitute claims 39, 41-45, and 52 are obvious in view of
`Brener, Desai, Weiss, and Pare. ............................................................ 56 
`Substitute claims 39, 40 and 46-50 are obvious in view of
`Brener, Desai, Schneier, and Pare. ........................................................ 72 
`VI.  THE SUBSTITUTE CLAIMS 39-52 ARE INELIGIBLE UNDER 35
`U.S.C. § 101. .................................................................................................. 86 
`A. 
`Alice Step 1: The Substitute Claims Are Directed to an Abstract
`Idea ........................................................................................................ 87 
`Alice Step 2: The remaining limitations of the substitute claims
`add nothing inventive to the abstract idea. ........................................... 89 
`VII.  THE PROPOSED SUBSTITUTE CLAIMS ARE INDEFINITE ................ 91 
`A. 
`The phrase “for providing information to a provider…without
`providing account identifying information to the provider” is
`indefinite ............................................................................................... 91 
`
`I. 
`
`J. 
`
`K. 
`
`B. 
`
`-ii-
`
`

`

`
`
`B. 
`The added limitations “validate” and “verify” are indefinite. .............. 91 
`VIII.  CONCLUDING STATEMENTS .................................................................. 92 
`APPENDIX A – LIST OF EXHIBITS .................................................................... 93 
`
`
`
`
`
`
`-iii-
`
`

`

`
`
`I, Justin Douglas Tygar, declare as follows:
`
`I.
`
`SCOPE OF WORK
`1.
`I have been retained by Visa Inc. and Visa USA, Inc. (together,
`
`“Visa”) to offer an expert opinion on the validity of certain claims of the ’539
`
`patent. I have previously provided testimony in connection with this matter in the
`
`form of a declaration submitted on July 3, 2018 (Ex-1002) and a deposition taken
`
`on April 19, 2019.
`
`2. My qualifications are set forth in my first declaration, Ex-1002, at
`
`paragraphs 2-10.
`
`3.
`
`Ex-1002 at Appendix A lists the materials I previously reviewed. I
`
`also reviewed and considered various other documents in arriving at my opinions
`
`set forth herein and cite some of them in this declaration. Appendix B lists the
`
`additional documentation that I considered in arriving at my opinions.
`
`4.
`
`5.
`
`Visa pays the consulting firm DOAR $700 per hour for my services.
`
`I previously set forth my understanding and opinions pertaining to a
`
`person of ordinary skill in the art in the relevant field in my first declaration, Ex-
`
`1002, at paragraphs 41-46.
`
`6.
`
`Dr. Jakobsson and I disagree about the appropriate level of skill in the
`
`art. See Ex-2001 at ¶¶14-16; Ex-1002 at ¶¶41-46. In my opinion, the differences
`
`-1-
`
`

`

`
`
`between our definitions have no impact on my analysis, and my opinions are the
`
`same whether Dr. Jakobsson’s or my definition applies.
`
`7.
`
`I previously set forth an overview of the ’539 Patent in my first
`
`declaration (Ex-1002) at ¶¶ 14-24.
`
`II. LEGAL STANDARDS
`8.
`I previously set forth my understanding of pertinent legal standards in
`
`my first declaration (Ex-1002) at ¶¶25-30.
`
`9.
`
`Counsel for Visa has informed me that 35 U.S.C. § 112, first
`
`paragraph requires that a specification contain a written description of the
`
`invention. To satisfy this written description requirement, the specification must
`
`describe the claimed invention in sufficient detail such that one of skill in the art
`
`can reasonably conclude that the inventor had possession of the claimed invention.
`
`10. Counsel for Visa has informed me that if the claims require an
`
`essential or critical feature which is not adequately described in the specification
`
`and which is not conventional in the art or known to one of ordinary skill in the art,
`
`then the written description requirement is not satisfied.
`
`11. Counsel for Visa has informed me that written description support for
`
`claims may be shown in the detailed drawings, which permit a person skilled in the
`
`art to clearly recognize that the applicant had possession of the claimed invention,
`
`or any description of sufficient, relevant, identifying characteristics so long as a
`
`-2-
`
`

`

`
`
`person skilled in the art would recognize that the inventor had possession of the
`
`claimed invention. Counsel for Visa has further informed me that a description
`
`that merely renders the invention obvious does not satisfy the written description
`
`requirement.
`
`12. Counsel for Visa has informed me that 35 U.S.C. §112, second
`
`paragraph requires that the specification shall conclude with one or more claims
`
`particularly pointing out and distinctly claiming the subject matter which the
`
`inventor or a joint inventor regards as the invention. Counsel for Visa has further
`
`informed me that this definiteness requirement means that a patent is invalid for
`
`indefiniteness if its claims, read in light of the specification delineating the patent,
`
`and the prosecution history, fail to inform, with reasonable certainty, those skilled
`
`in the art about the scope of the invention. Counsel for Visa has further informed
`
`me that the definiteness requirement is not satisfied just because some meaning can
`
`be ascribed to the patent’s claims.
`
`13. Counsel for Visa has further informed me that patent claims recite
`
`eligible subject matter under 35 U.S.C. §101. Counsel for Visa has informed me
`
`that laws of nature, abstract ideas, and natural phenomena are not patent eligible.
`
`Counsel for Visa has informed me that an application of an abstract idea, such as a
`
`mathematical formula, may be patent eligible if the patent claims add significantly
`
`more than routine, conventional activity to the underlying concept. Counsel for
`
`-3-
`
`

`

`
`
`Visa has informed me that an important and useful clue to patent eligibility is
`
`whether a claim is tied to a particular machine or apparatus or transforms a
`
`particular article into a different state or thing, and that this is known as the
`
`“machine-or-transformation test.” Counsel for Visa has informed me that the
`
`machine-or-transformation test is not the only test for patent eligibility.
`
`14. Counsel for Visa has informed me that the Supreme Court’s decision
`
`in the Alice Corp. case in 2014 articulates a two-step framework for distinguishing
`
`patents that claim ineligible abstract ideas from those that claim eligible
`
`applications of those ideas. In step one, the court must determine whether the
`
`claims at issue are directed to a patent-ineligible abstract concept. If the claim is
`
`directed to an abstract idea, the analysis proceeds to step two. In step two, counsel
`
`for Visa has informed me that the elements of the claim must be searched, both
`
`individually and as an “ordered combination,” for an “inventive concept”—i.e., an
`
`element or combination of elements that is “sufficient to ensure that the patent in
`
`practice amounts to significantly more than a patent upon the ineligible concept
`
`itself.” Counsel for Visa has informed me that a patentee cannot circumvent the
`
`prohibition on patenting abstract ideas by limiting the idea to “a particular
`
`technological environment,” nor by adding insignificant post-solution activity, or
`
`well-understood, routine, conventional features.
`
`-4-
`
`

`

`
`
`III. USR’S PROPOSED CLAIM AMENDMENTS
`15. Counsel for Visa has informed me that Universal Secure Registry
`
`LLC (“USR”) has filed a motion that proposes substitute claims 39-52 for original
`
`claims 1-4, 9, 16, 21-25, 31, 37, and 38. Counsel for Visa has also informed me
`
`that the USR’s substitute claims are contingent on the Board finding any of the
`
`respective original claims unpatentable.
`
`16.
`
`I have provided the proposed amendments to the claims below. The
`
`underlining reflects newly added text, strike-through reflects deleted text, and the
`
`double brackets reflect substituted text.
`
`39. (Proposed Substitute for Claim 1) A secure registry system for
`providing information to a provider to enable transactions between the
`provider and entities with secure data stored in the secure registry
`system, the secure registry system comprising:
`
`a database including secure data for each entity, wherein each entity is
`associated with a time-varying multicharacter code for each entity
`having secure data in the secure registry system, respectively, each
`time-varying multicharacter code representing an identity of one of
`the respective entities; and
`
`a processor configured to:
`
`receive from the provider 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
`
`-5-
`
`

`

`
`
`requesting the transaction, [[to]]the transaction request received at the
`secure registry system without the secure registry system
`communicating with the entity on whose behalf a transaction is to be
`performed;
`
`map the time-varying multicharacter code to the identity of the entity
`using the time-varying multicharacter code;[[, to]]
`
`validate an identity of the provider and execute a restriction
`mechanism to determine compliance with any access restrictions for
`the provider to secure data of the entity for completing the transaction
`based at least in part on the indication of the provider and the time-
`varying multicharacter code of the transaction request; and[[, and to]]
`
`allow or not allow access to the secure data associated with the entity
`including information required to enable the transaction based on the
`determined compliance with any access restrictions for the provider,
`the information including account identifying information, wherein
`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; and
`
`wherein the identity of the entity is verified using a biometric.
`
`40. (Proposed Substitute for Claim 2) The system of claim 39[[1]],
`wherein the time-varying multicharacter code is provided to the
`system via a secure electronic transmission device, and the transaction
`request includes a time value representative of when the time-varying
`
`-6-
`
`

`

`
`
`multicharacter code was generated; and wherein the processor is
`further configured to:
`
`extract the time value from the transaction request;
`
`map the time-varying multicharacter code to the identity of the entity
`using the time-varying multicharacter code and the time value.
`
`41. (Proposed Substitute for Claim 3) The system of claim 39[[1]],
`wherein the time-varying multicharacter code is encrypted and
`transmitted to the system, and wherein the system is configured to
`decrypt the time-varying multicharacter code with a public key of the
`entity.
`
`42. (Proposed Substitute for Claim 4) The system as claimed in claim
`39[[1]], wherein the transaction includes a service provided by the
`provider, wherein said provider’s service includes delivery, wherein
`the information is an address to which an item is to be delivered to the
`entity, wherein the system receives the time-varying multicharacter
`code, and wherein the system uses the time-varying multicharacter
`code to obtain the appropriate address for delivery of the item by the
`third party.
`
`43. (Proposed Substitute for Claim 9) The system as claimed in claim
`39[[1]], wherein the information includes personal identification
`information regarding the entity.
`
`44. (Proposed Substitute for Claim 16) The system of claim 39[[1]],
`wherein the account identifying information includes an account
`number.
`
`-7-
`
`

`

`
`
`45. (Proposed Substitute for Claim 21) The system of claim 39[[1]],
`wherein the identity of the entity is unknown until the time-varying
`code is mapped to the identity by the processor.
`
`46. (Proposed Substitute for Claim 22) A method for providing
`information to a provider to enable transactions between the provider
`and entities who have secure data stored in a secure registry in which
`each entity is identified by a time-varying multicharacter code, the
`method comprising:
`
`receiving from the provider a transaction request including at least
`the time-varying multicharacter code for an entity on whose behalf a
`transaction is to take place and an indication of the provider
`requesting the transaction, an identity of the entity on whose behalf
`the transaction is to take place having been verified using a biometric
`of the entity, and the transaction request further including a time value
`representative of when the time-varying multicharacter code was
`generated;
`
`extracting the time value from the transaction request;
`
`mapping the time-varying multicharacter code to an identity of the
`entity using the time-varying multicharacter code and the time value;
`
`determining compliance with any access restrictions for the provider
`to secure data of the entity for completing the transaction based at
`least in part on the indication of the provider and the time-varying
`multicharacter code of the transaction request;
`
`-8-
`
`

`

`
`
`accessing information of the entity required to perform the transaction
`based on the determined compliance with any access restrictions for
`the provider, the information including account identifying
`information;
`
`providing the account identifying information to a third party without
`providing the account identifying information to the provider to
`enable or deny the transaction; and
`
`enabling or denying the provider to perform the transaction without
`the provider’s knowledge of the account identifying information.
`
`47. (Proposed Substitute for Claim 23) The method of claim 44[[22]],
`wherein the act of receiving the time-varying multicharacter code
`comprises receiving the time-varying multicharacter code transmitted
`via a secure electronic transmission device, and the method further
`comprises:
`
`prior to determining compliance with any access restrictions for the
`provider, validating an identity of the provider.
`
`48. (Proposed Substitute for Claim 24) The method of claim 44[[22]],
`wherein the transaction request is received at the secure registry
`system without the secure registry system communicating with the
`entity on whose behalf a transaction is to be performed, and the act of
`receiving the time-varying multicharacter code comprises receiving an
`encrypted multicharacter code, and wherein the method further
`comprises decrypting the encrypted multicharacter code.
`
`-9-
`
`

`

`
`
`49. (Proposed Substitute for Claim 25) The method as claimed in
`claim 44[[22]], wherein the transaction includes a service provided by
`the provider, wherein the service includes delivery, wherein the
`account identifying information is associated with an address to which
`an item is to be delivered for the entity, and wherein the third party
`receives the address for delivery of an item provided by the provider.
`
`50. (Proposed Substitute for Claim 31) The method as claimed in
`claim 44[[22]], wherein the act of mapping the time-varying
`multicharacter code to information required by the provider comprises
`mapping the time-varying multicharacter code to personal
`identification information about the entity.
`
`51. (Proposed Substitute for Claim 37) A secure registry system for
`providing information to a provider to enable transactions between the
`provider and entities with secure data stored in the secure registry
`system, the secure registry system comprising:
`
`a database including secure data for each entity, wherein each entity is
`associated with a time-varying multicharacter code for each entity
`having secure data in the secure registry system, respectively, each
`time-varying multicharacter code representing an identity of one of
`the respective entities, wherein the database is configured to permit or
`deny access to information on the respective entity using the time-
`varying multicharacter code, the secure data stored at the database
`during a training process by establishing communications between
`the secure registry system and the entities; and
`
`a processor configured to:
`
`-10-
`
`

`

`
`
`receive from the provider a transaction request including at least the
`time-varying multicharacter code for the entity on whose behalf a
`transaction is to be performed, the transaction request received at the
`secure registry system during a transaction process initiated after
`completion of the training process and termination of
`communications between the secure registry system and the entity on
`whose behalf the transaction is to be performed;, configured to
`
`map the time-varying multicharacter code to the identity of the entity
`to identify the entity;, configured to
`
`execute a restriction mechanism to determine compliance with any
`access restrictions for the provider to at least one portion of secure
`data for completing the transaction and to store an appropriate code
`with each such portion of secure data;, configured to
`
`obtain from the database the secure data associated with the entity
`including information required to enable the transaction, the
`information including account identifying information;, and
`configured to
`
`provide the account identifying information to a third party to enable
`or deny the transaction without providing the account identifying
`information to the provider.
`
`52. (Proposed Substitute for Claim 38) A secure registry system for
`providing information to a provider to enable transactions between the
`provider and entities with secure data stored in the secure registry
`system without establishing and/or maintaining communications
`
`-11-
`
`

`

`
`
`between the secure registry system and an entity on whose behalf a
`transaction is to be performed, the secure registry system comprising:
`
`a database including secure data for each entity, wherein each entity is
`associated with a time-varying multicharacter code for each entity
`having secure data in the secure registry system, respectively, each
`time-varying multicharacter code representing an identity of one of
`the respective entities; and
`
`a processor configured to:
`
`receive from the provider the time-varying multicharacter code for the
`entity on whose behalf a transaction is to be performed, the entity
`having had its identity verified using a biometric;, configured to
`
`map the time-varying multicharacter code to the identity of the entity
`without requiring further information to identify the entity;,
`configured to
`
`access from the database secure data associated with the entity
`including information required to enable the transaction, the
`information including account identifying information that includes a
`public ID code that identifies a financial account number associated
`with the entity; and, and configured to
`
`provide the account identifying information to a third party that uses
`the public ID code to obtain the financial account number associated
`with the entity to enable or deny the transaction without providing the
`account identifying information to the provider;[[,]] and
`
`-12-
`
`

`

`
`
`wherein enabling or denying the transaction without providing
`account identifying information to the provider includes limiting
`transaction information provided by the secure registry system to the
`provider to transaction approval information.
`
`17. The Board construed certain terms as follows in its February 11, 2019
`
`Institution Decision (Paper No. 7). I rely on these constructions, which I list below
`
`for convenience. Any differences between the Board’s construction and my earlier
`
`proposed constructions do not affect my opinions.
`
`Claim Term
`
`Construction
`
`“entity”
`
`No construction necessary
`
`Determining compliance with any
`
`“based at least in part on the
`
`access restrictions for the provider must
`
`indication of the provider and the
`
`be “based at least in part on the
`
`time-varying multicharacter code of
`
`indication of the provider and the time-
`
`the transaction request”
`
`varying multicharacter code of the
`
`transaction request.”
`
`“provider”
`
`No construction necessary
`
`“access restrictions for the provider” No construction necessary
`
`-13-
`
`

`

`
`
`
`18.
`
`It is my understanding that USR does not dispute the construction of
`
`the terms above in its Contingent Motion to Amend.
`
`IV. SUBSTITUTE CLAIMS 39-52 OF THE ’539 PATENT LACK
`SUFFICIENT WRITTEN DESCRIPTION SUPPORT
`19.
`I have evaluated first whether the proposed substitute claims 39-52 are
`
`supported by the specification’s written description. In doing so, I reviewed
`
`USR’s Conditional Motion to Amend and proposed claims, as well as the exhibits
`
`provided, including U.S. Application Numbers 11/768,729 (“’729 Application”) at
`
`Ex-2008 and 09/810,703 (“’703 Application”) at Ex-2009.
`
`20. USR relies upon those two applications as providing written
`
`description support for certain new claim limitations involving a lack of
`
`communication between the entity and the secure registry system; a mapping to the
`
`identity of the entity using the time-varying multicharacter code and the time
`
`value; a verification of the identity of the entity prior to receiving a transaction
`
`request; and a training process by establishing communications between the secure
`
`registry system and multiple entities. In my opinion, the new claims lack support
`
`in four respects, as explained below.
`
`A. USR’s proposed claim limitations 39[c], 48[a], 51[d], and 52[pre]
`regarding a lack of communication between the secure registry
`system and the entity lack written description support.
`21. USR’s proposed claim limitations 39[c] and 48[a] require “the
`
`transaction request received at the secure registry system without the secure
`
`-14-
`
`

`

`
`
`registry system communicating with the entity on whose behalf a transaction is to
`
`be performed.” Similarly, proposed claim limitation 51[d] requires “termination of
`
`communications between the secure registry system and the entity on whose behalf
`
`the transaction is to be performed.” To support limitations 39[c], 48[a], and 51[d],
`
`USR identifies Ex-2008, 11:12-12:11, 12:29-13:21, 14:1-15:9, 16:28-20:15, FIGS.
`
`3, 5, 7-10; and Ex-2009, 11:27-12:28, 13:17-14:10, 14:22-15:31, 17:22-21:13,
`
`FIGS. 3, 5, 7-10. Similarly, proposed claim limitation 52 [pre] requires
`
`“transactions between the provider and entities with secure data stored in the
`
`secure registry system without establishing and/or maintaining communications
`
`between the secure registry system and an entity on whose behalf transaction is to
`
`be performed.” To support limitation 52[pre], USR identifies Ex-2008, 7:25-27,
`
`8:5-16, 11:12-12:11, 12:29-13:26, 14:1-15:9, 16:28-20:15, Cl. 1, FIGS. 1, 3, 5, 7-
`
`10; and Ex-2009, 8:6-8, 8:17-28, 11:27-12:28, 13:17-14:16, 14:22-15:31, 17:22-
`
`21:13, FIGS. 1, 3, 5, 7-10. I have reviewed each of these disclosures.
`
`22.
`
`It is my opinion that the cited priority documents do not disclose a
`
`lack of communication between the secure registry system and the entity while
`
`receiving the transaction request or enabling the transaction as required by USR’s
`
`proposed claim limitations 39[c], 48[a], 51[d], and 52[pre]. The specifications do
`
`not describe or require a lack of communication between the USR system and the
`
`-15-
`
`

`

`
`
`entity while receiving the transaction request or enabling the transaction as
`
`required by the proposed limitations. See Ex-1001, Ex-2008, Ex-2009.
`
`23. Although Dr. Jakobsson argues that “the secure registry system does
`
`not communicate with the entity on whose behalf a transaction is being
`
`performed,” I cannot find any support for his statement in his declaration. See,
`
`e.g., Ex-2010, ¶38. Instead, he broadly cites to Ex-2008, 16:28-20:15, Figs. 7-10
`
`and Ex-2009, 16:28-20:15, Figs. 7-10, in which I did not find any disclosure of a
`
`lack of communication taking place between the entity and the secure registry
`
`system.
`
`24. The cited priority documents describe multiple ways in which the user
`
`communicates with the USR system. See, e.g., Ex-2008 4:10-13 (“For example, in
`
`one embodiment, a smart card such as the SecurID™ card from RSI Security, Inc.
`
`may be provided with the user’s private key and the USR system’s public key to
`
`enable the card to encrypt messages being sent to the USR system and to decrypt
`
`messages from the USR system 10.”); 5:11-21 (“Access to the USR system may be
`
`by smart card, such as a SecurID™ card, or any other secure access device.”); Ex-
`
`2009, 4:20-24, 5:26-31. Instead of teaching a lack of communication between the
`
`secure registry system and the entity, the specification teaches at least three ways
`
`in which the entity communicates with the secure registry system before and
`
`during the transaction process.
`
`-16-
`
`

`

`
`
`25. First, the specification explains that the user communicates with the
`
`secure registry system during the training process when the user enters personal
`
`data into the USR database. Ex-2008, 14:1-21 (“If the person is authorized, the
`
`USR software 18 then enables the person to enter basic personal data into the USR
`
`database 24 (504).”), 14:29-15:1, Fig. 5; Ex-2009, 15:11-12, 15:20-23, Fig. 5.
`
`26. Similarly, the specification discloses communication by the user with
`
`the secure registry system when the user specifies the type of access restrictions set
`
`for the personal data stored in the secure registry system. Ex-2008, 15:1-4 (“For
`
`each type of data entered, the person is asked to specify the type of access
`
`restrictions and/or whom should be allowed to access the advanced personal data
`
`(510). When the person has completed entering data into the database, the process
`
`returns (512) and commits the data to the database.”); Ex-2009, 15:20-26 (same);
`
`see also MTA, 3-4 (“With respect to limitations 39[e] and 47[b], the ’729
`
`Application describes that ‘The process of 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.’”) (citations omitted) (emphasis
`
`added); MTA, Appendix B5, limitation 51[b] (“the secure data stored at the
`
`database during a training process by establishing communications between the
`
`secure registry system and the entities”).
`
`-17-
`
`

`

`
`
`27. Second, the user communicates with the USR system when it verifies
`
`its identity. The specifications of the supporting applications explain that the user
`
`may verify its identity using a biometric via the user’s device:
`
`The identity of the user possessing the identifying device may be
`verified at the point of use via any combination of a memorized PIN
`number or code, biometric identification such as a fingerprint, voice
`print, signature, iris or facial scan, or DNA analysis, or any other
`method of identifying the person possessing the device.
`
`Ex-2008, 5:16-19; Ex-2009, 5:31-6:5 (same). The user’s device must thus
`
`communicate with the USR database during the verification process so that the
`
`biometric information from the user’s device can be verified using the biometric
`
`information stored in the verification area of the USR database:
`
`Likewise, various types of biometric information may be stored in the
`verification area of the database entry to enable the identity of the user
`possessing the identifying device to be verified at the point of use.
`Examples of the type of biometric information that may be used in
`this situation includes a personal identification number (PIN),
`fingerprint, voice print, signature, iris or facial scan, or DNA analysis.
`
`Ex-2008, 12:20-24; Ex-2009, 13:7-11 (same).
`
`28. Similarly, the user must also communicate with the USR system to
`
`provide its time-varying code during the transaction to identify itself. As explained
`
`in the specification, the time-varying multicharacter code is generated by the user’s
`
`-18-
`
`

`

`
`
`device and is communicated from the user’s device to the USR system for
`
`validation:
`
`As shown in FIG. 7, when a user initiates a purchase (700), the user
`enters a secret code in the user's electronic ID device (702) to cause
`the ID device to generate a onetime code or other appropriate code,
`and presents the electronic ID device with the code to the merchant or
`otherwise presents the code to the merchant. The merchant transmits
`to the cred