Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 1 of 12
`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 1 of 12
`
`EXHIBIT 9
`EXHIBIT 9
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 2 of 12
`US 20030101348A1
`
`(19)United States
`(12)Patent Application Pnblication
`Russo et al.
`
`(54) METHOD AND SYSTEM EOR
`DETERMINING CONFIDENCE IN A
`DIGITAL TRANSACTION
`
`(76) Inventors: Anthony P. Russo, New York, NY
`(US); Peter A. McCoy, Santa Crnz, CA
`(US); Mark J. How이 1, Tucson, AZ
`(US)
`
`Correspondence Address:
`DORSEY & WHITNEY LLP
`Suite 3400
`Four Embarcadero Center
`San Francisco, CA 94III-4I87 (US)
`
`(21) Appl. No.:
`
`10/194,959
`
`(22) Filed:
`
`Jui. 12, 2002
`
`R이ated U.S. Appiication Data
`
`(63) Continuation-in-part of application No. 10/099,554,
`filed on Mar. 13, 2002. Continnation-in-part of appli­
`cation No. 10/099,558, filed on Mar. 13, 2002.
`
`(60) Provisional application No. 60/305,120, filed on Jnl.
`12, 2001.
`
`US 20030101348Al
`
`(10)Pub. No.: US 2003/0101348 Al
`May 29, 2003
`(43)Pub. Date:
`
`Publication Ciassification
`
`Int. C1.7 .............................H04K 1/00; H04L 9/00
`(51)
`(52) U.S. Ci............................................................... 713/185
`
`(57)
`
`ABSTRACT
`
`The present invention provides systems and methods utiliz­
`ing tokens to assign or mitigate risk. A software token is
`provided that associates a secret一such as a private key or
`password一with risk factors involved in protecting that
`secret from illicit access. The token may include an indica­
`tion or c시culation of the “overall risk of compromise^^
`(OROC), generally represented as an overall trust metric,
`associated with the secret. This token can then be used to
`inform system operators or third parties of the confidence of
`a given system transaction that depends on the secret. A third
`party can then take whatever actions it deems appropriate
`according to the estimated risk. For example, in one embodi­
`ment of the present invention, the risk factor is used to deny
`a transaction if the risk is deemed to great——is if the risk
`factor is greater than a predetermined (or sufficient) value.
`
`Server requests
`authentication wilh
`atlendarit IransarHirin
`し。nhdence Token
`
`blien or sep/cr
`initiates a
`iransaclioti
`
`긴0。
`
`Requester
`
`/し L2。
`
`Requester releases private
`encryption key using
`aulhen||cation method
`(passphrase, .
`fingerpnnl.PIN)
`
`七T
`
`Requester generates
`Iransaclior conlents
`
`J. zqo
`
`Requester adds inlormalion
`about confidence in lhe
`security of the transaction
`
`もて＞
`
`Requester signs
`Transaclion Confidence
`
`23
`
`じ
`
`Server receives transaction
`and Transaction
`boniidence Tcken
`
`Server adjusts confidence
`in ihc Iransadion based or
`pnvale kev 11110 ana
`=mploys any necessary
`consequences
`
`신2
`
`Transscbon
`completes
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 3 of 12
`
`Patent Application Pnblication May 29,2003 Sheet 1 of 3
`
`US 2003/0101348 Al
`
`Envelope
`
`3
`
`Transactionエ 서衬m사
`
`Enrollment Trust Metric
`
`storage Trust Metric
`
`Transmission Trust Metric
`
`Authentication T「니st Metric
`
`Overalt Trust Metric
`
`Timestamp
`
`170
`
`1%〉
`
`Seal
`
`ヽ\め
`
`F王&」
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 4 of 12
`
`Patent Application Publication May 29, 2003 Sheet 2 of 3
`
`US 2003/0101348 Al
`
`Requesler generates
`nls ■厂i
`transaction contents
`
`1 zqo
`
`I、ゲ
`
`Requester adds inFormation
`about confidence in the
`secunty of the transaction
`
`2.＜〇
`
`Requester signs
`Transaclion Confidence
`Token
`
`2&Q
`
`Server receives transaction
`and Transaction
`Confidence Token
`
`Server adjusts confidence
`in the transaclion based on
`pnvate key info and
`employs any necessary
`consequences
`
`L
`
`Transaction
`completes
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 5 of 12
`
`Patent Application Publication May 29, 2003 Sheet 3 of 3
`
`US 2003/0101348 Al
`
`Server receives transaction
`and Transaction
`Confidence Token
`
`ら夕
`
`3し。
`
`No
`
`Server transmits new
`Transaction Confidence
`Token to other Server
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 6 of 12
`
`US 2003/0101348 Al
`
`1
`
`May 29, 2003
`
`METHOD AND SYSTEM EOR DETERMINING
`CONFIDENCE IN A DIGITAL TRANSACTION
`
`RELATED APPEICATIONS
`[0001] This application further relates to the following
`co-pending applications:
`[0002] U.S. application Ser. No.
`, filed
`,
`entitled “BIOMETRICAEEY ENHANCED DIGITAL CËR-
`TIEICATES AND SYSTEM AND METHOD FOR MAK­
`ING AND USING^^ (Attorney Docket No. A-70596/RMA/
`JML);
`[0003] U.S. application Ser. No.
`, filed
`,
`entitled “SECURE NETWORK AND NETWORKED
`DEVICES USING BIOMETRICS^^ (Attorney Docket No.
`A70595/RMA/JML); and
`[0004] U.S. application Ser. No.
`, filed
`,
`entitled “METHOD AND SYSTEM FOR BIOMETRIC
`IMAGE ASSEMBEY EROM MULTIPLE PARTIAL BIO­
`METRIC FRAME SCANS^^ (Attorney Docket No.
`A-70591/RMA/JML); all of which are hereby incorporated
`by reference.
`[0005] This application claims the benefit nnder 35 U.S.C.
`§ff9 and/or 35 U.S.C. §120 of the filing date of: U.S.
`Provisional Application Serial No. 60/305,f20, filed Jul. 12,
`2001, which is hereby incorporated by reference, and
`entitled SYSTEM, METHOD, DEVICE AND COMPUTER
`PROGRAM FOR NON-REPUDIATED WIREEESS
`TRANSACTIONS; U.S. patent application Ser. No. f0/099,
`554 filed Mar. 13, 2002 and entitled SYSTEM, METHOD,
`AND OPERATING MODEL EOR MOBILE WIRELESS
`NETWORK-BASED TRANSACTION AUTHENTICA­
`TION AND NON-REPUDIATION; and U.S. patent appli­
`cation Ser. No. 10/099,558 filed Mar. 13, 2002 and entitled
`FINGERPRINT BIOMETRIC CAPTURE DEVICE AND
`METHOD WITH INTEGRATED ON-CHIP DATA BUFF­
`ERING; each of which applications are incorporated by
`reference herein.
`
`FIELD OE THE INVENTION
`[0006] The present invention relates generally to the field
`of methods, computer programs and computer program
`products, devices, and systems for encryption systems,
`especi시ly public key infrastructure (PKT) systems, and also
`to the field of biometrics, especially but not limited to
`biometrics such as human fingerprints and human voice­
`prints.
`
`BACKGROUND OF THE INVENTION
`[0007] The security and integrity of information systems
`depends in part on authentication of mdividu시 users一
`accurately and reliably determining the identity of a user
`attempting to use the system. Once a user is authenticated,
`a system is then able to authorize the user to retrieve certain
`information or perform certain actions appropriate to the
`system^s understanding of the user^s identity. Examples of
`such actions include downloading a document, completing a
`financial transaction, or digitally signing a purchase.
`[0008] Numerous methods have been developed for
`authenticating users. Generally, as will be understood by
`those skilled in the art, authentication methods are grouped
`
`into three categories, also called authentication factors: (f)
`something you know一a secret such as a password or a PIN
`or other information; (2) something you have一such as a
`smartcard, the key to a mechanical lock, an ID badge, or
`other physical object; and (3) something you are一a measure
`of a person such as a fingerprint or voiceprint. Each method
`has advantages and disadvantages including those relating to
`ways that a system may be fooled into accepting a normally
`unauthorized user in cases where, for example, a password
`has been guessed or a key has been stolen.
`[0009] The third category above一referred to herein as
`'something you are^ authentication methods一are the sub­
`ject of the biometrics field. Biometric identification is used
`to verify the identity of a person by measuring selected
`features of some physical characteristic and comparing those
`measurements with those filed for the person in a reference
`database or stored in a token (such as a smartcard) carried by
`the person. Physical characteristics that are used today
`include fingerprints, voiceprints, hand geometry, the pattern
`of blood vessels on the wrist or on the retina of the eye, the
`topography of the iris of the eye, facial patterns, and the
`dynamics of writing a signature or typing on a keyboard.
`Biometric identification methods are widely used today for
`securing physical access to buildings and securing data
`networks and personal computers.
`[0010] A secure system is based upon either a mutually-
`shared secret or a private key of a public-private key pair.
`During the enrollment process, the secret is first selected or
`created, then agreed upon and stored for later use. There are
`generally four major sources of risk associated with the
`secret being compromised: (f) the secret can be guessed by
`an unauthorized user; (2) the secret was observed by an
`unauthorized user during creation or subsequent transmis­
`sion; (3) the stored secret can be retrieved and employed by
`an unauthorized user after creation; and/or (4) the stored
`secret was issued to the wrong party.
`[0011] Each of the above broad categories has its own
`specific risk factors depending on the type of secret, where
`and how it is stored and how it is created. For example, the
`risk of guessing is dependent on a variety of factors includ­
`ing, but not limited to, the type of secret (for example, a
`password, a private PKI key, a symmetric key, or the like),
`the length of the secret (for example, number of characters
`in the password or number of bits in the private key), and the
`randomness of the secret (for example, an entropy calcula­
`tion plus, in the case of a password, whether the password
`matches a dictionary word). The risk of observation during
`transmission is dependent on factors including, but not
`limited to: whether it was transmitted at all (generally, there
`is no transmission of the secret in PKT); what type of
`encryption was used, if any, during transmission; and the
`network used for the transmission (for example, whether it
`was transmitted using a telephone, an internet, a private
`network, or other network or communication link or chan­
`nel).
`[0012] The risk of a stored secret being illicitly retrieved
`is dependent on factors including, but not limited to: the
`number of devices where instances of the secret are stored
`(for example, a secret may be stored on a user^s PC as well
`as in a system database); the storage medium used for each
`stored instance (hard disk, paper notes, smart card, portable
`memory device such as a flash memory card, PKCS-ff
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 7 of 12
`
`US 2003/0101348 Al
`
`2
`
`May 29, 2003
`
`token (as discussed further in "PKCS #11 v2.11: Cryptro-
`graphic Token Interface Standard^^ published Jnne 2001 by
`RSA Laboratories, hereby incorporated by reference), or the
`like); whether the secret is stored in plain text or encrypted;
`if stored encrypted, the risk associated with the encryption
`key nsed; what kind of biometrics used, if any, to restrict
`access to the storage medium; the security of passphrase
`used, if any, to retrieve secret; the security of biometric
`system(s) used, if any, to retrieve secret; and the security of
`physical token used, if any, to retrieve secret——example
`if a token is used, the security of that token is dependent
`upon whether someone else has had access to it, or if it has
`been lost or stolen; what combinations of passphrase, bio­
`metric, and token are required, if any; and the security of the
`enrolled biometric template.
`[0013] The risk associated with the secret being issued to
`the wrong person is dependent on factors including, but not
`limited to: the specific method or methods used to verify the
`user^s identity prior to issuing the secret; the degree of
`human interaction, if any, involved in the verification pro­
`cess (i.e. is it supervised and verified by a trained human
`being); what specific biometric system or systems, if any, is
`used to aid verification; which government agencies (such as
`for example the FBI, Secret Service, or other agency), if any,
`aid in the verification process; and which trusted documents,
`if any, were required for verification (for example bank
`statement, social security number, passport, or the like).
`[0014] Systems used for e-commerce, online banking and
`other financially related areas rely on security to prevent
`unauthorized users from accessing services for monetary
`gain. For example, well-designed systems try to prevent
`would-be buyers from purchasing goods and services with
`someone else^s credit card by requiring a PIN or a password.
`[0015] More generally, the security and integrity of infor­
`mation systems depends primarily on keeping data confi­
`dential so that only authorized users may see or act against
`the data, and assuring the integrity of data so that the data
`can not be changed or tampered with undetected. The field
`of cryptography provides well-known tools for assuring
`confidentiality and integrity using encryption techniques
`such as ciphers and hash algorithms.
`[0016] One widely known and implemented body of these
`tools, and procedures and practices for their use, is called
`Public Key Infrastructure (PKI). PKI gets its name from its
`use of a class of cryptographic algorithm called a public key
`algorithm. As is widely known to those versed in the
`cryptographic field, a public key algorithm is a crypto­
`graphic algorithm that operates using two different but
`mathematic시ly-related keys, a public key that may be
`shared with any party and a private key which must be kept
`secret, such that (for must such algorithms) data encrypted
`with the public key may only be decrypted with the private
`key, and vice-versa. PKI standards are well known, X.509
`for example, described in Housley, R., ''Internet X.509
`Public Key Infrastructure Certificate and CRL Profile,^^ RFC
`2459, January 1999, and ITU-T Recommendation X.509
`(1997 E): Information Technology——Systems Inter­
`connection一The Directory: Authentication Framework,
`June 1997, both of which are hereby incorporated by refer­
`ence.
`[0017] These standards provide powerful mechanisms for
`safe and private storage and transmission of confidential
`
`data so that it remains hidden from unauthorized parties. The
`standards provide for digit시 signatures, which provide the
`receiving party of some data with an assurance of the
`identity of the transmitting party. PKI standards further
`provide for digital certificates, which provide a tamper­
`resistant, portable record of the association of a public key
`with a person^s or organization^s name, attested to and
`signed by a trusted party, thus presenting a form of unique,
`irrefutable digit시 identity or credential for that person or
`organization. PKI standards also provide other useful and
`powerful mechanisms that can contribute to the security and
`integrity of information systems.
`[0018] PKI is widely nsed in commercial and non-com-
`mercial systems, both over the Internet and in more closed
`or local applications. Most web browsers, for example, use
`PKI and PKI-based standards to interoperate with web
`servers when high security is desired, as when a user
`specifies a credit card number for payment while placing an
`online order. The proliferation of electronic commerce has
`led many jurisdictions around the world to begin to develop
`leg시 standards with the intended result that a correctly
`constituted digital signature would be every bit as legally
`binding as a handwritten signature is today.
`[0019] PKI provides powerful mechanisms, but it has
`weaknesses. One way for digital identities to be compro­
`mised is for an impostor to somehow get a copy of the
`private key that is associated with the public key embedded
`in a certificate, thus invalidating an assumption that only the
`person or organization to which the certificate is issued has
`access to the (secret) private key. Anyone with both the
`certificate (which is meant to be public information, freely
`exchanged with anyone) and the associated private key
`(which is meant to be secret) can impersonate someone else
`and compromise the security and integrity of an information
`system dependent on the valid use of a certificate and
`associated private key.
`[0020] Most systems, therefore, secure the private key
`such that the user must authenticate before the private key
`can be used for any task. Many such systems require a
`password ("something you know^^) or a smartcard ("some­
`thing you have^^), or both. Some systems provide additional
`security by putting the private key on a smartcard that is
`resistant to tampering or copying. Other systems may also
`employ biometrics ("something you are^^) to ensure that the
`person using the private key is in fact the true owner of the
`certificate.
`[0021] However, smart cards may be lost, damaged, or
`stolen. Passwords may be forgotten or guessed. Biometrics
`systems can be fooled. These concerns are part of what is
`called in the field "the last-meter problem^^, the problem of
`making sure that an otherwise secure system isn^t compro­
`mised by a failure to correctly authenticate the person using
`(and usually physically adjacent to) some part of the system.
`The last-meter problem can present opportunities for impos­
`tors in PKI systems. Mathematically, the theoretical prob­
`ability of a PKI system being fooled or otherwise compro­
`mised is extremely low (much less than f in a billion, for
`instance). However, once the "last meter problem^^ is taken
`into account, the security of such a system is greatly
`reduced, as the "last meter problem^^ becomes the weakest
`link in an otherwise very secure chain.
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 8 of 12
`
`US 2003/0101348 Al
`
`3
`
`May 29, 2003
`
`[0022] Today^s PKI systems do not take into account the
`risk associated with the “last meter problem^^ when assessing
`the tmst level to associate with users of such systems.
`[0023] Accordingly, it is an object of the present invention
`to provide an indication of the security of a given transac­
`tion.
`
`SUMMARY
`[0024] In a first embodiment, the invention provides a
`transaction confidence token for use in a secure communi­
`cation system, comprising an envelope and a seal. The
`envelope comprises transaction information and a trust
`metric. The seal contains a digital signature of the envelope.
`In preferred embodiments, the envelope further includes a
`timestamp. In some embodiments, the transaction informa­
`tion contained in the envelope includes a web site address,
`a web session identifier, a monetary or exchange value, an
`order number, an SKU number, a credit card number, or any
`combinations thereof.
`[0025] In one embodiment, the trust metric within the
`envelope is an overall trust metric indicating a combined
`confidence level for enrollment, storage, transmission, and
`authentication processes employed for authentication of a
`transaction.
`[0026] In another embodiment, the trust metric comprises
`a storage tmst metric indicating a confidence level for a
`storage process associated with authentication of a transac­
`tion. In yet another embodiment, the trust metric comprises
`a transmission tmst metric indicating a confidence level for
`a transmission process associated with authentication of a
`transaction. In still another embodiment, the trust metric
`comprises an authentication trust metric indicating a confi­
`dence level for an authentication process associated with
`authentication of a transaction. In a further embodiment, the
`trust metric comprises an enrollment tmst metric indicating
`a confidence level for an enrollment process associated with
`authentication of a transaction. In other embodiments, a
`plurality of tmst metrics are provided in the envelope. In one
`embodiment, a first tmst metric comprises an overall trust
`metric and at least a second trust metric is provided chosen
`from the group consisting of an enrollment trust metric, a
`storage trust metric, a transmission tmst metric, an authen­
`tication trust metric, and combinations thereof.
`[0027] In some embodiments, the digital signature con­
`tained in the seal is signed with a private key.
`[0028] The present invention further provides methods for
`assuring a secure transaction. In one embodiment, a method
`for assuring a secure transaction comprises receiving a
`transaction confidence token comprising a trust metric asso­
`ciated with the transaction, determining if the tmst metric
`indicates a sufficient trust level; and processing the transac­
`tion if the tmst metric indicates or exceeds said sufficient
`trust level.
`[0029] In some embodiments, a method further comprises
`requiring a mitigating factor if said tmst metric indicates less
`than said sufficient tmst level. The mitigating factor may be
`chosen based on the trust metric. The mitigating factor may
`be chosen from the group consisting of a fee, a waiting
`period, an authentication procedure, and combinations
`thereof.
`
`[0030] In yet other embodiments, the method further com­
`prises processing the transaction after receiving a mitigating
`factor.
`[0031] In other embodiments, the method further com­
`prises constructing a transaction confidence token compris­
`ing a tmst metric, and transmitting said transaction confi­
`dence token to a server.
`[0032] In other embodiments, a method for assuring a
`secure transaction comprises receiving a transaction confi­
`dence token comprising a tmst metric associated with said
`transaction, determining if said trust metric indicates an
`acceptable risk level; and processing said transaction if said
`trust metric indicates or is less than said acceptable risk
`level.
`[0033] In some embodiments, the method further com­
`prises requiring a mitigating factor if said trust metric
`indicates greater than said acceptable risk level. In still other
`embodiments, the method further includes processing said
`transaction after receiving said mitigating factor.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`[0034] The present invention may be better understood,
`and its features and advantages made apparent to those
`skilled in the art by referencing the accompanying drawings.
`[0035] FIG. 1 is a schematic representation of one
`embodiment of a transaction confidence token according to
`an embodiment of the present invention.
`[0036] FIG. 2 is a schematic flowchart showing a method
`of processing a transaction according to an embodiment of
`the present invention.
`[0037] FIG. 3 is a schematic flowchart outlining a process
`for using a transaction confidence token according to an
`embodiment of the present invention.
`
`DETAILED DESCRIPTION OF THE
`EMBODIMENTS
`[0038] Many systems today, especially those that use PKI,
`involve transactions that depend on keeping a secret pro­
`tected from use by third parties. If there is any risk that the
`secret is compromised, then that risk is propagated to the
`provider of the transaction itself. For example, if an internet­
`based system 시lows a user to purchase an item by entering
`any valid credit card number, then the risk to the credit card
`company or merchant related to an unauthorized purchase is
`dependent on how well that credit card number can be kept
`secret, for example, how well authenticated are the parties to
`whom the secret is made available.
`[0039] This invention introduces the concept of a software
`token that associates a secretーーsuch as a private key or
`password一with risk factors involved in protecting that
`secret from illicit access. Furthermore, in preferred embodi­
`ments of the present invention, the token includes an indi­
`cation or calculation of the “overall risk of compromise^^
`(OROC), generally represented as an overall tmst metric,
`associated with the secret. In some embodiments of the
`present invention, the token also includes a calculation of
`mdividu시 risk factor probabilities used to determine the
`OROC, or overall trust metric. This token can then be used
`to inform system operators or third parties of the confidence
`of a given system transaction that depends on the secret. A
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 9 of 12
`
`US 2003/0101348 Al
`
`4
`
`May 29, 2003
`
`third party can then take whatever actions it deems appro­
`priate according to the estimated risk. For example, in one
`embodiment of the present invention, the risk factor is used
`to deny a transaction if the risk is deemed to great——is
`if the risk factor is greater than a predetermined (or suffi­
`cient) value. In another embodiment, the risk factor is used
`to charge the user a fee in an effort to mitigate the risk, or
`where some fee may already be charged to the user for the
`transaction to charge different fees according to the assessed
`risk or trust level. Fhe fee may be a flat fee charged to all
`transactions having less than a sufficient trust level or the fee
`may vary according to the trust level indicated by the token.
`[0040] Most authentication systems are geared to answer
`the question of whether the party trying to use the system is
`the party it claims to be with either a yes or no, even though
`the authentication method or methods employed are imper­
`fect. The present invention provides a mechanism for a
`system to add an estimate of risk or confidence on that yes
`or no answer, and for other systems to use that confidence
`information to their advantage. In one embodiment, it also
`provides a mechanism for documenting the party^s identity
`so as to provide a non-repudiation mechanism for the
`transaction.
`[0041] That is, the present invention provides systems
`utilizing tokens to assign or mitigate risk.
`[0042] FIG. 1 depicts a schematic representation of trans­
`action confidence token 100 according to one embodiment
`of the present invention.
`[0043] A token, such as token 100, is created using avail­
`able information regarding risk factors, examples of which
`are discussed above. Token 100 can be in the form of a
`separate packet of stored data associated with the secret,
`integrated either with the secret itself or, in the case of PKI,
`with the associated digital certificate.
`[0044] The present invention provides transaction confi­
`dence tokens comprising at least one trust metric. As used
`herein, ' trust metric^ generally refers to a measure of a risk
`factor. Examples of typical risk factors are discussed above.
`In one embodiment, token 100 comprises information on at
`least one risk factor discussed above. In another embodi­
`ment, token 100 comprises an overall risk-of-compromise
`(OROC) value, or overall trust metric 110, which may take
`one or more risk factors into consideration. In a preferred
`embodiment, token 100 is created and stored in a database
`during both enrollment and subsequent transactions,
`includes all the fields shown in FIG. 1. In other embodi­
`ments, only a subset of fields shown in FIG. 1 are present.
`[0045] In one embodiment of the present invention, trust
`metrics, such as overall trust metric no, are given by an
`absolute probability ranging from 0.0 to f.O, calculated
`using a weighted Bayesian equation. Other ranges and
`equations for c시culating trust metrics may also or alterna­
`tively be employed. In preferred embodiments of the present
`invention, trust metrics are given by an arbitrary mapping of
`risk information to three categories——medium, and
`high. Any number of categories may alternatively be used,
`with each category represented by a unique indicator. The
`risk information may alternatively be provided by a con­
`tinuous range of values rather than in discrete categories.
`Overall trust metric 110 represents a weighted combination
`of individual risk probabilities of a plurality of risk factors.
`
`In a preferred embodiment, a system uses token 100 to deny
`or accept a transaction. In other embodiments, a system
`charges a fee, or imposes another mitigation factor一such as
`a waiting period or another required authentication—based
`on risk information contained in token 100.
`
`[0046] Accordingly, transaction confidence token 100
`(FIG. 1) is composed of two data structures: envelope 120
`and seal 13〇. Envelope 120 comprises transaction contents,
`or transaction information 140 and at least one trust metric,
`although a plur시ity of trust metrics are shown in FIG. 1.
`Further, envelope 120 comprises timestamp 15〇. In a pre­
`ferred embodiment, transaction information 140 represents a
`complete record of a transaction——as appropriate,
`account numbers, web session identifiers, monetary or
`exchange values, item quantities, an SKU number, an order
`number, a credit card number, a web URL or address, or
`other data describing the user^s authenticated request. In
`other embodiments, transaction information 140 comprises
`only some of the above information associated with a
`transaction. In a preferred embodiment, transaction infor­
`mation 140 comprises only a transaction identifier or refer­
`ence string such as a web session identifier as is often used
`in web applications. In an alternative embodiment, transac­
`tion information 140 field comprises a complete transaction
`confidence token, which may in turn (i.e., recursively)
`contain another transaction confidence token in its transac­
`tion contents field, without particular limit. This embodi­
`ment allows for multiple parties to attest to a transaction and
`attach their own confidence to the transaction as it is
`processed by each of a number of systems in series. The
`innermost transaction confidence token corresponds to the
`original transaction when it is first authenticated and signed
`by the originating party. Timestamp 150 generally comprises
`a string indicating a date and time at which the authentica­
`tion event which is the subject of the transaction confidence
`token took place. Generally, any time indicator is appropri­
`ate for timestamp 15〇. In a preferred embodiment, times­
`tamp 150 is expressed in Universal Coordinated Time
`(UTC). Overall trust metric 110 indicates a degree of overall
`confidence in a transaction. In one embodiment, overall trust
`metric 110 provides a degree of confidence in enrollment,
`storage, transmission, and authentication processes
`employed for authentication of a transaction. Overall trust
`metric 110 can be defined according to the specifics of the
`application contemplated, but in a preferred embodiment,
`there are three possible values corresponding to low,
`medium, and high confidence. In a preferred embodiment,
`low security refers to a password authentication against a
`4-digit numeric PIN stored in non-secure storage. Medium
`security refers to a fingerprint authentication or strong
`password (alphanumeric, mixed case, greater than 8 char­
`acters) against a secret in non-secure storage, and high
`security is attributed to a fingerprint authentication or strong
`password against a secret in secure storage such as a smart
`card. Generally, any number of trust categories can be
`assigned among any authentication processes.
`[0047] Envelope 120 may comprise metrics related to
`measures of individual aspects of an authentication process.
`That is, envelope 120 may comprise some or all of the
`following optional fields: (f) Enrollment Trust Metric 160,
`(2) Storage Trust Metric 170, (3) Transmission Trust Metric
`180, and (4) Authentication Trust Metric 19〇.
`
`

`

`Case 6:21-cv-01101-ADA Document 31-9 Filed 05/19/22 Page 10 of 12
`
`US 2003/0101348 Al
`
`5
`
`May 29, 2003
`
`[0048] Enrollment Tmst Metric 160 indicates a degree of
`confidence in secnrity of an enrollment or personalization
`process under which a secret was issued to an authenticating
`party. Enrollment trust metric 160 can be defined according
`to specifics of the application employed. In a preferred
`embodiment, there are three possible values corresponding
`to low, medium, and high confidence. In one embodiment, a
`low confidence enrollment tmst metric is assigned to self­
`enrollment where little or no manual verification of user
`identity is carried out; a medium confidence enrollment trust
`metric is assigned to online verification using a “weak
`secret^^ such as a credit card number, which may be inde­
`pendently verified to match the enrollee^s name by the credit
`card issuer; and a high confidence enrollment trust metric is
`assigned in an enrollment situation where the user^s identity
`is verified——trusted documents such as a passport,
`driver^s license, or the like—by a human being who works
`for the enrollment agency or represents another predeter­
`mined organization.
`[0049] Storage Tmst Metric 170 indicates a degree of
`confidence in the security of a method of storage used to
`store a secret. Storage Tmst Metric 170 can be defined
`according to the specifics of the application employed. In a
`preferred embodiment, there are three possible values cor­
`responding to low, medium, and high confidence. Here, in
`one embodiment, a storage t