(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2011/0138450 A1
`Kesanupalli et al.
`(43) Pub. Date:
`Jun. 9, 2011
`
`US 2011 01384.50A1
`
`(54) SECURE TRANSACTION SYSTEMS AND
`METHODS USING USER AUTHENTCATING
`BOMETRIC INFORMATION
`(75) Inventors:
`Ramesh Kesanupalli, San Jose, CA
`(US); Davit Baghdasaryan,
`Fremont, CA (US); Frank Schwab,
`Phoenix, AZ (US); Philip Yiu
`Kwong Chan, Fremont, CA (US);
`Larry Hattery, Beaverton, OR
`(US)
`Validity Sensors, Inc., San Jose,
`CA (US)
`12/793,499
`Jun. 3, 2010
`Related U.S. Application Data
`(60) Provisional application No. 61/249,218, filed on Oct.
`6, 2009, provisional application No. 61/292.820, filed
`on Jan. 6, 2010.
`
`(21) Appl. No.:
`(22) Filed:
`
`(73) Assignee:
`
`Publication Classification
`
`(51) Int. Cl.
`H04L 9/32
`G06F2L/00
`
`(2006.01)
`(2006.01)
`
`(52) U.S. Cl. ............................................................ T26/7
`
`ABSTRACT
`(57)
`A user transaction request is received at a client device. A web
`browser plug-in communicates the user transaction request to
`a server that determines whether the user transaction request
`is a secure transaction. Transaction data is received from the
`server via the web browser plug-in. If the received transaction
`data indicates a secure transaction, the user is prompted to
`provide biometric data from a user using a biometric device
`and related security protocols. The web browser plug-in then
`communicates a transaction confirmation to the server.
`
`- 10
`
`114
`
`
`
`
`
`
`
`116
`
`MR. JONES,
`YOU ARE ABOUT TO SEND
`$5000 TOJOHN SMITH.
`
`
`
`PLEASE SWPE YOUR FINGERTO
`CONFIRM THISTRANSACTION.
`
`TRANSACTION
`DETALS
`
`AGENT
`APPLICATION
`
`VERIFY
`SIGNATURE
`OF APPLICATION
`
`
`
`
`
`PERIODICALLY VERIFY
`THE TEXT UNTIL USER SWPES
`
`102
`
`WEB BROWSER
`BIOMETRIC
`BROWSER
`EXTENSION
`
`
`
`
`
`TRANSACTION
`DETAILS, A RANDOM
`CHALLENGE AND
`SIGNATURE
`
`
`
`HTTPS WITH WEBSERVER
`
`9 -b.
`
`SECURESTORAGE BIOMETRIC SENSOR
`
`110
`
`ENCRYPTION KEY
`
`Carbyne Ex 2030, p.1 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`US 2011/O138450 A1
`
`
`
`
`
`NH
`
`Carbyne Ex 2030, p.2 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 2 of 17
`
`US 2011/O138450 A1
`
`200
`
`1.
`
`2O2
`
`204
`
`208
`
`212
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`A USER SUBMITS A TRANSACTION TO AWEB SERVER
`WIAA WEB BROWSERAPPLICATION
`
`THE WEBSERVER RETURNS THE TRANSACTIONSIGNED WITH
`AKEY SHARED BETWEEN THE WEBSERVER AND THE CLIENT
`DEVICE EXECUTING THE WEB BROWSERAPPLICATION
`
`THE WEB SERVER COMMUNICATES ADDITIONAL DATA TO THE
`CLIENT DEVICE EXECUTING THE WEB BROWSERAPPLICATION
`
`THE WEB BROWSERAPPLICATION RECEIVES THE
`TRANSACTION DATA AND ANY ADDITIONAL DATA, AND
`COMMUNICATES TO A BIOMETRIC SERVICE
`
`THE BIOMETRIC SERVICE GENERATES A WINDOW AND
`DISPLAYSTRANSACTION DATAN THE WINDOW
`
`THE BOMETRIC SERVICE MONITORS THE DATA DISPLAYED
`IN THE WINDOW TO ENSURE DATA IS NOT MODIFIED
`
`
`
`214
`
`DATAN WINDOW
`MODIFIED
`
`THE USER REVIEWS THE TRANSACTION DATAN THE WINDOW
`AND CONFIRMS THE TRANSACTION BY PROVIDING VALID
`BIOMETRIC DATA OR DENIES THE TRANSACTION BY
`CANCELING THE WINDOWITRANSACTION
`
`FIG. 2A
`
`Carbyne Ex 2030, p.3 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 3 of 17
`
`US 2011/O138450 A1
`
`220
`
`
`
`
`
`
`
`USER PROVIDES
`VALID BOMETRIC
`DATA
`
`
`
`NO
`
`YES
`
`THE BIOMETRIC SERVICE GENERATES A CONFIRMATION
`TOKEN AND COMMUNCATES THE CONFIRMATION TOKENTO
`THE WEBSERVER
`
`THE WEB SERVERVALIDATES THE CONFIRMATION TOKEN
`
`226
`
`NO
`
`VALID
`CONFIRMATION
`TOKENT
`
`
`
`
`
`
`
`YES
`
`THE WEB SERVER PROCESSES THE TRANSACTION
`
`THE WEBSERVER NOTIFIES THE BOMETRIC SERVICE WHEN
`THE TRANSACTION IS COMPLETE
`
`
`
`
`
`
`
`
`
`222
`
`224
`
`228
`
`230
`
`
`
`THE WEB SERVER
`CANCELS THE
`TRANSACTION
`
`FIG. 2B
`
`218
`
`Carbyne Ex 2030, p.4 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 4 of 17
`
`US 2011/O138450 A1
`
`
`
`300
`
`Login to yOur acCOunt
`using Fingerprint Security
`
`Please SWipe your finger
`
`If you prefer you may use yOur Username and
`Password.
`Not yet registered? Register now.
`
`FIG. 3
`
`Send Money
`You can send money to another user.
`Payment($):
`000
`
`TO:
`
`400
`
`John Smith
`
`My ACCOUnt
`
`FIG. 4
`
`Carbyne Ex 2030, p.5 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 5 of 17
`
`US 2011/O138450 A1
`
`Transaction Confirmation
`
`
`
`
`
`Cance Transaction
`
`F.G. 5
`
`Transaction Complete
`
`Transfer $5000 from your account to account'John
`Smith'.
`
`600
`
`Thanks you for using this system
`
`Make another Transaction
`
`My ACCount
`
`F.G. 6
`
`Carbyne Ex 2030, p.6 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Jun. 9, 2011 Sheet 6 of 17
`
`US 2011/O138450 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`V//, "$DIH
`
`Carbyne Ex 2030, p.7 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`US 2011/O138450 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Carbyne Ex 2030, p.8 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 8 of 17
`
`US 2011/O138450 A1
`
`-
`
`802
`-
`
`HOST PC
`
`
`
`WinUSB
`DRIVER
`
`BIOMETRIC
`SERVICE
`
`
`
`APPLICATION
`
`80
`
`BIOMETRIC
`SENSOR
`<6)
`Š2
`
`806
`
`SECURE STORAGE
`
`FIG. 8
`
`Carbyne Ex 2030, p.9 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 9 of 17
`
`US 2011/O138450 A1
`
`006__^
`
`Z06
`
`
`
`
`
`Od 1SOH
`
`TSS
`
`(~~~
`
`906
`
`806
`
`ÅEX
`
`Carbyne Ex 2030, p.10 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 10 of 17
`
`US 2011/0138450 A1
`
`
`
`
`
`
`
`
`
`
`
`1002
`
`004
`
`c.
`
`AND PROVIDE CREDENAS
`(F REQUIRED)
`
`BOMERC
`SERVICE
`
`APPCAON ID
`USERD
`USER CREDENTAS
`
`1006
`
`SECURE SORAGE
`
`
`
`102
`
`104
`
`r
`
`BOMETRIC
`SERVICE
`
`AUHEN CAE
`OR DENTFY
`
`APPLICATION
`
`USER CREDENTALS
`
`FOR AUTHEN CATION
`
`ass
`
`88.88.
`RS :
`
`1106
`Y
`
`SECURE SORAGE
`
`FIG. 11
`
`Carbyne Ex 2030, p.11 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 11 of 17
`
`over
`
`ACOLObl
`
`OLZL
`
`NOLLVOMIddHASMOUESMOCNIMKgs
`
`OMLSNOIg
`
`
`
`
`
`
`
`
`
`a3J0VdTWNLHOMANI
`
`
`
`
`
`YYOMANVeSININdYSONIAYSHLO
`
`FOIAaG
`
`
`
`YAABASWOodNvdNOISNALX3MOSNIS
`
`JONATIVHOOlLAWOIdOS
`
`OGNVY
`
`90¢1
`
`80c1viel
`
`FOIAYSS
`
`JONITIVHOclel
`
`
`
`ASNOdS3uYGNSS
`
`QrIWANOAINO
`
`SdIMS
`
`
`
`3SNOdS3uY1359
`
`US 2011/0138450 Al
`
`
`
`asvavlvdJdNoasAOVYOLSJYNOAS
`
`
`
`
`
`cbSls
`
`Carbyne Ex 2030, p.12 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`Carbyne Ex 2030, p.12 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`
`
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 12 of 17
`
`US 2011/0138450 A1
`
`1. 1300
`
`DETECT A FINGER CONTACTINGA FINGERPRINT
`SENSOR
`
`READ FINGERPRINT INFORMATIONASAUSER SWPES
`THEIR FINGER ACROSS THE FINGERPRINT SENSOR
`
`CREATE A FINGERPRINT TEMPLATE ASSOCATED WITH
`THE FINGERPRINT INFORMATION
`
`RECEIVE USER CREDENTIALS ASSOCATED WITH THE
`USER
`
`BIND THE USER CREDENTIALS WITH THE FINGERPRINT
`TEMPLATE
`
`STORE THE USER CREDENTIALS AND THE FINGERPRINT
`TEMPLAE
`
`1302
`
`1304
`
`1306
`
`1308
`
`1310
`
`1312
`
`FIG. 13
`
`Carbyne Ex 2030, p.13 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 13 of 17
`
`US 2011/0138450 A1
`
`/1 1400
`
`READ FINGERPRINT INFORMATION FROMA USER'S
`FINGER IN CONTACT WITH A FINGERPRINT SENSOR
`
`IDENTIFY A FINGERPRINT TEMPLATE ASSOCATED WITH
`THE USER
`
`COMPARE THE FINGERPRINT INFORMATION READ FROM
`THE USERS FINGER WITH THE FINGERPRINT TEMPLATE
`
`1408
`
`YES
`
`RETRIEVE USER CREDENTIALS ASSOCATED WITH THE
`USER
`
`COMMUNICATE THE USER CREDENTIALS TO A
`REQUESTING PROCESS OR SYSTEM
`
`
`
`
`
`1414
`
`DO NOT RETRIEVE
`USER CREDENTIALS
`
`FIG. 14
`
`Carbyne Ex 2030, p.14 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 14 of 17
`
`US 2011/0138450 A1
`
`1. 1500
`
`
`
`READ FINGERPRINT INFORMATION FROMA USER'S
`FINGER IN CONTACT WITH A FINGERPRINT SENSOR
`
`AUTHENTICATE THE FINGERPRINT INFORMATION
`
`
`
`
`
`
`
`AUTHENTICATED?
`
`YES
`
`1506
`
`NO
`
`RETRIEVE CREDENTIALS ASSOCATED WITH THE USER
`BASED ON THE FINGERPRINT INFORMATION
`
`DECRYPT THE USER CREDENTIALS
`
`1502
`
`1504
`
`1
`508
`
`1510
`
`IDENTIFY A UNIQUE DENTIFIER ASSOCATED WITH THE
`FNGERPRINT SENSOR
`
`1512
`
`
`
`COMMUNICATE THE DECRYPTED USER CREDENTIALS
`AND THE UNIQUE IDENTIFIER TO AREQUESTING
`PROCESS OR SYSTEM
`
`1514
`
`
`
`
`
`
`
`GENERATE MESSAGE
`INDICATING FAILURE OF
`AUTHENTICATION
`
`1516
`FIG. 15
`
`Carbyne Ex 2030, p.15 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 15 of 17
`
`US 2011/0138450 A1
`
`1. 1600
`
`1602
`
`1604
`
`AWEB BROWSERAPPLICATION ACCESSES AWEB
`SITE THAT SUPPORTS BIOMETRICAUTHENTICATION
`
`DETERMINE WHETHER A BIOMETRIC DEVICES
`INSTALLED IN THE SYSTEM EXECUTING THE WEB
`BROWSER APPLICATION
`
`
`
`
`
`BIOMETRIC DEVICE
`INSTALLED?
`
`YES
`
`1606
`
`NO
`
`THE WEB BROWSERAPPLICATION OFFERSENHANCED
`SECURITY TO AUSER THROUGH THE USE OF THE
`BIOMETRIC DEVICE
`
`1608
`
`
`
`
`
`
`
`USER ACCEPTS OFFER
`OF ENHANCED SECURITY?
`
`1610
`
`NO
`
`YES
`
`USERENROLLS USING THE BOMETRIC DEVICE
`
`1612
`
`
`
`1614
`
`THE WEB BROWSERAPPLICATION
`OPERATES WITHOUT BOMETRIC
`AUTHORIZATION
`
`FIG. 16
`
`Carbyne Ex 2030, p.16 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Patent Application Publication
`
`Jun. 9, 2011 Sheet 16 of 17
`
`US 2011/O138450 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Carbyne Ex 2030, p.17 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`Jun. 9, 2011 Sheet 17 of 17
`
`US 2011/O138450 A1
`
`
`
`
`
`Carbyne Ex 2030, p.18 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`US 2011/O 138450 A1
`
`Jun. 9, 2011
`
`SECURE TRANSACTION SYSTEMS AND
`METHODS USING USERAUTHENTICATING
`BOMETRIC INFORMATION
`
`RELATED APPLICATIONS
`0001. This application claims the benefit of U.S. Provi
`sional Application No. 61/249,218, filed Oct. 6, 2009, the
`disclosure of which is incorporated by reference herein. This
`application also claims the benefit of U.S. Provisional Appli
`cation No. 61/292.820, filed Jan. 6, 2010. This application
`also references the following U.S. Non-Provisional Applica
`tions: U.S. Non-Provisional application Ser. No. 12/731,027,
`filed Mar. 24, 2010, U.S. Non-Provisional application Ser.
`No. 12/731,037, filed Mar. 24, 2010, U.S. Non-Provisional
`application Ser. No. 12/731,050, filed Mar. 24, 2010, U.S.
`Non-Provisional application Ser. No. 12/751,952, filed Mar.
`31, 2010, U.S. Non-Provisional application Ser. No. 127751,
`964, filed Mar. 31, 2010, U.S. Non-Provisional application
`Ser. No. 12/751,983, filed Mar. 31, 2010, U.S. Non-Provi
`sional application Ser. No. 12/751,954, filed Mar. 31, 2010,
`and U.S. Non-Provisional application Ser. No. 12/751,969,
`filed Mar. 31, 2010. All of these co-pending applications are
`incorporated by reference herein.
`
`BACKGROUND
`0002 Typical user authentication systems and procedures
`use passwords to authenticate the identity of the user. In many
`instances, Web sites are authenticated using SSL (Secure
`Sockets Layer) or other protocols. SSL is a protocol for
`securely transmitting information via the Internet. When
`using SSL, a Web site is authenticated via its certificate. The
`user seeking access to the Web site is then authenticated by
`username and password.
`0003. Although passwords are commonly used to authen
`ticate users, passwords are subject to various attacks, such as
`phishing attacks, social engineering attacks, dictionary
`attacks and the like. Typically, longer passwords with com
`binations of letters and numbers provide a higher level of
`security. However, these longer passwords are more difficult
`for users to remember. Additionally, passwords provide a
`single factor of authentication by requiring the user to provide
`Something they know. This factor does not provide any physi
`cal authentication of the user's identity. Thus, any person can
`access the user's Web-based accounts and information if they
`gain knowledge of the user's password and username. Addi
`tionally, anyone with knowledge of a user's password can
`initiate transactions (e.g., purchase transactions and fund
`transfers) without the user's permission.
`0004 Another potential threat that occurs when using
`passwords is commonly referred to as “Man in the Browser
`attacks. These types of attacks involve malicious Software
`applications (malware) running in the internet browser while
`the user is logging on to a web site or performing a financial
`transaction.
`0005 One of the implementations of this attack is to get
`access to user's password when the user provides their pass
`word to the internet browser. After this point malware can
`conduct any type of malicious action with the user's account.
`0006 Another example of a “Man in the Browser' attack
`is to modify the transaction information on the fly and dupe
`the user by encouraging them to confirm a transaction which
`they didn't intend to confirm. The malware residing in the
`internet browser has full access to all graphical user interface
`
`parts of the browser (window, text, etc.) and may change them
`whenever necessary. Therefore, it's important to not trust the
`browser user interface when conducting important financial
`operations or when logging in to a web account.
`0007. Therefore, it is desirable to provide a user authenti
`cation method and system that offers a more secure authen
`tication of the user, and more secure transactions, than com
`monly used password-based systems and methods.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0008 FIG. 1 depicts an example system capable of imple
`menting secure transactions as discussed herein.
`0009 FIGS. 2A and 2B representa flow diagram depicting
`an embodiment of a procedure for implementing a secure
`transaction.
`0010 FIGS. 3-6 depict example user interface displays for
`implementing secure transactions.
`(0011
`FIGS. 7A and 7B depict another example of a pro
`cedure for implementing a secure transaction.
`0012 FIG. 8 depicts an example system capable of per
`forming biometric user authentication.
`0013 FIG. 9 depicts another example system capable of
`performing biometric user authentication.
`0014 FIG. 10 depicts an example user enrollment process.
`0015 FIG. 11 depicts an example user authentication pro
`CCSS,
`0016 FIG. 12 depicts another example system capable of
`performing biometric user authentication.
`(0017
`FIG. 13 is a flow diagram depicting an embodiment
`of a procedure for enrolling a user of a biometric authentica
`tion system.
`0018 FIG. 14 is a flow diagram depicting an embodiment
`of a procedure for authenticating a user of a biometric authen
`tication system.
`0019 FIG. 15 is a flow diagram depicting another embodi
`ment of a procedure for authenticating a user of a biometric
`authentication system.
`0020 FIG. 16 is a flow diagram depicting an embodiment
`of a procedure for authenticating a user of a Web browser
`application that Supports biometric authentication.
`0021
`FIG. 17 depicts another embodiment of a procedure
`for enrolling a user of a biometric authentication system.
`0022 FIG. 18 depicts another embodiment of a procedure
`for identifying and authenticating a user of a biometric
`authentication system.
`0023 Throughout the description, similar reference num
`bers may be used to identify similar elements.
`
`DETAILED DESCRIPTION
`0024. The systems and methods described herein relate to
`biometric authentication of users. "Biometrics”, “biometric
`information' and “biometric data” refers to measurable bio
`logical characteristics of a user, such as fingerprint character
`istics, facial characteristics, eye characteristics, Voice charac
`teristics (also referred to as a “voiceprint”) and the like. As
`discussed herein, biometric information provides an addi
`tional level of security when used in Systems and procedures
`related to authentication of a user and the implementation of
`secure transactions.
`0025 Particular examples discussed herein use fingerprint
`biometric information to authenticate one or more users. In
`other embodiments, any type of biometric information may
`be used instead of fingerprint information. Additionally, a
`
`Carbyne Ex 2030, p.19 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`US 2011/O 138450 A1
`
`Jun. 9, 2011
`
`particular embodiment may utilize multiple types of biomet
`ric information (e.g., fingerprints and Voiceprints) to authen
`ticate a user. Certain described embodiments refer to “swipe'
`style fingerprint sensors. However, alternate embodiments
`may include any type offingerprint sensor, such as a “place
`ment’ sensor. In particular embodiments, the biometric sen
`sor is physically attached (or manufactured into) a client
`device. Such as a computer, cellular phone, and so forth. In
`other embodiments, the biometric sensor is a portable device
`that is temporarily coupled to the client device (e.g., a plug
`gable USB device) for enrollment, authentication and/or
`secure transaction procedures.
`0026. As used herein, a “web application', a “web-based
`application', and a “web-enabled application” refers to a
`software application or software routine that is capable of
`communicating with one or more web servers or similar
`devices via the Internet or other data communication net
`work. Additionally, a “plug-in”, “browser plug-in” or a
`“browser extension” refers to an application or extension that
`provides a variety of different features and functions. Particu
`lar examples of "plug-ins' and “browser plug-ins' discussed
`herein provide features and functions related to user authen
`tication while, for example, accessing web sites, implement
`ing secure transactions, and the like. In particular embodi
`ments, the browser plug-in is installed as part of the
`manufacturing process of devices equipped with associated
`biometric devices. In other embodiments, the browser plug-in
`is downloaded (e.g., via the Internet) at any time after the
`device is manufactured. In specific implementations, the
`browser plug-in is operable with any biometric device that
`supports the Windows Biometric Framework or other sup
`ported architectures or systems.
`0027. As discussed above, typical passwords do not pro
`vide any physical authentication of the user's identity. Thus,
`any person can access a user's Web-based accounts and
`related information if they gain knowledge of the user's pass
`word and username. Additionally, anyone with the user's
`password and username can initiate a transaction (such as a
`financial transaction) without the user's permission. Using
`biometric information in the user authentication and/or trans
`action process provides an increased level of security by
`authenticating physical characteristics of the user. Thus, an
`imposter with the correct password but lacking the required
`physical characteristics will not be authenticated by the sys
`tem and not permitted to initiate a transaction needing user
`permission.
`0028. The systems and methods described herein perform
`biometric user authentication in several steps. A specific dis
`cussion of these user authentication steps is provided below.
`0029 FIG. 1 depicts an example system 100 capable of
`implementing secure transactions as discussed herein. A web
`browser application 102 executing on a user's computing
`device communicates with various web servers via the Inter
`net. Web browser application 102 includes a browser exten
`sion 104 (or browser plug-in) that communicates with a bio
`metric service 106. In a particular embodiment, biometric
`service 106 is a secure application executing in a background
`mode on the user's computing device. Biometric service 106
`provides a communication interface to a biometric sensor
`108, such as a fingerprint sensor. Embodiments of biometric
`sensor 108 may include a unique encryption key 110 and may
`store various information, Such as user names, encrypted
`secret keys, and the like in a secure storage device 112.
`
`0030 Browser extension 104 is capable of communicat
`ing transaction details, random challenges, signature infor
`mation, and other data to biometric service 106. Biometric
`service 106 verifies the digital signature of an agent applica
`tion 114 prior to communicating with the agent application.
`Biometric service 106 may communicate transaction details
`and related information to agent application 114. During a
`secure transaction, biometric service 106 also verifies the text
`presented in a transaction window 116 to the user until the
`user confirms the transaction by interacting with biometric
`sensor 108 (e.g., by presenting the user's fingerprint to a
`fingerprint sensor). Agent application 114 is responsible for
`launching transaction window 116 and displaying transaction
`information in the transaction window. Biometric service 106
`communicates with one or more web servers as part of the
`user authentication procedure and during implementation of
`the secure transaction. Additional details regarding the enroll
`ment and biometric authentication of a user are discussed
`below.
`FIGS. 2A and 2B representa flow diagram depicting
`0031
`an embodiment of a procedure 200 for implementing a secure
`transaction. A user Submits a transaction to a web server via a
`web browser application (block 202). This transaction may
`include a purchase transaction, a funds transfer transaction, or
`any other transaction in which the user desires a particular
`level of security. The web server returns the transaction
`signed with a key that is shared between the client device (the
`computing system executing the web browser application)
`and the web server (block 204). The web server may also
`communicate additional data to the client device executing
`the web browser application (block 206). This additional data
`may include transaction details, time and other information.
`For example, additional data may include a cryptographic
`OCC.
`0032. The web browser application receives the transac
`tion data and any additional data, and communicates the
`received data to a biometric service (block 208), such as
`biometric service 106 shown in FIG.1. The biometric service
`then generates a window and displays transaction data in the
`window (block 210). This window is for the benefit of the user
`to view and confirm the transaction details. The biometric
`service then monitors the transaction data presented in the
`window to ensure that the presented data is not modified
`(block 212), e.g., by a malicious application or a malicious
`user. If the biometric service detects that any of the data in the
`window is modified, the biometric service instructs the web
`server to cancel the transaction (block 218). The biometric
`service may verify the integrity of the data in the window at
`regular (e.g., periodic) time intervals or at random time inter
`vals.
`0033. If the data in the window is not modified, the user is
`then given the opportunity to review the transaction data
`presented in the window and either 1) confirm the transaction
`by providing valid biometric data; or 2) deny the transaction
`by canceling the window or canceling the transaction (block
`216). If the user does not provide valid biometric data (or the
`user closes the window/cancels the transaction), the biomet
`ric service instructs the web server to cancel the transaction
`(block 218). If the user provides valid biometric data, the
`biometric service generates a confirmation token and com
`municates the confirmation token to the web server (block
`222). The web server then validates the confirmation token
`(block 224). If the confirmation token is determined by the
`web server to be invalid, the web server cancels the transac
`
`Carbyne Ex 2030, p.20 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`US 2011/O 138450 A1
`
`Jun. 9, 2011
`
`tion (block 218). However, if the confirmation is determined
`by the web server to be valid, the web server processes the
`transaction (block 228) and notifies the biometric service
`when the transaction is complete (block 230).
`0034 FIGS. 3-6 depict example user interface displays for
`implementing secure transactions. FIG. 3 shows an example
`user interface display 300 that gives the user an opportunity to
`login to the user's account. In this example, the user logs into
`the account by Swiping their finger across a fingerprint sensor
`or activating another biometric device.
`0035 FIG. 4 shows an example user interface display 400
`that allows the user to send funds to another user or to make
`a payment to a merchant or other person or entity. As shown
`in FIG. 4, the user can enter the amount of the payment or
`funds transferas well as the name of the recipient of the funds.
`In alternate embodiments, the user may also identify addi
`tional information Such as a scheduled time for the transac
`tion or a comment/note related to the transaction.
`0036 FIG. 5 shows an example user interface display 500
`that allows a user to confirm a transaction by Swiping their
`finger across a fingerprint sensor (or using another type of
`biometric device). The interface shown in FIG. 5 displays the
`transaction details, such as the amount of the funds transfer
`and the recipient of the funds. If the user chooses not to
`confirm the transaction, they can close the window shown in
`FIG.5 or activate the “Cancel Transaction' button included in
`the display. To confirm the transaction, the user simply Swipes
`their finger across the fingerprint sensor in their computing
`device. If the user swipes their fingerprint and the user's
`fingerprint information is verified, the web server processes
`the transaction. Upon completion of the transaction, the web
`server notifies the user that the transaction is complete by
`displaying a user interface window (Such as example user
`interface 600 display shown in FIG. 6) indicating completion
`of the transaction. User interface 600 shown in FIG. 6 also
`displays the details of the completed transaction to the user.
`0037 FIGS. 7A and 7B depict another example of a pro
`cedure for implementing a secure transaction. The example
`shown in FIGS. 7A and 7B includes various tasks, actions and
`functions performed by different systems, procedures or
`components, such as the biometric sensor, the biometric Ser
`vice, the user, the biometric browser extension, the internet
`browser application, and the web server. A user visits a web
`site where they previously enrolled their biometric informa
`tion associated with a biometric device (e.g., a fingerprint
`sensor). If the user is authenticated, they can initiate a privi
`leged operation, Such as a secure transaction. This privileged
`operation may include transferring funds, purchasing a prod
`uct or service, and the like.
`0038. The web browser application creates an HTTP
`request associated with the secure transaction and communi
`cates the request to an appropriate web server. The web server
`requests information from the user to complete the requested
`secure transaction. The web server then returns various infor
`mation, such as transaction details, a shared key, and a ran
`dom challenge. This information returned by the web server is
`identified by a specific HTML tag inserted into the HTML
`code by the web server. Upon receiving this information from
`the web server, the web browser displays an appropriate
`response. The biometric browser extension detects the
`HTML tag inserted by the web server and requests the gen
`eration of a display window to display the transaction details
`and ask the user to confirm the transaction details by provid
`ing biometric authorization. The biometric browser extension
`
`interacts with the biometric service to obtain an authentica
`tion token if the user provides valid biometric information
`(e.g., a valid fingerprint is scanned by a fingerprint sensor).
`0039. The biometric service validates the digital signature
`of the biometric browser extension to be certain the biometric
`browser extension has not been modified or experienced any
`tampering. If the user provides valid biometric authorization
`and the biometric browser extension has not suffered any
`tampering, the biometric service creates an HTTPS connec
`tion with the appropriate web server and communicates the
`authentication token to the web server. The web server then
`validates the authentication token and completes the transac
`tion.
`0040. In a particular embodiment, an agent application
`generates the display window to the user that provides trans
`action details and requests that the user confirm the transac
`tion details by providing biometric authorization. This agent
`application is monitored by the biometric service to detect
`any modification of (or tampering with) the information dis
`played in the displayed window.
`0041. When a user begins using a device that has an asso
`ciated biometric sensor, the user enrolls with the biometric
`user authentication system by binding their user credentials
`with the user's biometric template (a "fingerprint template' in
`specific implementations). The biometric template contains
`information related to the user's biometric characteristics
`(also referred to as “biometric information') obtained from a
`biometric sensor that scans or reads the user's biometric char
`acteristics, such as a fingerprint. A user identification process
`identifies a particular user among multiple enrolled users
`(e.g., multiple users enrolled with a particular device, system
`or biometric sensor). A user verification process verifies that
`the user who provided their biometric information is who they
`claim to be by comparing the user's biometric information
`with the biometric template obtained during enrollment of the
`user. The enrollment, identification and verification of users
`are discussed in greater detail herein.
`0042. During an example enrollment process that uses a
`fingerprint sensor as the biometric sensor, a user Swipes their
`finger across the fingerprint sensor several times to create a
`fingerprint template. The fingerprint template contains quali
`tative fingerprint information that allows the user's finger
`print to be distinguished from fingerprints associated with
`other users. In alternate embodiments, a placement finger
`print sensor (also referred to as a static fingerprint sensor) is
`used such that a user places their finger on the fingerprint
`sensor rather than'swiping their finger across the fingerprint
`sensor. After creating a fingerprinttemplate, the user provides
`user credentials, such as a password, cryptographic key, ran
`dom seed, and the like. The systems and procedures described
`herein bind the user's fingerprint template with the user cre
`dentials. The fingerprint template and user credentials are
`then stored in a secure storage device. In one embodiment the
`secure storage device is contained within the fingerprint sen
`Sor hardware. In other embodiments, the secure storage
`device is contained in a device that utilizes the fingerprint
`SSO.
`0043. During an example user identification process (also
`referred to as a user verification process), a user Swipes their
`finger across a fingerprint sensor. The process then deter
`mines whether the user's fingerprint information matches a
`fingerprint template associated with the fingerprint sensor. If
`the user's fingerprint information matches a fingerprint tem
`plate, the user's credentials are released to the user and/or a
`
`Carbyne Ex 2030, p.21 of 26
`Apple v. Carbyne
`IPR2024-00507
`
`

`

`US 2011/O 138450 A1
`
`Jun. 9, 2011
`
`service or process requesting the user verification. Thus, the
`user credentials are not released from the secure storage
`device until a matching fingerprint template is confirmed. In
`particular embodiments, the user credentials released as a
`result of a match with a fingerprint template are not necessar
`ily the same credentials provided by the user during the
`enrollment process. For example, the user credentials
`released after finding a matching fingerprint template may
`include an OTP (One Time Password) token, RSA signature
`and the like. The enrollment process can be initiated by a Web
`server, a Web browser plug-in, and the like.
`0044) The described systems and methods communicate
`user credentials to a specific address, location, or other recipi
`ent identifier. Thus, even if an imposter can gain access to the
`user credentials, the system will send those user credentials to
`a predetermined address or location, thereby preventing the
`imposter from attempting to have the user credentials sent to
`an alternate address or location. The address or location infor
`mation is stored within the user credentials and is established
`as part of the enrollmen