United States Patent
`
`[19]
`[11] Patent Number:
`5,903,721
`
`Sixtus
`[45] Date of Patent:
`May 11, 1999
`
`USOOS903721A
`
`[54] METHOD AND SYSTEM FOR SECURE
`ONLINE TRANSACTION PROCESSING
`
`[75]
`
`Inventor: Timothy Sixtus, New York, NY.
`.
`_
`_
`[73] Assrgnee: cha!Techn0]0g1es Serv1ces, Inc., New
`York, NY
`
`[21] Appl.No.:08/816,410
`[22]
`Filed:
`Mar. 13, 1997
`
`Int. Cl.6 ...................................................... G06F 13/00
`[51]
`[52] US. 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
`
`[56]
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,416,842
`575577518
`3922393;
`5,678,041
`5,684,950
`5,684,951
`5,754,761
`5,758,069
`
`5/1995 AZiZ .......................................... 380/30
`
`9/1996 R056“ ~~~~~~~~~~~~~
`364/408
`
`;;133; Tigrigreétazlal ‘
`395322/7281
`
`10/1997 Baker et a1.
`..... 395/609
`
`11/1997 Dare et a1. .............. 395/187.01
`
`. 395/188.01
`11/1997 Goldman et a1.
`
`5/1998 Willsey ................ 395/186
`5/1998 Olsen ................................. 395/187.01
`OTHER PUBLICATIONS
`
`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.
`
`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. 2349.
`David Chaum et al., “Minting Electronic Cash”, IEEE
`Spectrum, Feb., 1997, pp. 31—34.
`Peter S. Gemmell, “Traceable e—Cash”, IEEE Spectrum,
`Feb” 1997, pp. 35—37.
`Robert W. Baldwin et al., “Locking the e—Safe”, IEEE
`Spectrum, Feb., 1997, pp. 40—46.
`
`Primary Examiner—Joseph E. Palys
`Assistant Examiner—Norman Michael Wright
`Attorney, Agent, or Firm—Anthony R. Barkume
`[57]
`ABSTRACT
`.
`.
`.
`A method for executing a secure onlme transactlon between
`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 comprises the steps of the
`user computer transmlttmg a transactlon request message .to
`the vendor computer v1a the computer network, the financ1al
`transaction request comprising user identification 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-
`tieating step has passed.
`
`11 Claims, 10 Drawing Sheets
`
`
`Amust SERVER WMYS FOR
`TRUST
`
`VENDOR REQUEST av INVERNET
`
`must SERVER RECEIVES
`
`
`
`V PURCHASER s11a ADDRESS AND
`1 TIME sump TRANSACTYON mm
`
`1
`1. R55» FROM VENDOR
`CDMPUYER
`1
`
`_ TR‘NSAWQM 7 _ » 7
`REGr$7RAT1oN
`1 TRUST SERVER VER1FIES
`l
`‘ ”MESS“ /
`\_//
`‘ CREDIY or PURCHASER ]
`1
`NO
`omwe
`,
`FEYCH USER MATRIX FROM DATABASE USVNG ‘
`1
`
`
`
`‘REG» AS PomrER ]g 1 1
`
`\
`may SERVER nemwmes ExPEcTED cm 1
`/
`, I 4 mam \
`= Fzmseumz STAMP USER MArRrx)
`[VES
`/
`\
`\
`ox '7 ,
`_,
`/
`\
`YRusT SERVER GENERAVES uwwm =
`11
`nmssmm: sums USER MAYERIX]
`\ /
`1
`V
`TRusT SERVER conucrs puncmsanr
`|
`CLIENT Ar 11: ADDRESS AND EXPECYED
`1I
`wow mo oamws ummm
`
`—1‘
`/
`
`V?“/ M N“ \—_Wo
`DEC NE TRANS/my o,
`\ MN (p, 7/
`\ ,9
`
`
`\VrvEs
`TRANSACWON AUTHORIZED
`‘
`)(MIY DECLVNE COMMAND
`m vURcHAsER
`comma;
`1
`wow nuncmsamusm o1:
`AumoszIoN smug av
`
`
`J
`111mm maoueu OPEN Pom
`mm mmsmm 1N
`L
`DAYAEASE
`CLEARINGHOUSE or
`mmsrcnow
`
`’7
`
`1
`]
`‘
`
`
`
`
`
`‘
`
`1
`1
`
`]
`1
`
`
`
`Apple Exhibit 1037
`
`Page 00001
`
`
`
`
`UPDATE DATABAsE
`1
`, »
`7
`W
`——L
`l
`1
`
`Apple Exhibit 1037
`Page 00001
`
`

`

`US. Patent
`
`May 11, 1999
`
`Sheet 1 0f 10
`
`5,903,721
`
`fix
`
`Nmoozm>
`
`\x
`
`cmoozm>
`
`\\N\
`
`_‘mcozm>v1mm:
`
`
`
`25:025:0
`
`
`
`cozmbmam:%\522%,”:
`
`mm>mmm535
`
`
`\IIIIIIIIIcozmoctg
`
`
`
`
`"mmaozozE/md“-.$12203070—”—_tommo_+111111
`
`_
`
`Page 00002
`
`Page 00002
`
`
`

`

`US. Patent
`
`May 11, 1999
`
`Sheet 2 0f 10
`
`5,903,721
`
`mwaozwzifid
`
`:85_
`
`
`
`“8.623283Am
`
`
`
`bumsmemcezaAm
`
`amooSmEUmu6
`
`am;APcmoozm;IC$2.
`
`25Em:8283£5,3me
`
`
`
`“$323222.Am
`
`Page 00003
`
`Page 00003
`
`
`
`

`

`US. Patent
`
`May 11, 1999
`
`Sheet 3 0f 10
`
`5,903,721
`
`NW
`
`«~de
`
`
`
`32.2.58“nineuohmauni=0
`
`.02_£204.
`
`
`
`00.2.20hmzmMHE
`
`Page 00004
`
`Page 00004
`
`

`

`US. Patent
`
`May 11,1999
`
`Sheet 4 0f 10
`
`5,903,721
`
`PURCHASER
`BROWSES FOR A
`TRANSACTION
`
`PURCHASER
`
`INITIATES
`TRANSACTION TO
`VENDOR
`
`SERVER
`
`/
`
`2
`
`5
`
`
`
`WAIT FOR TRUST
`SERVER
`
`VENDOR FORWARDS
`DATA TO TRUST
`
`
`
`TRUST SERVER
`
`TRUST SERVER
`AUTHENTICATES
`
`VERIFIES CREDIT
`
`
`PURCHASER
`
`
`
`NO
`
`DECLINE
`
`YES
`
`ALLOW
`
`TRANSACTION
`
`FIG.3
`
`Page 00005
`
`Page 00005
`
`

`

`US. Patent
`
`May 11,1999
`
`Sheet 5 0f 10
`
`5,903,721
`
`
` PURCHASER EXECUTES
`
`INTERNET BROWSING
`(\BROWSE FOR TRANSACTION
`
`
`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
`
`
`
`
`FIG.4A
`
`
`
`
`
`
`GOTO
`‘\\
`PURCHASERSELECTSDESRED
`
`PURCHASETRANSAcngy)
`TRANSACTKMIBYCLmKnusoN
`
`/
`EMBEDDEDCONTROL
`\\‘___d//_
`
`
`Page00006
`
`Page 00006
`
`

`

`US. Patent
`
`May 11,1999
`
`Sheet 6 0f 10
`
`5,903,721
`
`
`PURCHASER'S
`
`START
`
`
`BROWSER ACTIVATES
`PURCHASE TRANSACTION
`
`
`
`PURCHASER-CLIENT
`SOFTWARE
`
`PROMPT USER FOR
`REGISTRATION #
`
` HRST
`TRANSACTION
`7
`
`
`
`
`
`
`
`PURCHASER-CLIENT
`
`
`
`
`GENERATES UMAN(P) =
`FHREG#KHMESTAMP,
`USER MATRIX)
`
`USER MATRIX =
`
`
`
`F3(UNIQUE H/IN 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#
`
`
`WAIT FOR
`
`
`TRANSACTION
` ,mI
`
`STATUS FROM TRUST
`
`‘ SERVER
`VENDOR /
`
`WAIT FOR TRUST SERVER
`
`DISPLAY STATUS TO
`COMMUNICATIONS
`USER
`
`
`
`
`CLOSE PORT
`
`
`
`
`
`Page 00007
`
`Page 00007
`
`

`

`US. Patent
`
`May 11,1999
`
`Sheet 7 0f 10
`
`5,903,721
`
`VENDOR
`
`FIG.4C
`
`VENDOR WAITS FOR
`TRANSACTION FROM
`PURCHASER
`
`VENDOR COMPUTER
`
`RECEIVES TIME STAMP,
`TRANSACTION DATA 8: REG#
`FROM PURCHASER-CLIENT
`VIA INTERNET
`
`INTERNET
`
`VENDOR OBTAIN'S
`PURCHASER'S IP ADDRESS
`FROM HTTP HEADER AND
`
`SENDS WITH TIME STAMP,
`TRANSACTION DATA, & REG#
`TO TURST SERVER BY
`
`Page 00008
`
`Page 00008
`
`

`

`US. Patent
`
`May 11,1999
`
`Sheet 8 0f 10
`
`5,903,721
`
`A
`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
`
`
`
`NC
`FETCH USER MATRIX FROM DATABASE USING
`REG# AS POINTER
`
`__ _ _ .l
`I
`
`~—.__!._———
`I TRUST SERVER VERIFIES:
`I CREDIT OF PURCHASER I
`OFFLINE
`,
`
`I
`I
`YES
`I_ _
`
`Y
`
`\
`
`/
`\
`CREDIT
`OK 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
`
`

`

`US. Patent
`
`May 11, 1999
`
`Sheet 9 0f 10
`
`5,903,721
`
`
`
`
`mzo_h<o_z:s_:oomm>mmw
`meE.20:.o<wz<m._.
`
`zO_._.o<wz<m._.
`
`
`mm>mmmw20_._.<0_2:s_s_oo
`mmmz-mm>w_mw
`
`mm>mmwHwawt.
`
`FODOONE
`
`
`
` mOQZm>—hmiommOnzw>_r_
`
`de
`
`Page 00010
`
`mum:
`
`
`
`
`
`moozm>z_<s_z_<s_
`
`
`
`$553$55..»$553mm>mmm20.5525:mm>mMm
`
`m002m>-mm>mmw
`
`mmSmmm
`
`ZO_._.O<wZ<m._.
`
`
`
`Z_<S_
`
`
`
`mwwD
`
`WIIIIIIII
`
`X_m._.<_2
`
`j'llllll‘llj
`
`
`
`
`
`$33.2$23.3mmw<2<s
`
`
`
`
`
`
`
`
`
`
`
`Page 00010
`
`
`
`
`
`
`

`

`US. Patent
`
`May 11, 1999
`
`Sheet 10 0f 10
`
`5,903,721
`
`n=EU._.
`
`Page 0001 1
`
`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 (WWW) 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
`
`Page00013
`
`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. Since the users
`are pre-registered with the trust server, the trust server can
`request a