`
`[19]
`
`[11] Patent Number:
`
`5,903,721
`
`Sixtus
`
`[45] Date of Patent:
`
`May 11, 1999
`
`US005903721A
`
`Jim Sabo, “Riding Shotgun on the Electronic Stagecoach”,
`NetGuide, Aug., 1996, pp. 119-124.
`Larry Loeb, “The Stage is Set”, Internet World, Aug., 1996,
`pp. 55_59,
`Marvin A. Sirbu, “Credits and Debits on the Internet”, IEEE
`Spectrum, Feb., 1997, PP~ 23‘29~
`David Chaum et al., “Minting Electronic Cash”, IEEE
`Spectrum, Feb., 1997, pp. 31-34.
`Peter S. Gemmell, “Traceable e-Cash”, IEEE Spectrum,
`Feb» 1997» P11 35-37
`Robert W. Baldwin et al., “Locking the e-Safe”, IEEE
`spectrum, Feb., 1997, pp- 4046-
`
`.
`Primary Examiner—J0seph E. Palys
`Asszstant ExamLner—Norman Michael Wright
`Attorney, Agent, or Firm—Anthony R. Barkume
`[57]
`ABSTRACT
`A th df
`1,
`t,
`t
`t,
`b t
`me o
`or execu ing a secure on ine ransac ion e ween
`a Vendor computer and a user computer, wherein the Vendor
`computer and the user computer are interconnected to a
`computer network such as the Internet for data communi-
`cations therebetween The method coin rises the ste s of the
`1 .
`. P
`P
`user computer transmitting a transaction request message ‘to
`the vendor computer via the computer network, the ‘financial
`transaction request C0H1Pr1S1r1g user Identlficatrorl data
`unique to the user computer; in response to receiving the
`transaction request, the vendor computer sending a transac-
`tion verification request to a trust server computer intercon-
`nected to the computer network, the transaction verification
`request comprising the user identification data and data
`indicative of the requested transaction; in response to receiv-
`ing the transaction verification request,
`the trust server
`computer authenticating the user computer by using the user
`identification data and communicating with the user com-
`puter for verification with the user identification data; and
`the trust server authorizing the transaction when the authen-
`ticating step has passed.
`
`11 Claims, 10 Drawing Sheets
`
`[54] METHOD AND SYSTEM FOR SECURE
`ONLINE TRANSACTION PROCESSING
`
`[75]
`
`Inventor: Timothy Sixtus, New York, N.Y.
`,
`_
`_
`[73] Assignee:
`cha1!{Techn0l0g1es Services, Inc., New
`Yor ’ N’Y'
`
`[21] Appl' No‘: 08/816’410
`[22]
`Filed:
`Mar. 13, 1997
`
`Int. Cl.5 ...................................................... G06F 13/00
`[51]
`[52] U.S. Cl.
`............................... .. 395/187.01; 395/188.01
`[58] Field of Search ......................... 395/188.01, 187.01,
`395/186; 380/3, 4, 21, 23, 24, 25, 30
`
`References Cited
`U.S. PATENT DOCUMENTS
`5/1995 AZIZ ........................................ .. 380/30
`9/1996 R056“ ----------- ~-
`364/408
`1/1997 salmon et al‘ ‘
`““ “ 395/207
`7/1997 Theimer et al‘
`’ 395/18701
`10/1997 Baker et al.
`.... .. 395/609
`. . . . . . . . .
`11/1997 Dare et al.
`. . . N 395/187.01
`11/1997 Goldman et al.
`. 395/188.01
`5/1998 Willsey . . . . . . . . . .
`. . . . .. 395/186
`5/1998 Olsen ............................... .. 395/187.01
`OTHER PUBLICATIONS
`
`
`
`5,416,842
`5557518
`595929375
`5’649’099
`5,678,041
`5,684,950
`5,684,951
`5,754,761
`5,758,069
`
`[56]
`
`Netscape Communications Corporation, “Netscape Live-
`Payment White Paper”, Oct. 02, 1996 (located on Internet)
`pp. 1-14.
`Michele Rosen, “Cash for Cyberspace”, Midrange Systems,
`Apr. 12, 1996, pp. 34-35.
`Stephan Somogyi, “Mediascape—How Would You Like to
`Pay for That?”, Digital Media, vol.4, No. 7, pp. 13-17.
`Candee Wilde, “Internet Security: A Moving Target”, Inter-
`active Age, May 13, 1996.
`B. Clifford Newman et al. “Requirements for Network
`Payment: The NetCheque Perspective”, pp. 32-36.
`
`
`
`F‘:
`must seszven wA1Ys eon
`TRUST
`venue»: REQUEST av wreeuer
`
`must semen RECEIVES
`1 auncu/«sen 5 0= ADDRESS AND
`1 nme sump TRANSACTVON mm
`1
`.1. Res» FROM venue»:
`CDMPUYER
`1
`may
`v__-__
`-1 puecwasea /
`‘ES /re-~s~«.~»oM1-
`
`1 TRUST seavew VER1FIE5{, ceenn or PURCHASER ,
`- - —‘
`or-‘euwe
`1
`i NO
`'
`rercu use»: 1/wmx seem DATABASE 1Js1NG ‘
`
`
`
`‘REGDI AS pcnmee ‘M 1 y
`\
`YRUSY seevea neremmues ex:-ecreo om ]
`/
`\
`= F2[REGIl,Y1ME swap usefi MAYRIX)
`WES
`/
`’ ‘ T\
`‘ox 7 ,‘
`_.
`,
`\
`YRUST sewer? GENERAVES um/mm =
`11
`r1mesu_r1»1e sm/us usen »memx1
`\ /
`1
`V
`TRUST senvea CONYACTS PURCHASER
`1
`cuenr AT 11: Aunfisss mu Expecrsn
`1I
`com mo oamws uwwqm
`_L
`11
`~
`1
`NO
`//UK],-mm:
`/\ UMAWH/\?.[ DECUNETRANSACHON
`1
`ES
`\\VW/
`TRANsAcT1oN AUTHORIZED
`1NFoRM PURCHASER-CLIENT or
`AUYHORVZATION smrus av
`wrener mnoueu OPEN vow
`-
`
`Reconu TRANsAcY1ON1N
`our/«ease
`weowm cfiemr
`CLEARINGHDUSE or
`YRANSACHON
`
`/
`Resrsvk/mow
`
`i
`
`L
`
`1
`1
`‘
`1
`
`‘
`
`1
`]
`
`]
`1
`
`1
`
`mu DECUNE COMMAND
`vo vuncmsen
`1
`cowuren
`TM?!
`- »
`—
`upon; mums; 7
`"
`TL
`1
`[
`
`Apple Exhibit 1032
`
`Page 00001
`
`Apple Exhibit 1032
`Page 00001
`
`
`
`tHCtaP“AU
`
`MM
`
`Nmoozms
`
`xx
`
`\ \\N\
`
`9E N\
`%:moozms:mmm:Q\
`
`.m:_E.o 525m:o=m:m_am_co_.m:m_mm_Mo:_Eo
`
`
`
`
`gmxxn........-\
`
`
`
`_mm:o:oz_m<m:o_-1.%.ew_m__m_@.:»«.0_u_mmwM.:ommow._
`1m«M_\sI1IlIIII,co_.mo_Em>R.m,
`
`E>mm_m
`
`2W
`
`Page 00002
`
`
`
`
`U
`
`m
`
`.\.....M_mm:o:uz_m<m:o__P_:85FIIaIII1I1L&/IuI1aII\V35=853
`
`mbums_mmm;..::a3mmzce
`
`mmmcezqAmWamoom\m:__omu6
`
`
`
`.333.mmmfiéaAm
`
`
`
`
`
`n.EW9M,xxm0w\nW,o._:_Em:mmmcezq£5,$92.83APs__mon_zm.>I__$2.
`
`3MM
`
`Page 00003
`
`
`
`
`3U
`
`m
`
`m
`
`09,5
`
`1
`
`
`
`%0o.._<._.<u.Ezmm:.z_.uz_.ms_o<
`
`
`
`
`
`
`
`$222.83m.Eouo.__mmum._o__o
`
`2moeV/yaNWNO_H_mma
`
`4
`
`Page 00004
`
`
`
`U.S. Patent
`
`May 11,1999
`
`Sheet 4 of 10
`
`5,903,721
`
`PURCHASER
`BROWSES FOR A
`TRANSACTION
`
`PURCHASER
`
`INITIATES
`TRANSACTION TO
`VENDOR
`
`VENDOR FORWARDS
`DATA TO TRUST
`SERVER
`
`/
`
`2
`
`5
`
`
`
`WAIT FOR TRUST
`SERVER
`
`
`
`
`
`
`TRUST SERVER
`VERIFIES CREDIT
`
`TRUST SERVER
`AUTHENTICATES
`PURCHASER
`
`
`
`NO
`
`DECLINE
`
`YES
`
`ALLOW
`
`TRANSACTION
`
`FlG.3
`
`Page 00005
`
`Page 00005
`
`
`
`U.S. Patent
`
`May 11,1999
`
`Sheet 5 of 10
`
`5,903,721
`
`
` PURCHASER EXECUTES
`(éaowse FOR TRANSACTION
`INTERNET BROWSING
`
`COMMANDS
`
`
`
`
`
`
`
`INTERNET BROWSER
`
`FORWARDS COMMANDS
`TO SELECTED VENDOR
`COMPUTER -
`
`
`
`
`VENDOR COMPUTER
`XMITS EMBEDDED WEB
`PAGES TO PURCHASER'S
`INTERNET BROWSER
`
`
`
`PURCHASER'S
`
`BROWSER DISPLAYS
`
`RECEIVED WEB PAGES
`
`TO PURCHASER
`
`
`
`
`
`CONTINUE
`HAS PURCHASER
`
`BROWSING
`FOUND A DESIRED
`
`TRANSACTION 7
`
`
`
`
`
`F|G.4A
`
`GOTO
`‘ ~\
`PURCHASE TRANSACTIW
`“Z
`
`
`
`Page 00006
`
`
`
`PURCHASER SELECTS DESIRED
`TRANSACTION BY CLICKING ON
`EMBEDDED CONTROL
`
`
`
`
`Page 00006
`
`
`
`U.S. Patent
`
`May 11,1999
`
`Sheet 6 of 10
`
`5,903,721
`
`
`
`PURCHASER'S
`
`sTART
`BROWSER ACTIVATES
`PURCHASE TRANSACTION
`
`PURCHASER-CLIENT
`SOFTINARE
`
`
`
`PROMPT USER FOR
`REGISTRATION #
`
`
` HRST
`TRANSACTION
`7
`
`PURCHASER-CLIENT
`
`GENERATES UMAN(P) =
`FHREG#fHMESTAMP,
`USER MATRIX)
`
`
`
`USER MATRIX =
`
`F3(UNIQUE H/W ID)
`
`
`
`
`
` PURCHASER-CLIENT
`OPENS PORT =
`UMAN = USER MATRIX
`
`F2(REG#, TIMESTAMP,
`TRANSMIT UMAN(P) TO
`
`USER MATRIX)
`TRUST SERVER VIA
`PORT WHEN
`
`REQUESTED BY
`
`TRUST SERVER
`
`
`
`
`
`
`
`PURCHASER-CLIENT
`TRANSMITS TO VENDOR
`SERVER COMPUTER VIA
`INTERNET HTTP REQUEST:
`
`TIMESTAMF’, TRANSACTION
`
`DATA. REG#
`
`
`
`
`
`
`CLOSE PORT
`
`
`
`WAIT FOR
`TRANSACTION
`STATUS FROM TRUST
`
`VENDOR /
`
` I
`
`L SERVER
`
`
`
`WAIT FOR TRUST SERVER
`DISPLAY STATUS TO
`COMMUNICATIONS
`USER
`
`
`
`
`Page 00007
`
`Page 00007
`
`
`
`U.S. Patent
`
`May 11,1999
`
`Sheet 7 of 10
`
`5,903,721
`
`VENDOR
`
`VENDOR WAITS FOR
`TRANSACTION FROM
`PURCHASER
`
`VENDOR COMPUTER
`
`RECEIVES TIME STAMP,
`TRANSACTION DATA 8: REG#
`FROM PURCHASER-CLIENT
`VIA INTERNET
`
`VENDOR OBTAIN'S
`PURCHASERS IP ADDRESS
`FROM HTTP HEADER AND
`
`SENDS WITH TIME STAMP,
`TRANSACTION DATA, & REG#
`TO TURST SERVER BY
`INTERNET
`
`FIG.4C
`
`Page 00008
`
`Page 00008
`
`
`
`U.S. Patent
`
`May 11,1999
`
`Sheet 8 of 10
`
`5,903,721
`
`FN
`TRUST SERVER WAITS FOR
`VENDOR REQUEST BY INTERNET
`
`TRUST SERVER RECEIVES
`PURCHASER'S IP ADDRESS AND
`‘TIME STAMP, TRANSACTION DATA
`& REG# FROM VENDOR
`COMPUTER
`
`REGISTRATION
`
`FIRST
`
`YES
`
`TRANSACTION BY
`PURCHASER
`
`
`
`No
`FETCH USER MATRIX FROM DATABASE USING
`REG# AS POINTER
`
`—_ — — 1
`I
`
`.—_.__!_____
`I TRUST SERVER VERIFIES:
`I CREDIT OF PURCHASER I
`OFFLINE
`,
`
`I
`I
`YES
`L _
`
`Y
`
`\
`
`/
`\
`CREDIT
`7 /
`/
`
`/
`
`\
`
`\
`
`\
`
`\ /
`NO
`
`I I I
`
`I
`
`: I
`
`TRUST SERVER DETERMINES EXPECTED ORT
`= F2(REG#,TIME STAMP, USER MATRIX)
`
`TRUST SERVER GENERATES UMAN(T) =
`F1(REG#,TIME STAMP, USER MATERIX)
`
`TRUST SERVER CONTACTS PURCHASER-
`CLIENT AT IP ADDRESS AND EXPECTED
`PORT AND OBTAINS UMANIP)
`
`DECLINE TRANSACTION
`
`xMIT DECLINE COMMAND
`TO PURCHASER
`COMPUTER
`
`UPDATE DATABASE
`
`
`
` UMAN(T) =
`UMAN(P) 7
`
`
`YES
`
`NO
`
`TRANSACTION AUTHORIZED
`
`INFORM PURCHASER-CLIENT OF
`AUTHORIZATION STATUS BY
`INTENET THROUGH OPEN PORT
`
`RECORD TRANSACTION IN
`DATABASE
`
`INFORM CREDIT
`CLEARINGHOUSE OF
`TRANSACTION
`
`FIG.4D
`
`Page 00009
`
`Page 00009
`
`
`
`
`
`
`
`mon2m>-mm>mmm-
`
`
`mz0_._.<o_z:s=2Oomm>mmw~.m>~w_mm.._,umw_._&_.n%._4ru.~__.,m_:..%_<,_oo
`
`
`U.S.Patent
`
`mmsmmm
`
`
`
`zo:o<wz<Emum:
`
`x_E.<E.IalnIl‘|.|1||:
`
`Z_<.2
`
`
`
`May11,1999
`
`
`
`
`
`5zoom;
`
`Sheet9of10
`
`zo_»8<wz<E
`
`mum:
`
`
`
`m:m<.pzo:o<wz<E
`
`mm>mmm5:5
`
`
`
` mon_zm_>:.E_mommonzm>Zr_
`
`5,903,721
`
`m.w_n_
`
`Page 00010
`
`
`
`
`
`moozm>z_<s_z_<s_
`
`
`
`
`
`mmo<z<s_mmusmmmmmo<2<s_
`
`
`
`m.o.<mE<nmmsmmmum<m<»<nmm>mmmzo:o<mz<Emm>mum
`
`Page 00010
`
`
`
`
`
`
`U.S. Patent
`
`May 11,1999
`
`Sheet 10 of 10
`
`5,903,721
`
`n=Eu._.
`
`Page 00011
`
`Page 00011
`
`
`
`1
`METHOD AND SYSTEM FOR SECURE
`ONLINE TRANSACTION PROCESSING
`
`BACKGROUND OF THE INVENTION
`
`This invention relates to online electronic commerce, and
`in particular to a secure methodology for approving an
`online transaction carried out over the Internet by authenti-
`cating the identity and credit of the purchaser without
`transmitting a credit card number or other payment means as
`part of the online transaction.
`The Internet is constantly expanding at a very high pace
`and has become one of today’s essential communication and
`information environments. But nevertheless, its potential as
`a facilitator of electronic commerce has not been fully
`realized. This is because today’s networks are not secure
`enough for transmitting sensitive financial
`information.
`Despite the constant development of new encryption
`methods, they are seemingly never beyond a hacker’s abil-
`ity. Most users do not even want to take the chance of
`someone eavesdropping on their credit-card number or even
`postal address as it is carried along even the most secured
`network communication paths. The biggest problem for
`electronic commerce today is users’ lack of trust and the
`psychological barriers to use of the Internet as a tool for
`commerce that arise therefrom.
`
`Prior art systems have been developed in an effort to meet
`this need; for example, a system has been proposed called
`Secure Electronic Transaction (SET). With SET-enabled
`software and an account with a financial institution that
`
`supports the system, a user can go to an Internet World Wide
`Web
`site, choose products to buy, and then order
`them with a few mouse clicks. The order is processed, the
`buyer’s identity and account are verified, and the transaction
`is complete. Whether it’s a checking or credit card account,
`or another payment system such as DIGICASH or FIRST
`VIRTUAL, it will be with a financial institution (such as
`MASTERCARD or VISA)
`that supports electronic
`payments, referred to as the Bank.
`When a user opens the account, he receives from the Bank
`an electronic file called a certificate, which acts like a credit
`card for on-line purchases. It contains information about the
`user, including a public key, it has an expiration date, and it
`has been digitally signed by the Bank to ensure its validity.
`On the other end, merchants doing business with the Banks
`also get certificates that include both the merchant’s public
`key and the Bank’s public key. This certificate also is signed
`by the Bank to indicate that the merchant is legitimate. The
`merchant’s key will be used for ordering, while the Bank’s
`key will be used for paying.
`The user indicates to the merchant what product or service
`he wishes to purchase via e-mail, through a Web page data
`transfer or the like. The following series of events is set in
`motion that takes a few seconds to complete. First, the user’s
`software receives a copy of the merchant’s certificate and
`verifies that
`it
`is dealing with a valid store since the
`certificate has been signed by the Bank. The user’s software
`sends the merchant three items, all of which have been
`signed: the order information, which is encrypted with the
`merchant’s public key; the payment information, which is
`encrypted with the Bank’s public key (thus, the merchant
`cannot see the payment information); and a message digest
`(a code containing information from both the payment and
`the order) that ensures that the payment can only be used for
`that order.
`
`the merchant checks the
`After receiving these items,
`user’s digital signature. The merchant validates the user’s
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,903,721
`
`2
`
`information with a third party (likely, but not necessarily, the
`Bank) to make sure the user is genuine. The merchant then
`sends the user a message indicating that the order has been
`received. The merchant also sends a signed message to the
`Bank using the Bank’s public key. This message includes the
`customer’s payment information (which the merchant can’t
`interpret) and the merchant’s certificate.
`The Bank first verifies that the merchant is legitimate,
`then checks the signature of the message it just received to
`make sure that the message is legitimate. The Bank then
`opens the enclosed payment information from the customer
`and verifies that it is good. The Bank also checks to make
`sure the payment information is for that merchant and that
`particular order. The Bank signs and encrypts an authoriza-
`tion to the merchant, which can then ship the goods.
`The SET system has been criticized for various reasons,
`one of which is the possibility that a keystroke stealing
`program that attaches itself to the keyboard drivers in a
`user’s computer can lay dormant until it is activated by the
`presence of a digital wallet program. It then records the
`keystrokes performed (before they are encrypted) and sends
`them to a third party. Such a phantom program could be
`disseminated inside a modified (but seemingly normal)
`electronic-commerce software package unknowingly dis-
`tributed by a financial institution.
`The SET methodology relied heavily on encryption,
`which is also another potential weakness. Certificates play a
`major part in SET’s security scheme. The parameter that
`gives the certificates mathematical resistance to decryption
`is the length of the original encryption key. SET certificates
`will use a key 1,024 bits long, which is felt to provide strong
`enough security. But, as with any encryption-based scheme,
`a hacker can break the code given enough time and com-
`puting power. The problem with a total reliance on crypto-
`graphic methods is that if they are decrypted,
`they fail
`totally. Worse, if decryption is performed by a third party
`and goes undetected by the legitimate users, a false sense of
`security ensues. Stronger security for electronic transactions
`must have some sort of backup mechanism in place, rather
`than simple faith in a particular encryption scheme.
`the
`In another prior art electronic commerce scheme,
`FIRST VIRTUAL system does not rely on any form of
`cryptography,
`rather it allows non-sensitive transaction
`information to travel over the Internet, while users’ credit
`card numbers are gathered by phone. In addition, there is a
`buyer feedback mechanism built atop existing Internet appli-
`cation protocols including e-mail, FTP, telnet, and the World
`Wide Web. Because those protocols carry no proof of
`identity, FIRST VIRTUAL uses a payment system based on
`e-mail call-backs. When asked to process a financial
`transaction, it looks up the buyer’s account and sends an
`e-mail message asking the buyer to confirm the validity of
`the transaction. The buyer can respond with “yes”, “no”, or
`“fraud”. Only when the buyer says “yes” is a financial
`transaction initiated.
`
`Moreover, FIRST VIRTUAL’s dependency on e-mail and
`the “VirtualPIN” avails itself to a potential hacker’s perusal
`for several reasons. First, e-mail is relatively easy to subvert,
`since it uses well known ports and can be “spoofed” or faked
`with simple tools and a rudimentary understanding of SMTP
`(Simple Mail Transfer Protocol). In addition, in the case of
`a slow e-mail gateway (such as that provided by most
`commercially available online services), mail delivery can
`take up to a day or more. Furthermore, the VirtualPIN is
`static and therefore can be impersonated.
`A different scheme for electronic payments was devel-
`oped by DIGICASH, based on a digital wallet containing
`
`Page 00012
`
`Page 00012
`
`
`
`5,903,721
`
`3
`
`tokens. The tokens are validated (digitally countersigned) by
`a bank, but the bank can’t trace the tokens to an individual
`user,
`
`None of the prior art systems provide a secure electronic
`commerce methodology sufficient to be carried out in large
`scale use over a non-secure network such as the Internet.
`
`Primary reasons for shortcomings of the prior art are the
`reliance on encryption as well as the transmittal of sensitive
`financial data over the Internet.
`
`It is therefore an object of the present invention to provide
`a secure methodology and system for approving an online
`transaction carried out over the Internet by authenticating
`the identity and credit of the purchaser without transmitting
`a credit card number as part of the online transaction.
`It is a further object of the present invention to provide
`such a system that does not rely on encryption for transmittal
`of data over the Internet as part of the transaction approval
`process.
`It is a further object of the present invention to provide
`such a system that utilizes a third party as a trust broker that
`has users (purchasers) and vendors pre-registered, so that the
`trust broker may validate the transaction by authenticating
`the user by utilizing data internally stored that is not trans-
`mitted over the Internet.
`
`SUMMARY OF THE INVENTION
`
`In accordance with these and other objects, provided is a
`method for executing a secure online transaction between a
`vendor computer and a user computer, wherein the vendor
`computer and the user computer are interconnected to a
`computer network for data communications therebetween.
`The method comprises the steps of the user computer
`transmitting a transaction request message to the vendor
`computer via the computer network, the transaction request
`comprising user identification data unique to the user com-
`puter; in response to receiving the transaction request, the
`vendor computer sending a transaction verification request
`to a trust server computer interconnected to the computer
`network, the transaction verification request comprising the
`user identification data and data indicative of the requested
`transaction; in response to receiving the transaction verifi-
`cation request, the trust server computer authenticating the
`user computer by using the user identification data and
`communicating with the user computer for verification with
`the user identification data; and the trust server authorizing
`the transaction when the authenticating step has passed.
`In particular, the user computer executes the transaction
`request by generating a user authentication number as a first
`function of a user registration number unique to the user
`computer, time stamp data correlated to the time of the
`transaction request, and an internally stored user matrix
`unique to the user computer; assigning a network protocol
`port number as a second function of the user registration
`number, the time stamp data, and the calculated user matrix;
`and transmitting a transaction request message to the vendor
`computer via the computer network, the transaction request
`message comprising the user registration number, the time
`stamp data, first data indicative of the requested transaction,
`and the network address associated with the user computer.
`The transaction verification request sent by the vendor
`computer to the trust broker comprises the user registration
`number, the time stamp data, second data indicative of the
`requested transaction, and the network address associated
`with the user computer. The trust server computer authen-
`ticates the user computer by calculating the user matrix by
`utilizing the received user registration number; generating a
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`trust server authentication number as a first function of the
`
`received user registration number, the received time stamp
`data, and the calculated user matrix; calculating an expected
`network protocol port number as a second function of the
`received user registration number, the received time stamp
`data, and the calculated user matrix. The trust server com-
`municates with the user computer by utilizing the user
`computer network address received from the vendor com-
`puter and the calculated expected network protocol port
`number. The trust server obtains from the user computer the
`user authentication number; it compares the obtained user
`authentication number with the generated trust server
`authentication number; and it indicates that the user com-
`puter is authentic when the comparison step has passed or
`indicates that the user computer is not authentic when the
`comparison step has failed, or the calculated port number is
`not available.
`
`The first function for generating the user authentication
`number comprises the step of synthesizing a user matrix as
`a third function of the calculated user matrix; and the first
`function for generating a trust server authentication number
`comprises the step of synthesizing a trust server user matrix
`as the third function of the calculated user matrix. Further,
`the first function for generating a user authentication number
`utilizes the user registration number and the time stamp data
`to extract the user authentication number from the synthe-
`sized user matrix; and the first function for generating the
`trust server authentication number utilizes the user registra-
`tion number and the time stamp data to extract the trust
`server authentication number from the synthesized trust
`server user matrix.
`
`Thus, as will be evident, the present invention is a novel
`online method of payment which will solve today’s elec-
`tronic commerce problems and utilize the Internet’s massive
`electronic commerce potential. The invention is a complete
`solution consisting of servers and clients which already have
`an existing trust relationship and therefore only need to
`communicate requests, and not financial data, in order to
`carry out online transactions.
`The system provides the ability to conduct secure elec-
`tronic commerce over the Internet without communication
`
`of sensitive or financial data. There’s nothing to encrypt and
`therefore there’s nothing to hack. Even if the online con-
`nection is eavesdropped,
`the information communicated
`over the wire is useless since it forms only part of the entire
`system, and is the product of a calculation, therefore it is
`dynamic as opposed to static information, which can be
`effectively reused.
`A user interested in a vendor’s product or service would
`simply access that vendor’s Web pages, which already
`incorporate embedded transaction request buttons. By doing
`that, client software would be automatically downloaded to
`the user’s machine. Once a transaction request button is
`clicked, a transaction takes place with no credit-card or
`address to type in. A few seconds pass from when a user
`initiates a transaction until it has been carried out.
`
`Finally, as an integral part of the trust server system, the
`user-client employs a multimedia interface. The transaction
`request button appears as an attractive animated figure.
`When clicked, the animation changes accompanied by audio
`effects. And when the transaction is approved, the animation
`changes once more accompanied by an audio effect such as
`“cha-chang!”
`Avendor needs a Web site in order to offer and engage in
`electronic commerce. In order to use the transaction authen-
`
`tication system, it registers with the trust broker via any
`
`Page 00013
`
`Page 00013
`
`
`
`5,903,721
`
`5
`
`preferred means (mail, fax, phone, or Internet). Then, it adds
`simple HTML tags to its Web pages, specifying information
`per each offered transaction. Auser hitting such a Web page
`would need the user-client software module as a browser
`
`add-on in order to view the page. Therefore, if it is not
`already installed, it will be automatically downloaded and
`installed on the machine in a matter of seconds.
`
`When a user requests to engage in his first transaction, he
`will have to register with the trust server via any preferred
`means (mail, fax, phone or Internet), and receive his User
`Registration Number. Upon entering this number and his
`chosen PIN in the user-client, a short introductory session
`takes place between it and the trust servers, which will later
`enable them to recognize each other online. After that, the
`first transaction can Lake place. Note that the PIN merely
`serves as a key to access the user-client, and is never sent
`over the wire.
`
`In order to request a transaction, a user simply has to click
`the embedded button and enter his PIN. After that everything
`is done automatically. The request is sent via the vendor to
`the trust servers. Upon receipt of the request,
`the trust
`servers authenticate the user’s machine using the same
`algorithm used by the user-client in order to verify its desire
`to carry out the transaction. After the user’s credit has been
`cleared and the user computer’s identity authenticated, the
`transaction is carried out and the status is shown to the user.
`
`All of this happens in a few seconds.
`The system accurately tracks all transactions taken place
`in a database, sending vendors and users daily or monthly
`reports of transactions in which they participated.
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`FIG. 1 is a top level system block diagram illustrating the
`communications of the present invention;
`FIG. 2 is a simplified block diagram showing a single
`transaction and the data flow between the parties;
`FIG. 2a illustrates a typical Web page displayed to the
`user for effecting the present invention;
`FIG. 3 is a top level flowchart of the method of the present
`invention;
`FIG. 4a is a detailed flowchart of the browsing function
`of the present invention;
`FIG. 4b is a detailed flowchart of the user transaction
`
`function of the present invention;
`FIG. 4c is a detailed flowchart of the vendor function of
`
`the present invention;
`FIG. 4d is a detailed flowchart of the trust server function
`
`of the present invention;
`FIG. 5 is an illustration of the software component
`architecture of the present invention; and
`FIG. 6 is a block diagram of the user computer function-
`ality for carrying out the present invention.
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`
`FIG. 1 illustrates a top level illustration of the system 10
`of the present invention. A plurality of user computers 12,
`designated USER1, USER2, .
`.
`. USERn are interconnected
`to the Internet 16 by any of various means known in the art
`such as a dial-up modem connection to an Internet Service
`Provider (ISP), a direct connection to a network that is in
`turn connected to the Internet, etc. The Internet 16 is a global
`network of interrelated computer networks allowing inter-
`change of information therebetween. Although the Internet
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`16 is used in the preferred embodiment, the invention is
`applicable to any computer network topology where secure
`transactions between interconnected computers are desired.
`Typically, a user computer 12 will be a personal computer in
`a home or business environment that accesses the Internet
`
`through a commercially-available browser client software
`package.
`A plurality of vendor computers 14 designated as
`VENDOR1, VENDOR2, .
`.
`. VENDORn are likewise inter-
`connected to the Internet 16 by any of various means known
`in the art. The vendor computer 14 may for example be an
`appropriate server running on a dedicated host connected to
`the Internet.
`A trust server 18 is also interconnected to the Internet as
`
`shown in FIG. 1, and acts as a trust broker for the purpose
`of approving a transaction between any user computer 12
`and any vendor computer 14, both of which must first be
`registered with the trust server 18 as will be described
`herein. The trust server 18 is shown with a dotted line
`
`connection to a credit clearinghouse 20, which does not form
`part of the present invention but which is accessed by the
`trust server 18 by any means known in the art (e.g. dial-up
`modem connection) to determine the creditworthiness of a
`user who requests a transaction from the trust server 18.
`Each of the user computers, vendor computers, and the
`trust broker may communicate with each other by commu-
`nication protocols well known in the art as applied to the
`particular network being implemented. Thus, for the pre-
`ferred embodiment Internet connections, the TCP/IP proto-
`col suite well known in the art will be implemented by each
`party to the transaction as described herein.
`FIGS. 2 and 3 illustrate the data flow between a user
`
`computer 12, a vendor computer 14 associated with a
`transaction desired by a user, and the trust server computer
`18. A user begins the process during a browsing session at
`step 1, where he downloads pages from various vendors via
`an Internet browser such as Netscape, until he views a page
`that describes an item he desires to purchase. As shown in
`FIG. 2a, the user makes a transaction request by selecting an
`item to be purchased at step 2 by using his mouse or other
`pointing device associated with the computer 12 to click on
`a control embedded within the screen page 22 and indicative
`of the item,
`for example in HTML (hypertext markup
`language) format. In FIG. 2a, the user selects the clock to
`purchase by clicking on the associated control 20. Selection
`of a transaction-enabled control will initiate internal pro-
`cessing to be described below, and a transaction request
`message is transmitted by the Internet to the selected vendor
`computer 14 in known Internet protocol methodology. The
`user computer 12 then goes into a temporary wait state
`pending a subsequent is communication from the trust server
`18.
`
`The vendor computer 14, upon receiving the transaction
`request message from the user computer 12, sends an image
`of the transaction request to the trust server 18 via the
`Internet at step 3. Along with the transaction request image,
`the vendor computer 14 sends to the trust server 18 the IP
`network address of the requesting user computer 12, which
`will allow the trust server 18 to authenticate the identity of
`the user computer 12 prior to authorizing the transaction.
`The vendor computer 14 is finished with processing for this
`transaction and thus waits for another transaction request
`from another user.
`
`The trust server then carries out two independent func-
`tions at substantially the same time in order to expedite the
`transaction request approval. One function, shown as step 4,
`
`Page 00014
`
`Page 00014
`
`
`
`5,903,721
`
`7
`is to communicate with the credit clearinghouse by any
`means known in the art, e.g. through a direct dial-up modem
`connection, in order to determine the creditworthiness of the
`user for the requested transaction. The trust server 18 knows
`the identity of the user and the amount of credit required to
`approve the transaction from data contained within the
`transaction request. If the credit clearinghouse does not
`approve the request for credit reasons, then the trust server
`18 declines the transaction request and notifies the user
`accordingly. The vendor need never be notified in the case
`of a declined transaction.
`
`At the same time, at step 5, the trust server 18 performs
`internal processing and data communications with the user
`computer 12 in order to authenticate the identity of the user
`computer 12 and approve the transaction. The trust server 18
`knows the IP address of the user computer 12 from the data
`transmitted by the vendor computer 14. The trust server 18
`obtains a piece of data, called the user matrix authentication
`number (UMAN), and compares it to a trust server matrix
`authentication number (TSMAN) that was calculated inter-
`nally as a function of the user’s identity. When the respective
`matrix authentication numbers match, then the user is con-
`sidered to be authentic, and the transaction is approved at
`step 6.
`Thus, the triangulation methodology of the present inven-
`tion for approving a transaction request is apparent from the
`three-party process illustrated in FIG. 2. The user computer
`12 and vendor computer 14 are both pre-registered with the
`trust server 18, which acts as a trust broker performing trust
`and authentication services. The vendor has trust in the trust
`
`server 18 and relies on its method of authenticating the user,
`since it knows that the trust server 18 will only allows
`transactions requested by registered users. Sinc