CA2405847A1 - A method and system for a virtual safe - Google Patents

Abstract

A transaction server for performing a transaction over a network using a virtual smart card the server comprising, a virtual smart card database having a plurality of records each record including a virtual card identification and a value corresponding to a single virtual smart card; a security module; an emulator for emulating a smart card, the emulator for receiving smart card commands and processing the commands in conjunction with the virtual smart card database and the security module; and a virtual card reader module for receiving the smart card commands and relaying the commands to the smart card emulator whereby transactions are performed over the network using one or more the records and the virtual smart card database.

Description

19-0.7-2002 . CA 02405847 2002-10-10 ~ CA0100504 A. METHOD AND S~.'S'TEIVI FO~t A'~'.ITtTUAG SAI~'E
The invention relates to the field of electronic commerce systems, and mare specifically to secure electronic commerce systems employing virtual smart cards.
BACKGROUND OF THE rN"VENTION
~ With the rapid increase in the number of consumers, having access to the World Wide Web, a corresponding need for conducting commerce over the Internet has emerged. .
However, concerns with online security have undermined the evolution of electronic commerce as security issues have affected the required level of oust between online retailers and corisumers_ In traditional business transactions, trust is established face-to-face and supported by documentation that reduces liability. Today, traditional business transactions are being transformed. In particular, the use of smart cards. is expanding, further affecting the Level of Trust retailers and consumers have in electronic commerce.
A smart card, ' also called a chip card, integrated circuit card, memory card or processor card, is typically a credit card-sized plastic card that includes one or more integrated circuits. A smart card can interface with a point-of sale terminal, an ATM, or with a card reader integrated with a computer,'telephane, vending machine, or a variety.of other devices. A srilart card may be programzrted with various,types of functionality such as stored-value applications, credit or debit applications, loyalty 2U applications, cardholder inforn3ation, etc. Although a plastic card is currently the medium of choice for smart cards, it .is possible to implement these cards using a , smaller form factor.-For example, a smart card..could be attached to a key chain or. it could be as small as a single integrated circuit chip. A' smart card may also be implemented as dart of a personal digital assistant, telephone, or some other form.
ZS Typically, to increase user trust, a smart card contains a hardware encryption module for petforming a variety of encryption algoiithms_ Encryption may also be performed in software. A typical process for issuing smart cards and far reconciling transactions performed with these cards in the consumer context may be described as follows. A
AMENDED SHEET

19-07-2002 . CA 02405847 2002-10-10 CA0100504 terminal supplier builds the equipment used by a service provider, to prgvide goods and/or services to consumers via smart card and service payment terminal. A
card supplier contracts with an integrated circuit manufacturer and a card manufacturer for integrated circuits and plastic card bodies, respectively. The card supplier then emlxeds the integrated circuits zn'the cards and initializes them with a serial number.
The card supplier then delivers these cards to a card issuer. in conjunction with a clearing and administration system, the card issuer personalizes new cards and then transfers these cards to individual cardholders (l.c. consumers). A cardholder may then charge the card with value prior to use. tllternatively, the card may be delivered with value pre-loaded. The cardholder nay then use the card at a service payment terminal to purchase goods andlor services from the service.provider. Upon purchase, the terminal debits the value of the purchase from the card, thus creating a service payment. The system may be implemented, for example, using Visa, MasterCaTd, American Express, ~f7iscovery, Players Card Tnternational, bank and financial I 5 institution debit cards, and other cards.
In this typical process, all transactions are sent in a data file from the service payment terminal, via an acquirer, to a clearing and administration system..
Accumulated 'service payment batches ' from other terminals are also sent to the clearing . and administration system. $ased upon this ~ collection data, the - clearing and administradan system receives money from the card issuer. The money received.
from the card issuer,. of course, originates from ~ the cardholder. The clearing and administration system then, transfers a lump stctn to the acquirer using a suitable settlement service (e.g. Visa, MasterCard American Express, piscovery, Players Card International, etc.) to. pay the various service providers having a relationship with the acqctirer. Based upon the collection data, the acquirer then transfers an appropriate amounE of, money to each service provider reflecting the value of the goods and services that that service pTOVider provided to cardholders that period (e.g.
day}. The value of the goads and services provided is based on deductions from cardholders' smart cards:
3Q . A consumer typically uses a service payment terminal in a face-to-face context in order to purchase goods at a store ox directly from the terminal itself. The service .

AMENDED SHEET

payment terminal eau be an attended device or it can be integrated into a self service device such as a v~ding machine or public telephone. For example, the service payment terminal may be incorporated into a soda machine in order to dispense sodas to a customer where the customer pays by inserting a smart card. Or, the service payment terminal may be a point-of sale (P(aS) terminal typically found at the check.
alit C0lulter OI a Store.
In general, service payment terminals allow consumers to use smart cards for the payment of goods and services. A service payment terminal generates a payment result from a transaction and bundles individual payment results into a collection for transfer to a eleariag and administration system. The service payment terminal then transfers funds debited from consumers' smart card to the merchant whose goods and services were purchased through the terminal. Thus, a variety of goods and services may be purchased using a smart card from a merchant having a service payment terminal on premises. In addition, a consumer with a smart card may purchase goods 1~ or services from a merchant over the Internet.
Now, in order to purchase a product or service with a smart card, the card must fast be loaded with value or with an identity. Typically, "stored-value" cards are loaded with value while "debit" acrd "credit" smart cards are loaded with the identity of the card holder. lX~ith respect to stored-value cards, value can be loaded onto the card in a variety of ways. For example, while ineotwenient for the consumer, the consumer may physically travel to a bank or other institution that has an automated teller machine (ATM), or other Similar device, in order to load value onto the smart card.
RTith respect to loading value onto a smart card, the consumer may insert money into a value loading machine and have a corresponding value loaded onto the card.
Or, the consumer may use a debit card to deduct value from the consumer's bank account for transfer to the card. Additionally, a credit card can be used as the source of value. Tn these examples, the consumer must travel to the bank to load value. .A further iucnnvenience exists in that not all banks have value loading machines. To overcome this inconvenience, a method by which consumers may load value onto their smart 3D cards via the Internet has been proposed aad is described in '~(J.S. Patent Application AMENDED SHEET

' 19-07-2002 , CA 02405847 2002-10-10 CA0100504 No. 09/~7C1,488 (Davis, et al.), filed April 30, 1998, and entitled "lntexnet Loading System Using Smart Card", which is incorporated herein by reference.
One disadvantage of current smart card systems is that they are dependent on the use of two- hardware components new to the mass consumer market: smart cards and S smart card readers. Without having large numbers of smart cards and card readers in use, there is little demand for them from consumers, which in turn makes it difficult to convince merchants to adopt these systems.
A need therefore exists for an electronic commerce system that does not require the prior deployment ~ of physical smart cards and smart card readers. Such a system would allow merchants and issuers to establish a market presence that would in turn facilitate the acceptance of physical smart cards anal card readers as They become morc widely available.
With respect,to the issue of trust, for electrotxic commerce, crust must be established in seconds between stxangers who axe physically separated. Effective secuzity is based I 5 on the unequivocal authentication of authorized parties.
h~iethods for providing authentication include digital signatures, the public key infrastructure (PK'~, and elecuonic payment policies such as X9.59. However, the traditional digital' signature model is a complex and computationally expensive process when apQlied to mainstream business ' transactions over the Internet.
The ?0 traditional di~,ital sigaature model was not developed specifically fvr today's business tiansactions or a secure means to conduct electronic ct~ntmeree that takes into account the infrastructure and business processes already in place within the financial sector to .
ensure trtest in financial. taansactions. On the other hand, the PKI model does provide stiong authentication. In addition, the financial.industry's X9.59 policy, is a light-25 weight, high integriity, strong authentication payment protocol targeted for all methods of electronic paymem including, but mat limited to, set-top boxes, point-of sale terminals with online authorization, and merchant web servers. With the appropriate smart card, X9.53 can work at point-of sale, even improving the integrity of the AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 current POS infrastructure, while eliminating the necessity for any identity information in payment transactions.
A need therefore exists for an electronic commerce system with effective authentication suitable for today 's business transactions.
S Finally, in addition to being secure, modern electronic camtnerce systems must protect individual privacy without impeding legitimate inquiries by law enforcement and government agencies. Typically, to improve privacy, a modern electronic commerce system must be relatively anonymous for the user.
rn summary, smart cards require information be recorded on them. In the case of 1U stored-value cards, a monetary value must be downloaded io the card. In the case of a debit or credit cards, an identity mast be securely transferred to the card.
Hence, a need exists for an electronic commerce system that has eFfective online authentication and that ~ includes the benefits of physical smart card but that operates in a virtual environment. Zn addition, a need exists for an electronic commerce systenZ
that 15 provides the benefits of card present transactions in the context of remote networks and the Internet. Feuthermore, a need exists far an elecAconic commerce system that can reduce costs associated with current systems with respect to card distribution, reader distribution, axed connectivity. Moreover, a need exists for an elecaconic commerce system that provides effective authentication, security, and privacy.
20 A need therefore exists for an iiuproved electronic commerce system.
Consequently, it is an. object of the present invention to obviate or mitigate at Ieast some of the above-mentioned disadvantages.
summit of ~ lr~rrr~oN
25 The invention provides a system for conducting secure electronic commercs transactions ovex netwatlcs with virtual smart cards.
_5, AMENDED SHEET

19-0.7-2002 CA 02405847 2002-10-10 CA0100504 According to one aspect of the invention, a method for performing a secure electronic cor~uuerce transaction over a network using a smart card is provided. With respect to the method: the network, has a client terminal, a merchant server, a payment server, and an authentication server; the smart card being a physical smart card or a virtual smart card; the smart card being associated with a user at the client terminal; the smart card having associated smart card information; the smart card information including an account balance; and, the smart card znformatit~n beipg stored at the client terminal and at the auxhexttication server. The method includes the steps of:
sending a transaction request message from the client terminal to the merchant server identifying a product for the transaction, the product hsving associated product information, the product inforrttation being displayed an a first web page supported by the merchant server, tile user being able to view the web page at the client terminal using a browser;
sending transaction information from the merchant server to the client terminal itt response co the transaction request message, the transaction information being contained in a second web page generated, by the merchant server apd displayable to the user through the browser, the transaction information including a price for the product, an 1P address of the payment server, a trans~ctian identifier, and a merchant identifier, the transaction identifier for ~ : tracking the transaction by the merchant server and by the payment server, the merchant identifier for tracking the transaction by the client terminal and the payment server;
receiving a user identifier and a PIN from the user at the client texminal far authorizing the transaction;
seeding the user identifier, the PIN, and the transaction information from the ciienr tc;rmirial to the authentication server;
comparing the price of the product to the account balance for the smart card at the . authenricatiou server to determine if the transaction can proceed, the account balance being stored at the authenrication server and being accessed AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 using the user identifier and the PITT, the transaction being terminated and a first termination message being sent from the authentication server to the client terminal for display to the user if the price exceeds the accotant balance by a predetermined amount;
sending a draw request message fxom the authenticatioil server to the payment .
server using the IP address of the payment server, the ~xaw xequest message containing the transaction information;
sending the draw request message from the payment server to the client terminal;
, sending a debit request message from the client terminal to the payment server in response to the draw request message, the debit request message iacluding a fZrst digital signature, the first digital signature fQr verifying that , the debit request message originated from the client terminal, the first digital signature being generated at the client ternunal using the smart card ipforrnation stored ~ . at the client terminal; .
sending the debit request message from . the payment server to the authenrication server;
comparing at the authentication server the first digital signature contained in the debit request message to a fast check digital signature generated at the authentication se,~er using the smart card information stored at the authentication server to determine if the transaction can proceed, the transaction being terminated and a second termination message being sent from the authentication server to the client terminal for display to. the user if the first digital signature does not match the first check digital signature;
~ updating the. smart card information by debiting the account balance by the price to produce an updated accotnzt balance and storing the updated account balance at the authentication server;
AMENDED SHEET

19-0.7-2002 . CA 02405847 2002-10-10 CA0100504 sending a ~ debit iesponse message from the authenutation server to the payment server, the debit response message including a second digital sigctature; the second digital signature for verifying that the debit response message originated fr4m. the authentication server and for verifying that the account balance has been debited, the second digital.signature being generated at the authentication server using the smart card 'information stored at the authentication server;
sending the debit response message from the payment server to the client terminal; ' .
comparing at, the client terminal the second digital signature contained in the debit response message Lo a second check digital signature generated at the client terminal using the sri~art card information stored at the client terminal, the smart card information stored at the client terminal including. an expected updated account balance, to determine if the transaction can proceed, the ~ transaction. being terminated and a third termination message being displayed to the user if the second digital signature does not ixiatch the .second check digital signature;
updating the smart card information by debiting the account balance by the price to produce an c~pdated account balance and storing the updated account balance at the client terminal;
sending a~ verification response message from the client terniinal to the payment server, the verification response message including an indication that the. second digital signature matches the second check digital signature and that the transaction can proceed;
2S logging the indicatiait and the transaction information at the payment server;
sending a debit result message from the payment server to the authentication server, the debit result rizessage for confirming~that the transaction has been _g_ AMENDED SHEET

19-0.7-2002 . CA 02405847 2002-10-10 CA0100504 logged and that the transaction can proceed, the debit result message including the indication and the transaction information;
logging the debit result message at the authentication server;
sending the debit result message from the authentication server to the client S terminal to confirm ' that the transaction. has been logged and that the transaction can proceed;
sending the debit result message from the client terminal to the merchant server to confirm that the transaction has been logged and that the product can be reteased to the u.~~ez~; ansl, sending a purchase receigt message from the merchant server to the client . . . terminal, the purchase receipt auessage indicating that the product h.as been released to 'the user, thereby completing the secure electronic commerce transaction.
According to another aspect of the invention, the network is the Internet.
According to another aspect of the invention, the debit result message is encrypted.
According to another aspect of the invention a transaction server is provided for performing a transaction over a netwozk using a virtual smart card_ The server includes:
a) a virtual sztiart card database having a .plurality of records each record including a wirtuai card identification at~d a value corresponding to a single virtual smart card;
b) a security module; ' c) an emulator far emulating a strtart card, the emulator for receiving smart card commands and processing the commands in conjunction with the virtual smart card database and the security module; and _~_ AMFNI~FII ~NFFT

19-07-2002 . . CA0100504 d) a virtual card reader module for receiving the smart card carrzmands and relaying the commands to the smart ' card emulator whereby transactions are performed -over the network using . one or more the records and the virtual smart eared database.
According to another aspect of the invention, a method for performing a transaction over a network using a virtual smart card and a server is provided. The method includes the steps of;
a) creating~a plurality of records on a v~ircual smart card database, each record including a virtual card identifier and a value corresponding to a single virtual smart card;
b) receiving smart card commands via a smart card emulator and processing the commands in - conjunction with the virtual smatr card database and a security module; and c) receiving the smart card commands via a~ virtual card reader module and relaying the commands to tire smart card emulator whereby transactions are perfoxrned over the network using the server and one or more of the records in the v~irttxal smart card database.
According to another aspect of the invention, the server's security-module includes a plurality of encryption algorithms.

BRIEF DfiSCRIFTIC3IV OF THE 1~RA~iN~S
Embodiments of the inventiomnay best be understood by referring to the following description -and accompanying drawings. Ia- the description and. drawings, like numerals refer to like structures or processes. In the drawings:
FTG. 1 is a block diagram illustrating ~inualSAFE software modules in accordance with ors embodimeat of the inveriziob;

AMENDED SHEET

19-07-2002 CA 02405847 2002-10-10 ' CA0100504 b'IG. 2 is a flowchart illustrating the operation of the secure remote pointer component of VirtuaISAFIr in accordance with an embodiment of the invention;
FIG. 3 is a flowchart illustrating the steps for user enrollment in VimialSAFE
in the general case in accordance with an embodiment of the invention;
FIG. 4 is a flowchart illustrating the steps for user enrollment in VirnzaISAFE in a second case in accordance with an embodiment of the invention;
FIG. 5 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in. a third casein accordance with an embodiment of the invention;
FIG. 6 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in a 10. fourth case in accordance with an embodiment of the invention;
FiG. 7 is a flowchart illustrating the steps for user enrollment in VinuaISAFE
in a fifth case in accordance with an embodiment of the invention;
FIG. S is a tlawchart illustrating the steps' for user enrolhnent in VirtualSAFF in a sixth case in accordance with an embodiment of the invention;
FIG. 9 is a flowchart illustrating the steps for user enrollment ir<
VirtualSAF1= in a seventh case in accordance with an embodiment of the invention;
FIG. 10 is a flowchart illustrating the steps for user enrollment in VirtualSAFE in an eighth case in accordance with an embodiment of the invention;
FIG. 11 is a flowchart illustrating the steps far user enrollment in VirtualSAFE in a 2(? ninth case in accordance with an embodiment of the.invention;
FIG. 12 is a flowchart illustrating CA process steps in VirtualSAFF .in accordance with an emmbodiment of the invention; .
FIG. 13 is a block diagram illustrating participants and_their contractual relationships in VirtualSAFF in accordance with an embodiment of the invention; .

AMENDED SHEET

! 9-07-2002 CA 02405847 2002-10-10 CA0100504 FIG. 14 is a block diagram illustrating the enrollrrient process in.
VirtualSAFE in accordance with an embodiment of the invention;
FIG. 15 is a block diagram illustrating the online transaction process in VirtualSAFE
in accordance with an embodiment of the invention;
FIG. I6 is a block diagram illustrating the serves authentication process in VirtualSAFE in accordance with an embodiment of the invention;
FIG. 17 is a block diagram illustrating the computer authentication process in VircualS~lFE in accordance with an embodiment of the invention;
FIG. 18 is a block diagcarn illustrating the user authentication process in VirtualSAFE
l 0 in accordance with an embodiment of the invention;
FIG. 19 is a block diagram illustrating the back-end authentication process in VirtuaISAFE in accordance with an embodiment of the invention;
FIG. 20 is a block diagram illustrating the fulfillment process in VirtualSAFE
in accordance with an embodiment of the invention;
15 FIG. 21 is a block diagram illustrating the attribute authentication.
authority process in VirtualSAFE in accordance with an embodiment of the invention;
FIG: 22 is a block . diagram illustrating the virtual identity {VI) process in 'VirtualSAFE in accordance with an embodiment of the invention;
F1G. 23 is a block diagiam illustrating the virtual . smart card {VSC) process, in 20. VirtuaISAFE .in accordance with an embodiment of the invention;
FIG. 24 is a block diagram illustrating the VirtualSAFE deposit box (VSDB) process in VirtualSAFE in accordance with an embodiment of the invention;
FIG. 25 is a block.diagram illustrating the point-of sale {PAS) and virtual smart card (VSC) emulation process in YirtualSAFE in accordance with an embodiment of the 25 ~ invention;

AMENDED SHEET

19-07-2002 : CA 02405847 2002-10-10 ~ CA0100504 FIG. 26 is a black diagram , illustrating the ATM and virtual smart card (VSC) emulation process' in VirtualSAFE in ~ accordance with an embodiraent of the invention;
FIrr. 27 is a block dia,~cam illustrating the wireless POS and ATM process in S VirtualSAFE in accordance with an embodiment of the invention;' FIG. 28 is a block diagram illustrating the SAFEcheck process in VirtuaISAFE
in accordance with an embodiment of the invention;
FIG. 29 is a block diagrarA ~illustrtting physical access control in VirEuaISAFE in accordance with an embodiment of the invention-,.
FIG. 30 is a block diagram ~ illustrating VirtualSAFE from a business-to-business perspective, and including an e-portal, in accordance, with an embodiment of the invention; and, ~~
FICr. 3I is a block diagram illustrating VirtualSAFE from a business-to-consumer perspective, and including a merchant, in accordance with an embodiment of the invention.
AET.AILEl~ I~I;SCIZ.IPTioN of THE PREFEIZ.REA EMBQhIMENTS
Zn the following description, numerous specific details are set. forth to provide a thorough understanding of the inventiotl. However, it is understood that the invention 24 may be practiced without these specific details. .In other instances, well-knovvit software, circuits, structures and processes have not been described'or shoal n in detail in order not to obscure theinvention. In the description and drawings, like numerals refer to like structures or processes.
The term "VirtualSAFE" is used herein to refer to a system, including software, for secure electronic con~.merce using virtual smart cards in accordance with an embodiment of the invention. VirtualSAFE may include machines for processing data, including the computer systems and network arrangements described herein.
_ 1~ _ AMENDED SHEET

19-07-2002 . CA 02405847 2002-10-10 CA0100504 SysEenr. VirniaISAFE is an electronic commerce system which includes a client terminal, a merchant server, a payment server, and a VirtualSAFE
authentication server. The client .terminal, merchant server, payment server, and VirtualSAFE
authentication server'are in communication over a network, typically, the Internet.
Using a web browser, a user at the client terminal browses through product and service web pages presented by a merchant through the merchant. server. The user may purchase products and services fxom the merchant using a virtual smart card. The VimtalSAFE. authentication server authenticates . the user through the so#lware . rraodules and method described bel4w. In general, the payment server fulfills the e-eoramerce transaction. VirtualSAFE has stored therein data representing sequences of instructions which when executed cause. the method described herein to be performed.
Of,course, VirtualSAFE may contain addirional software and hardware a description of which is not necessary for understanding the invention.
Modteles. Referring to' FIGr. 1, there is shown , a block diagram illustrating VirtualSAFE software modules ~ I00 win accordance with as embodiment of the invention. VirtualSAFB software modules I00 include the following: Public Key Infrastructure (PICI}~ 101; Redirection Link (RL) 102; Secure Remote Pointer (SRP}
103; Attribute Authority {AA} 104; Virtual Identity (VI) .105; Vixtual Smart Card (VSC} I06; Secure Data Repository 107; VirtualSA.FE (or Authentication Authority) Server 108; Crypto-Engine (CFV} 1Q9; Payment Processing Engine 110; Risk lliianagement Engine 1'!L; Transaction Fulfil3ment Mecbazlism (TFM}.112;
Tnsurance Module I13; Secure Transaction Repository 114; and VirtualSAFE Deposit Box (VSDB) 1.15.
These modules are described in detail in the . following beginning with the VirtualSAFE server 108 and Crypto-Engine {CEV) 1.09.
YirtualSAF~ Server 108. Advantageously, the Virtua3aAFE server 108 (or authentication server) dispenses with the need for physical smart cards and card AMENDED SHEET

readers. In the following, physical smart card transactions are contrasted with virtual smart card transactions as coordinated by the YinuaiSAFE server 108.
Ph~rsical Smart Card Transactions. Typically, local cardholder functions include a consumer card interface. display arid acceptlcancel options are performed 'at the client terminal. Payment functions, including security card control,. data storage, and the use of a concentration point, are performed by a payment server. The presentation and eventual delivery of goods arid services by a merchant are performed under the control of a merchant server. The Internet performs routing functions between each entity. It should. be appreciated that the Internet may include its present form or it 1 U ~. may include any other open network implemented using a combination of computer, telephone, mitxowave, satellite, or cable networks.
The client terminal controls the interaction with a consumer and interfaces to the card reader that accepts a smart card having a stored-value application. The payment server communicates directly with a terminal or / through a concentrator that handles a number ' of terminals each having a security card. The payment . server also communicates with the concentration point for transmission of transaction data to a clearing and settlement system. The database stores all the appropriate information passing through the payment server for each transaction. Use of such a database allows any number of merchants (or merchant servers) to use the payment server for transactions. The ' payment server controls payment functions such as handling attached terminals, managing the database, and collection functions. The merchant ' server is typically a site that has contracted with an acquirer to accept smart card transactions as payments for goods and services purchased over the Internet.
As discussed above, the smart card may take a variety of forms and is useful in many 2S . situations where it is desirable to store monetary value 'on'a card that a consumer may use. Generally speaking, the smart card is any card or similar device able to store a value and decrement that value when the card is used. The card rnay be purchased complete with a stored value or a given value may be added to the card later.
Such cards may also have their value replenished. The smart card may also perform a 3Q ' variety of functions in addition to simply storing value, for example, debit, credit, AMENDED SHEET

19-07-2002 CA 02405847 2002-10-10 ' CA0100504 prepayment, and other functions. Such a card typically includes information such as a bark identifier number, a. sequence number, a purchase key; a Ioad key, an ugdate key, an expiration date, a transaction ID, and a running balance.
The smart card may include an eneryption module in order to provide a vaziety of security features. FQr example, security features may include, simple PIN
numbers, biometrics, simple algorithms, ~ or sophisticated algorithms . such as the Data Encryption Standard (DES) or Rivest Shamir Adelman (RSA) encryption.
Typically, .
a smart card is able to use these features to verify consumers and card readers, to validate security cards, and to provide a unique digital.signature. A smart card may include. any number of keys which are lmown to the card issuer. and that are used during the course of a payment or load transaction to generate digital signatures for validation of the stored-value card, security card or module, or the system itself.
The client terminal may be any suitable device for interacting with the card and for commuxticating over a network with a payment server and a merchant server. For example, the client terminal may be a mainframe computer, a workstation, a personal computer, a set lop box, a kiosk, or any type of service payment terminal that a consumer might use to purchase goods and services. The client terminal may also be embodied iri' any portable device including a laptop computer, a cellular telephone (including GSM telephones), or a personal digital assistant {PDA). The card reader may be any suitable interface device that is capable of transfening information and commands between the client terminal and the card.
Typically, the client terminal includes a "client code module" and a "card reader module". The card reader module may be implemented using any suitable software and libraries for communicating with the card reader. Its actual irraplementarion will ?5 depend upon the. type of card reader used. The client code module controls communications between the client terminal, the card reader, the payment server, and the merchant server. The client code module may be implemented using any suitable software. For example, the client code module may be implemented using a combination of "C" code and a Java applet. The applet may be supplemented with parameters from an FiTML page sent from the merchant, server. The client code-AMENDED SHEET

J 19-07-2002 CA 02405847 2002-10-10 ~ CA0100504 module is also responsible for controlling displays presented to consumers and for the interaction between the card and the card reader. This module also builds the draw xequest message after receiving ail of the start up irifoxmation from the card and the amount of the purchase from the merchant sewer.
S Typically, the payment server includes a payment code module and a terminal interface. -As with the client terminal, the payment server may be implemented using any suitable computer, for example, a personal computer. There may lie one payment server for each merchant server or a single payment server~may service any number of rrierchant servers. There may be multiple payment servers for a single merchant. In 1Q . addiCion, the payment server need t~or be remote from the merchant server but may be located at the same site and have a different Internet address. Or, the payment server and the merchant server may be implemented. on the same computer. The payment server is designed to facilitate communications between the consumer's smart card and ~ terminal's security card.
1 S The payment module mdy be implemented using any suitable code. For example, the payment module xnay be implemented using a combination of "C" code, "Ca--i-"
code, and Java code. The.payment module maybe a multi-threaded process that can service multiple concurrent client applet transactions on demand: Ttie module is responsible for controhing all interactions with terminals including the . tcansac:tion collection 2Q function. For individual transactions, the payment module controls message flow and Iogs interim results. When an applet connects with the payment server, it creates a uansaction thread to support the transaction through its life cycle. Each thread, in rum, assigns a terminal .for communicati4ns. A one-to-one correspondence between transaction threads and terminals may provide good results.
2S Tygieally, the terminal interface is any -suitable set of s4ftware and libraries 'for communications with a terminal 'either directly or through a terminal concentrator.
The actual implementation of the terminal interface will depend upon the type of terminal used. For example, an IQ Delta ~fllQ terminal made by Schlumberger may be used. Such a terntinal supports a variety of commands originating firom the 30 terminal interface. These commands emulate the normal responses from a smart card AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 to a security card should both be located in the same service payment terminal. The actual security card commands ate held in the terminal while the terminal performs the tasks necessary to simulate the presence of a sruart card. The emulation of the card commands can be done by the payment server, using the terminal as a card . reader, or may even be performed by the client tenmixial.
Typically, the security card is any suitable security card such as those that are known in the art (often referred to as~ a Purchase. Secure Application Module or PSAM). The functionality of the security card may be replaced by a crypto-engine (as is done in VirtualSAFE), may be implemented in hardware within the payment server, or may be implemented in saftwate. For example, the security . card may be a.
removable credit card-sized smart card that is programmed to process and store data relating to financial transactions. The security card may contain a microchip embedded in the card that enables the card to authenticate and to validate the consumer's smart card. If the consumer smart card is acceptable to the security card, and if the smart card v contains. . suffici~tt value, then the security card guarantees that the merchant providing goods and services will receive payment in the amount deducted from the smart card. The security card may else contains pES and public key ptu~chase security keys; may authenticate the smart card during a purchase transaction, and may secure the payment and collection totals. A security card may also store digital signature ?0 algorithms far all smart cards in use. A secelrity card may also contain a transaction identifier for the current transaction, a financial sum of all transactions remaining to be settled, a session key, and master keys for all smart cards in use:
Further, the security card may contain generations of keys, blocked card indicators, dates of last update, multiple.card programs, different currency rates, and additional security.
The concentration point is typically a staging eox~puter that communicates with a payment server to ,collect batches of purchase transactions. The concentration point then sends these wransactian batches to a cleaxing and settlement system far processing. ' Once processed, batch acknowledgments, along with other system updates, are retwaied.
_18_ AMENDED SHEET

Typically, the merchant server includes a merchant code module. The merchant serves may be implemented on any suitable computer cap$ble of communicating with and presenting information to consumers over. the Internet. The merchant code module may be implemented using any suitable code. For example, the merchant module S may be implemented using a combination of Perl, HTML, and Java code: The merchant server is typically a generic web server customized for the merchant's business..The merchant server may include databases, CGI scripts, and back-office programs that produce HTML pages for an Internet user.
During a financial transaction, the client termipal and the merchant server exchange ~ information via the Internet. . Each transaction initiated by a consumer has a transaction identifier created at the.merchant server. A merchant identifier unique to the payment server is also available fram the merchant server. The client code module and the payment server also use this unique transaction identifier for tracking and logging information about the transaction. The merchant server generates a unique identification for the transaction, completes other required parameters, encrypts as appropriate, and builds an HTML page and sends it to the client terminal.
The client code. module interacts rwith the smart card and builds a "draw request message" containing related card information, the purchase amount, and other information supplied by.the merchant server.
Next, the client terminal communicates with the payment server by first forwarding the draw request to the payment server. The payment server verifies the transaction to . .
determine if zt is a valid transaction from a lcriown~merchant. The transaction is logged in the payment server's transaction database. Upon completion of a transaction, the payment server builds a result message containing the identificarion of the transaction and signs it. The Tnessage is then routed to the merchant server via the client territinal.
The merchant server then valid tes the result . message. After determining that the transaction was ~ successful, the raerchant server creates an HTML page for .
the purchased. information and sends it to'the client terminal. The merchant may also deliver purchased goods and services to the consumer at this point. It is also possible far the payment server and the merchant server to communicate information directly between them. As the client terminal has already established communication with the _1g_ AMENDED SHEET

19-0.7-2002 . CA 02405847 2002-10-10 CA0100504 merchant server and the payment server, links are used to exchange information between the payment server and the merchant server, rather than establishing a new link.
Virtual Smart Card Transactions. Similar to transactions with physical smart cards, the system includes the client terminal, the 'payment server, and the merchant server.
However, the system dispenses with the need for the physical smart cards and card readers as their functionality is contained within the VirntalSAfE server IOg.
rn VirtualSAFE, the client code module is funcrionally part of the ViitualSAFE
server 10$ instead. of being part of the client terminal. And, the functionality of the card reader module for.transacrions with physical smart cards is included in the client code module to allow communication with a "pseudo technology . process module" (see below). Also, the user interface functionality of the client code module is transferred to 'a client terminal module in the client terminal. in this embodiment, a "pass through" client code module serves to ''pass through" communications between the I5 merchant server and the VirtualSAF~ server 108.
Again, the VirtualSAFE server 108 effectively replaces the need for physical smart cards and card Tenders. To achieve this, the server 10g implements a "pseudo technology process module" and smart card emulator in software. A card database stores information representing "virtual" smart cards 106 (see below) in use within the system. The card emulator interacts with the card database and a crypto-engine (CEV) 109 {see below) to effectively replace physical smart cards and card readers.
Thus, the client code module may be implemented as before unaware that it i3 interacting with a saflware emulation of a smart card rather then with a physical smart card.
The VirtualSAFE server 108 stores the same data used with physical cards in its database and handles incoming commands from initiation or payment servers to increment or decrement a "card" balance as appropriate. Important data is stored in encrypted form and all fur:ction$ that requaTe a chanbe to irnpoxtarlt data or the generation or checking of digital signatures is~perforined by the CEV 109 (see below).
The ViitualSAFE server 108 is typically located at an issuer's site. one such server AMENDED SHEET

w 19-0,7-2002 , CA 02405847 2002-10-10 CA0100504 may support multiple issuers provided appropriate Safeguards are in place tv partition data.
Furthermore, to suppoxt interoperability with existing financial networks, including different credit card vendors, financial institurions, and processing gateways, the VirtualSAFE server I08 may be located at an.~acqtrirer's site. This configuration does not change existing transaction flows and does not require additional investment to secure the financial network.
In an alternative embodiment, the client terminal includes a card reader and a smart card, In this ernbodimerlt, the client terchinal includes a client code module with "pass ! D through" functionality. The system may operate in either of two modes. The system may operate without using a physical smart card by using the emulation contained within the Vixrizal~AFE server 108. Concurrently, or at a later date when smart cards and readers .are more Gammon, the system may be upgraded to make use of a physical card and reader attached to the client terminal.
1 S The VirtualS.AFE server 108 co~nunicates with the client terminal through a "user verification module"' and with the payment server over a link. The server 108 emulates a physical smart card through the use of the pseudo technology process rnadule, a "~inart card emulator", the erypto-engine (CEV) 1.09, and the database 105, .
106, i07, 114, 1IS. .
20 The user verification module . allows the VirtualSAFE server 108 to identify which user is logged an to the system and desires access to a virn~al card in the database.
The.module provides a' login procedure that retluires a secret user identifier anal PIN
from each user. A combination of this user identifier and PIN is then used as an index into the database to identify the record that represents the virtual smart card lOb.for 25 ~ that user. The user verification module may also include the Gard identifier (digital certificate digital signaturey for the user, the funding account and it's expiration date;
and address information for address , verification during the funding portion of the initiation transaction. An address verification system may compare billing information _2I, AMENDED SHEET

19-07-2002 . CA0100504 from an authorization to that on file to assure that the real cardholder is making the transaction.
The pseudo technology process module is a software module that performs the functionality of ~ a physical card reader so that the emulation of a smart card is transparent to the client code module. ~ The card reader module accepts the actual card reader commands from the client code module and, instead of using them to drive a physical card reader, places them into a format to comrnutiicate with the smart card emulator that is emulating a smart card. Thus, an existing application programming interface (API) used by the client code module to communicate with a smart card may continue to ~be used. In an alternatiYe embodiment, the card reader mndute and,rhe emulator may be collapsed into a single functional block although this may require modification of the commands issued by the client code module.
The~smart card emulator emulates a physical smart card by accepting and passing the incoming card corttmauds from the card reader module and determining actions to perform. In, the course of performing-these actions, the emulator handles the interface to the CEV 109, fetches data frotri, and stares data to, the database. For example, upon receiving a command to debit a card, the emulator fetches the balance from the appropriate record in the database and transfers the ~crypted balance to the to be decrypted and decremented. Once the new balance is encrypted by the CEV
1U9, the emulator receives the new balance arid stores it back in the ~ansacrion secure database.
Qnce .an action has been performed, the emulator generates a simulated smart card response that is then relayed via the card reader module and the client code module to the payment server. xhe emulator generates card commands that appear as if they have been generated by a physical smart card, thus making .emulation of the smart card transparent to the rest of the system. The emulator also updates the secure transaction database 1I4 .at appropriate. steps in the processing of a debit or an initiation.
AMENDED SHEET

In addition to debiting or initiating a ~vinual card in the card database,.
the server 108 is able to credit a virtual card if the card was debited by mistake. Tn other words, once a card has been debited to make a payment, the server 1U8 is able to recover that. value and credit the virtual card in the card' database, if necessary. For example;
if a S transaction fails and value has been taken off the card, ~ but no value has been credited to a particular payment server, the system is able to credit the virtual card in the card database to replace the lost value. , Such an operation is different from a formal initiation command in that a user's card is credited for a -value that had earlier been taken off the card.
1Q VirtualSAFE's databases 105,106,10'1, 114, 115 may he impleme led in any callable format and .contain. recbrds for each virtual smart -card in use within the system, A
secure ;transaction repository,114 and a 'secure data ~ repository 1D7 include the information for each virtual smart card in use and thus assists in the simulation of physical smart cards. An identifier such as a user name, PIN, or combination thereof 15, is used as an index into the database in order to identify the appropriate virtual smart card xQb for initiating, debiting, or authentication. Advantageously, the 3.nformation contained in the database is typically stored in an encrypted form for security. In one embodiment, the database are implemented in Sybase.
Records in the database store a variety of data for each virtual smart card I06. This . 20 information _ includes initiation and purchase key identifiers, card and issuer certificates, initiation algorithms, initiation key versions, purchase algorithms, purchase key versions, a bank identification number (BTN), a VirtualSAFE
Deposit Box (~lSl~$) 115 wurrtber, a transaction 1D, a balance, a currency and exponent, an expiration date, and a maximum balance, initiation and business public keys indicate 2~ which keys should be used. Although au keys may be stored within CEV IO~, in one embodiment, the keys are stared within the secure data repository 1D7 as well, with the exception of the CEV master key that is stored in the CEV 14~.
The secure transaction repository 114 stores information regarding transactions that occur such as a debit or an initiation and may be implemented in a similar fashion as 30 the other databases. Also ~referxed to as a history database, the secure transaction AMENDED SHEET

. 19-07-2002 ' CA0100504 repository l I4 includes a puichase table' (i.e. log full of transactions and tirnestamps) and an initiation table (i.e. log full of transactions, funding requestlresponse, ~ and timestatnps).
Crypto-Engine (C~V) 109: The'CEV module 1U9 is used to facilitate cryptographic S processing. As will be described below, the CEV 109 stores secret keys and encryption algorithms, perfomls cryptographic functions on secret data and generates digital signatures. Typically, the 1CEV 1U9 is a, tamper-praaf device that employs a level of physical security as means to protect the sensitive information contained therein. The CEV 109 may be suitable security module, for e~.amgle, it may be similar to the security box typically. attached to automatic teller machines.
Ixt another embodiment, the CEV 109 may be implemented on a smart card within a card reader, on a series of smart cards, on any suitably secure computer, or in software.
In addition to other tasks, the CEV ,1Q9 performs encryption for physical smart cards.
For a physical smart card,, various data elements such as balance and currency are contained securely vc~ithin the card. ' However, such data elements are not stored within the C>~V 1Q9 but are stored in the server's I~8 database_ Typically, important information is stored in an encrypted foam in the database. The CEV 109 performs the task of receiving encrypted card data from the database via an emulator, decrypting the card data, performing required cryptographic functions on the data, and then .
encrypting the data and sending it back out to be stored in the financial information database 114 and secure data repository 10'7. Far example, if the card balance is to be reduced, the encrypted balance is sent from the database to the CEV ,109 where it is decrypted, reduced, and then &nally encrypted again before it is returned to the database.
The CEV 109 ~ also performs cryptograph functions related to digital signatures used uTithin the system. Digital signatures acre used during the initiation operation and typically are generated by the smart card. Some digital signatures are used during an initiation or purchase operation and are generated by the issuer or the payment server.
Some digital signatures are generated by the smart card on occurrence of.an initiation or debit and. are considered the final digital signature after the card has either initiated nnn~~pED SHEET

~.19-0,7-2002 ~, CA 02405847 2002-10-10 CA0100504 value onto, or debited value &om, itself. In VirtualSAFE, the CEV 109 performs these functions which are normally handled by a smart eaid as no physical smart card need be present with VirtualSAFE_ The Cl=V 10~ is used to generate' ,digital signatures and verify digital signatures foi an initiation operation, and is used to verify ~ digital signatures and generate digital si~atures for a purchase operation.
The CEV
109 may also perform other cryptographic functions that would normally ~ be performed by a physical smart card.
Initiation algorithms are identifiers that identify which cryptographic algorithm of the CEV ltl9 is to be used for the verification and generation of digital signatures during I U an initiation. The initiation key version is an identifier identifying which version of a key will he used for the generation or verification of a particular digital signature.
Purchase algorithms and purchase -key versions perform a similar function during a purchase.
A six-digit BTN in combination with the ten-digit TEP forms a sixteen-digit "identification number" that uciiquely identifies a particular virtual smart card 106.
'Ibis identif canon number xnay also be referred to as a "card identifier".
Each BIN, or card range, has a single maximum balance and currency for all of its virtual cards.
The balance keeps track~of the value for the particular card. Currency and exponent information provide fuxther details concerning the >5alance. Azt expiration date provides an expiration date for the card. The maximum balance provides a maximum' for the virtual card, or could also indicate a maximum balance for all virtual cards associated with a 13IN.
.Public Key Ir~frastrueture (1'K1) lfll. VirtualSAFE is compliant with PI~.I
standards , for X.509 vl and v3 certificates, ItSA cryptography, PKCS #1 I certificates, certificates, PKIX v3 extensions, and Secure Electronic Transactions (SET).
The PKI
process lU1 consists of mufti-tiered and distinct Certificate Authorities (CA) defined as follows:

AMENDED SHEET

19-07-2002 CA 02405847 2002-10-10 ~ CA0100504 1.. An External Certification Authority (ECA) designated to issue web certificates to user client computers. Each user has an ECA key' pair as follows:
~ ECA Public Key {ECApuh) ~ );CA Private Key (ECApriv) 2. An internal ViriualSAFE Certification Authority ('VCA). desi~rtated to issue corresponding internal VirtualSAFE certificates for each external user web certificate_ Each user has a VCA key pair as follows:
s V CA Public Key (VCApub) ~ VCA Private Key (VCApriv) . .
3. The VCA issues an encryption certificate to the VirtualSAFE Web Server (VWS) with the~following key pair:
VSW Public Key (VSWpub) VSW Private ICey {VSVVpriv}
As will be described below, VirtualSAFE has an Attn-bute Authority (AA) 10~
designated for managing access and network permission' attn~butes far users. ' Redit~ection Zink (ItL) 102. The redirecCion link 142 allows non-repudiation by~using digital certif cater and a secure algo~.thm and protocol residing on a remote merchant ar business site. The redirection, Link IQZ enables an online e-commerce process to access ViitualSAFE's secure transaction environment. The associated process consists of the following steps:
1. The, user completes the .required conditions for executing a transaction, or request for a resource, by selecting and retrieving the appropriate access query page from a merchant server.
-2b-AMENDED SHEET

19-07-2002 . CA 02405847 2002-10-10 CA0100504 2. The access query will be in the fvim "buy now" for a payment transaction or "access now" for a secure resource access or retrieval.
3. The redirection link 102 will capture the relevant data from the merchant server and redirect the contents of the request 'to VirtuaISAFE. In the case of any transactionla~cess any amountlsession unique identifier . may be transferred. In the case of a resource access request; user attributes may be transferred to 'Virtual- SAFE.
The redirection link .102 allows non repudiation by using X.509 certificates and a secure algorithm and protocol residing on a remote merchant, business, or resource site. The redirection request, once processed, initiates the Secure Remote Pointer (SRP) X03 process for encrypting, sigting, and hashing transferred data. The SRP
1U3 is described below. The merchant and/or user can digitally sign the transaction.
Sec:cre Remore Painter (SR1') 103. The SRP 103 is a composite secure algorithm and protocol residing on a remote site (i.e.. VirtualSAFE, merchant, user yr any other 1 S entity) that provides encrypt/decrypt and digital signing timestamp functionality for coW municating with ,VimvaISAFE. The SRP 103 is . a VirtualSAFE compatible application that runs as a web hrowser plug in, applet, or standard application. The client browser; to conduct secure communications with VirtualSAFE, uses the SRP
1a3. The process is initiated when the user clicks on a redirection link (RL) 102 that requires an authentication and authorization check. Clicking on this RL, 102, as described above, implies a commitment to access a resource, for exazriple, a payment transaction or a secure database. In order to execute a transaction, authentication of the user is required. The process requires authentication of the user computer via an X.509 r?igital Certificate or other standard PKI format. Once authenticated with..a ~25 digital certificate the user; application, or browser will always communicate with VimtalSAFE via the secure web browser plug-in or the SRP 103 or application.
The security approach to the SRP 1Q3 includes mufti-layer security via encryption and enveloping techniques. The SRf 103 functions include encryption of data that will he packaged and then encrypted via secure sessions in addition to an SSL
-z~-AMENDED SHEET

19-07-2002 ~ CA 02405847 2002-10-10 CA0100504 co~municatio» channel with the 'VirtualSAFE database to complete transactions and store operational data, or for other accesses purposes.
Refet~ing to FIG. 2, there is shown s flowchart illustrating the operation. of the secure remote pointer (SRP} 10~ in accordance wiih an embodiment of the invention. In order to securely capture and store data from the customer, the following steps anal requirements are incorporated in the SRP 103:
1. The entire communication will take place over a'client-server in addition to an authenticated SSL channel: Two-way authentication is established using the digital certificate distribution method described above.
a) T'he SRP 103 will encrypt data being transmitted to VirtuaISAFE prior to being placed in an electronic envelope. The envelope in turn will be transmitted over' the secure session in addition to an SSL channel protocol. . ();ncrypted data is seat in accordance with VirtualSAFE
policy through the SSL.) b) The VCA Public-key, VCApub, of the user that is stored in the browser, application, message, or cookie is used to encrypt data once, creating Cl 201_ c) A time stamp is concatenated to the enerygted data package C 1 2U1, the ECA private key, l~CApriv, belonging to the user signs the data to create C2 202.
d) 'Phe result is encrypted with the VixtuaISAFE Web Server FubIic-key {VSVfpub) to create C3 2U3. This key can be obtained by the SRi' 103 or in the case of dynamic application that will be transmitted with an~
ActiveX Control I lava Appiet I Application, etc., at the time of page initiation.
2. 1"ncryption and signing of the data package is completed entirely within the secure confines of the SRP 1U3. The following steps are carried out to securely communicate with VirtuaISAFE.

AMENDED SHEET

19-07-2002 CA 02405847 2002-10-10 ~ CA0100504 a) C3 _2U3 is nansrnitted as C4 20~t over SSL or other secured channel encrypted with the appropriate se~sian keys.
b) The data package C4 2Q4 is decrypted 20S by the reciprocal SSL, or secure channel session keys, at the VirtualSAFE W'eb Server to reveal C3 243.
c) The VirtuaiSAFE Web Server/Application will decrypt 246 the data package with its private key VSWpriv locally on the W eb ~ Server to reveal C2 202, C?ptiotially, this may be performed by a VirtuaISAFE
Apphcauon behind the Web Server.
~ d) The data is now ready to be used locally within VirtualSAFE.
e) The data package C2 2t12 is passed 207 to the User's Virtu,a3SAFE.
Deposit Box I15.
3. The data package in its new form may now be used by VirtuaISAFE for various different operations including:
' a) .Authentication. Data received fox authe~atication is treated as an encrypted quantity that does not need to be decrypted. The encrypted data is compared with a database of encrypted PINS in the VixtualSAFE.
b) ~ Transaction. The VirtuaiSAFE private-key VCApriv of the customer is cased to decrypt .the transaction data received at the time of purchase.
The encrypted private iztformation of the customer in the customer repository is decrypted and hashed or encrypted, or digitally signed and sent to the payment processor, or other transaction engine. The VirtualSAFE Private-key {VCApriv) ' is used to decrypt the local customer credit information far the transactiari. The credit information will then be passed to. the paytn.ent prQCessor or other transaction engine. The information may be optionally signed by the customer, hushed or encrypted by an administrator. The payment configuration AMENDED SHEET

will determine future processing and the necessary encryption or digital signing for the data.
Arrribute Authenrfeation Aicthoriry AAA) x04. The AA 104 is an internal and external Vir:ualSAFI_ module that enables the assignment of authorization to users and 5' applications to access network resources, and remote non-repudiation providing valid digital signature and verification zrlechatlisxns for new or existing financial and other information in'&astructures.
The implementation of a remote ~ electronic commerce application requires managing access to electronic resources. The core value of an e-commerce application lies in the ability to manage identities and the associated privileges ~ attached to these identities. Tn traditional approaches to PKI, a Certification Authority (CA?
issues and .
revokes certificates used to bind a name to a public .key. However, the existing certificate strucitue reduires an existing name space where each individual is uniquely identified with a unique name and often a unique number. In e-commerce IS transactions, the merchant server may be assured of the customer's identity by means of digital certificate verification. However, the authorization of the customer identity to actually perform the transactio» ~ (or' other access privileged is not necessarily a given. _ Advantageously, VirtualSAFE provides a means far the merchant to be certain that the actions to be undertaken am legally binding. and the signer indeed haS the authority to execute theta.
T.n VirtualSAFE, digital certificates are enhanced by including attributes that provide or grant a privilege to its owner. The benefit of this approach makes the attribute certificate well suited for system access. control or authorization control.
By definition, access control entails the limiting of activities of a user on the system.
2~ Enforcement of such controls is accomplished by maintaining a reference monitor that mediates access attempts by consulting an authorisation base to determine if the user attempting the access is authorized to gain access. 'A distinction is made here between authentication ~ and access control; authentication eonfrrrns the identity of the user, AMENDED SHEET

19-07-2002 ~~ CA 02405847 2002-10-10 CA0100504 while access ccant~ol establishes, identity privileges can the basis of successful authenucation.
Access control may be deployed in one of two modes, namely, an activity-based mode or a group:based .mode. In the activity-based u~ode, user access control is , niauaged according to activity monitoring where each_aecess is checked against an . ~ authorization table and permissions are granted or denied on that basis.
In the group based rrtode, user access control is based on the group to which a user belongs. Users of the same group are authorized to perform a specific set of system tasks or actions.
Instead of specifying ail the individual user .authori2ations, actions are assigned according to the group such that an individual user may perform the tasks assigned to the user's group.
Group-based access contxol is characterized by the following:
I. Authorizations are defined according to classes of objects or resources where a member of a goup may be authorized to access a particular resource. This enables a class of resources to be accessible to a group of users Without specifying individual resource access privileges.
2. Access to specific resources are defined by the activities required by a particular group- ,A group is defined by its authorizations and a user rriay be affoided access rights according to a group designation.
2Q 3. Groups may be nested in a hierarchical order wherein higher-class groups may inherit lower-class group authorizations.
4. Minimum access may be granted on the basis of a minimum group characteristic. Access for lower . risk resources may' be afforded by assigning a lower class role.
5. Access privileges can be specified according to Boolean constructs '' wherein several group authorizations may be afforded to a user to achieve a composite access portfolio.

AMENDED SHEET

-~ 19-07-2002 CA 02405847 2002-10-10 ~ CA0100504 A group-based model is advantageous on several levels_ Far example, overall administration is shifted to the group Ievel from the individual user level.
A user Fnay have several authentications including the following: , ~ ' User authentication as described vv~ith respect to . the authentication authority module 1U4 below. In addition, an enrolment value is exchanged between Vi.rtualSAFE and a secure portal with a resource group. Any transaction/access session is performed by a minimum of two chazmels simultaneously (e.g. SSL and VPN, etc.), combining enroll value and session value digitally, signed by all parties based on a digital identity 1 Q group (i.e. secret, shared-secret, physical material). .
AccountlResaurce digital signature authentication based a digital signature Verl~ted by a user public key attached to the accountlresource.
The digital certificate infrastructure is well suited for this approach to access control.
In the standard digital certif care, a public key is signed by a Certification Authority I5 (CA) and distributed far authentication purposes. The same principle is applied to group-based access conaol_- in this method, a gzoup is described by a set of attributes that enable the members of the group to perform cowman ~unctians. The attributes are bound together by a digital signature by a CA, creating an Attribute Certificate (AC), which is consequently unalterable until a new set of attributes is designated and 20 signed. The Attribute Certificate may contain the following fields:
~ Version: Designates format of the AC currently in use.
~ Subject; Context of the AC usage in terms of the given application.
~ rssuer: Issuer of the certified AC.
~7igital signature: Digital signature of the AC data by the Issuer. ~ - ' 25 ~ Issuer Unique ID
a Seria3 Number: A unique identifier of the AC.
_32_ AMENDED SHEET

19-07-2002 ' CA 02405847 2002-10-10 ~ CA0100504 Expiry: Defines the validity period of the AC.
Attributes: Access control de~tnitiot~s for the AC.
The attribute authentication authority (AA) 1Q4 is advantageous for autbentieatian and authorization of business processes. Typically, existing business processes use ' some means of account based protocol to evaluate attributes. However, these methods are reliant on knowledge ~actor authenticauow where the user diwlges a previously agreed secret. That is, typical business processes supporting authentication are primarily "shared-secret" based (e.g. PINs, mother's maiden name, SiN#, SSN#, etc.).
The "shared-secret" has the disadvantage that the shared-seexet can both originate as well ~as authenticate a transaction (i.e.. exasdng business infrastructures need extra .
Levels .of security to prevent divulging the shared secret): ~ Upgrading these existing authentication business infrastructures to~ PKI is straightforward and eliminates the vulnerability associated with divulging the authenticating value.
Advantageously, VirtualSAFE includes a straightforward icpgrade to existing "shared-secret" authentication processes to a "secxet", "shared secret", and "physical material"
authentication process using existing business processes. By including , an Attribute Certificate in a transaction, the .authentication of the user is enhanced.
Consider the following access control system, which is in~accQrdance with an embodiment of the invention:
ZO 1. . A Trusted-Third Party Certification Authority CA(x) 2. An Authentication Authority AA(y) .
3. Organization Resource R(1) , R(2) , It(3) , R(4) ,... R{n) 4. Groups described by attn-butes G(l.), G(2), :..G(n) 5. Users designated as U (1 ), U(2), .. ..: I1{n) AMENDED SHEET

19-07-2002 CA 02405847 2002-10-10 ~ CA0100504 The Certification Authority CA(x) is capable of issuing public key certificates and of signing the root issuing certificate of the Authentication Authority AA(y).
Resources are classed and labeled such that access to resource R(1) is distinct and non-connected with.R(2), or any other resource R(u). ~aeh group G(n) is assigned authorization to access a particular set of resources based an policy, for example, G(1) rnay access R{1}, R(3), and R(4}_ In this embodiraent, a method by which an authorization environment for resource access is made instantaneous, may include the following steps;
1. The root certificate CA.(x) is distributed to all users U(n) and resources I Q R(n). _ 2. The root certificate AA(y) is also made publicly available.
3. Authentication Authority AA(y) is able to issue ACs to all users U(n) in ~(n).
To exercise a- resource access authorization, the ..following steps may now be 1 S. followed:
1. An access reguest to resource R(1} is made by a user member U(1) of group G{1), where G{1) is granted access to R(1), R(2), and R(4), and is digitally signed by the user. ' 2. Resource R( I ) verifies the digital signature of U( 1 ) with U( 1 )'s public-key 20 certificate.
3: Resource R(1) checks the validity of U(I)'s certificate by verifying the digital signature with CA(x)'a root certificate.
4. The AC of U{1) is verified using AA(y)'s root certificate.
S. 'I'he attributes in U{ 1 )'s certificate are then used to pant access, according 25 to the group membership of U(1), to G(I) which includes R(1) access.

AMENDED SHEET
r Given the successful verif ration of these queries on U(1}'s AC, then the result will be either to deny access or to grant access on the basis of identity authentication and appropriate access authorization.
Virrual .Identity (VI) 105. The VI module 105 is a composite secure algorithm and protocol far creating a digital cenifieate based virtual identity based ~ op the ~ above described secret, shared-secret, and physical matenal process. VI 1(l5 includes the use of x.509 Digital Certificates in the internal ViriuaISAFE Certification Authority (VCA), as described above. VT 105 also includes the following:.
1. - The Web certificate from a third party or ECA public and private key of ~ the user:
Public Key (LCApub}
Private Key (ECApriv}
2. The VirtualSAFE CA public and private key of the user:
s VCA-Public Key (VCApub) o VCA Private Key ('VCApriv) 3. The private data of the user is encrypted with the user's public key (VCApub}~ and committed to the local database.
4. The user's private key (VCApriv) is stoied securely ,elsewhere in VirtualSAFE.
- 5. VirtualSAFE then executes a retrieval of the information in the Virtual Identity 1.0S by employing a composite secure algorithm and protocol described below in coujunctiQn with the Virtual Smart Card module 146.
The retrieval and storage of the secuice data is performed on the basis of a secret, shared-secret, aad physical material process.

6. The user data stored in the Virtual Identity 105 may include the following:

AMENDED SHEET

~' 19-07-200 ~ CA 02405847 2002-10-10 CA0100504 Encrypted P1N and other access data ~ AA Reference Data ~ Personal User Data ~ Financial User Data Yirrual Smart Card (CSC) 14G. Tlie Virtual Smart Card module 106 enables authentication and secure, isolated . enctyptldecrypt and digital verification functionality. Remote.' or roaming VinualSAF>= digital certificate storage is an important part of this configuration. The VSC module 106 is ~an internal VirtuaISAFE
application that acts as a local secure proxy to an external virtual authentication. token 1d accessed via the Sectue Remote Painter (SRP) -1A3. The VSC 106, authenticates, encrypts and decrypts VirtualSAFE user data using a multi-tiered Public Key Infrastructure (PK,I) ID1 managed service. The VSC gD6 implements a mufti-tiered PKi by desi~ating a dual set of key pairs for each user. As described above, the first set is an External Public-Private key pair, issued by the External Certification Authority (ECA), which resides on the client or web browser and interope~ates with the SRf' 1D3. The second set is a local VirniaiSAl;E Public-Private key pair issued by the VirtualSAFE Certification Authority (VCA} that resides securely and inaccessibly to the outside network within YifilalSAF.E. The Virtual Smart Card (VSC) 1D6 is part of VirtualSAFE's secure baekend Virtual Identity 1DS manageanent system. As . described above, a system in which Vittu.aISA'FE is deployed typically includes the following:
1. Client Terminal. The client terniinal typically includes a ' personal computes with network interface communic~tiou capability, and a World Wide 'Web browser application. The client terminal tuns the Secure 2S ~ Remote Pointer ID3 that makes a secure connection' with the merchant server.
?. Merchant Server. The txterchaiit server (i.e. WWW server) is configured to serve web pages. The merchant server can serve pages related to an e-AMENDED SHEET

commerce shopping-cart , application or it can serve pages reIadng to the access of controlled resources (e.g_ documents, applications, etc.).
3. VirntaISAFE sewer 108. The VimtaISAFE server IQS includes the VSC
pmcess I06 and the requisite VirtualSAFE Deposit Box 115 (see below) S containing Virtual Identities 1U5.
4. Payment Server. The payment server (i.e. fulfilment resource) ~ is in communication with VixtttalSAFE and may include of any valuable or sensitive services or systezx~s; including but not limited to payment servers, secure data repositories, or other information.
I O The method by which the VSO 106 is accessed by the remote. client terminal and by which it executes ari online interaction is as follows:
1. A communication channel is opened between the client terminal and the merchant server. The client terminal is presented vs~th content from the merchant server. The user browses this content for items and makes an 15 access decision. In the case of an e-commerce application, this is equivalent .to browsing an electronic shopping cart , application and composing a~list of items for a purchase decision.
Z. Upon makzng an access decision, a sigpal to actuate a resource access process ~on behalf of the user is tratZSZnitted~when the customer clicks the 20 ~ Redirection Link 1d2 on the merchant server's resource decision web page.
3. The merchant server communicates the requirement to execute the resource access process to the VirtualSAFI" server over a secure channel whereby authentication is initiated between -the client terminal and VirtualSAFE.
~5 4. VirtualSAFE initiates Virtual Smart Card (VSC) X06 authentication by immediately downloadixtg the Secure Remote Painter (SRP) 103 to nhe client rexminal.

AMENDED SHEET

' 19-07-2002 ~ "-~~~ ~ --~~-~~ ~-~ --- - CA 02405847 2002-10-10 ' CA0100504 5. The SRI' 103 requires.PiN and PIN~authenticatian from the user.
The VSC module 106 includes a multi-tiered authentication ruecha~ism that consists of the elements described above with respect to PKI IO~, that is, the ECA, VCA, and AA.
S The VSC 106 may be initiated through the following method:
1. A User VCA' Public-Private key-pair is generated by VirtualSAFE and stored as follows:
a) The VCA public key ~7CApub) is combined with the Certificate . Digital Signature from the Lxternal Public Key Certificate, ECA, and used as a unique identifier or footprint.
b) .This combined unique identifier and digital certificate data is stored in an online application, browser cookie, or dynamic header flf a we3~ page; and automatically downloaded tanhe client terminal ar web browser_ c) The unique identifier and digital certificate data is also stored with .the user's Virtual Identity (VI) 105 in the user database. As the database's user information is entirely encrypted, the unique identifier and digital certificate data, .as described, is used as a search index in ordei to retrieve encrypted information about a particular user.
d) Every query communicated to the VSC ' 106 from the SRP 103 , contains the user"s unique identifier and digital certificate data for identification purposes. Note that the data from the. SRP 103 is signed and encrypted to help prevent fraud.
2. Ail the user data stored in the VirtualSAFE database is encrypted with the individual user's VirtualSAFE private key (VCApriv). Any key that is external to VixtuaISA~ cannot decrypt the local data, for example, the AMENDED SHEET

19-07-2002 _ ~ CA0100504 ECApriv key. The VCApriv key is stared secuxely in VirtualSAFE, apart fmm the VS1J$ I1S.
3. When a query is made vza the Secure Demote Pointer (SRP} 103 it can arrive in either of the following two forms (as described above with respect to the SRP module T03)_ a) Authentication. The SRP 103 query composed of a data package C1 is decrypted 24$ (see FIG. 2} and verified for use by VirtualSAFE as described above:
1. In this case the data contained in the data package is .the user footprint and the verified but still encrypted (with VCApub) Personal Identification Number {P~t) from the ,' remote client terminal.
1I. ~ The user 'footprint, is used, to locate the VirtualSAFE
database Vixtual Identity xOS of the parricular user_ III. Upon retrieval of the VI 105 of the particular user, the encrypted pZT~T from the SRP 103 is compared to the PIN in the VI 105 record.
IV. If the encrypted data fields match, then an authentication is affirmed, and authorizarions associated with this VI 105 are requested from ttte AA 104.
V. The remaining authorizations are queued and verified as . described above with respect to the Authentication Authority I04.
b) Transaction. The SRP 103 query composed of a data package Cl. is decrypted and, verified far use by the VirtualSAFE as described above.
_39-AMENDED SHEET

19-07-2002 ' CA 02405847 2002-10-10 CA0100504 t. In this case, the data contained, in the data package is the user footprint and the vsrified hut still encrypted (with VCApub) resource access query C1 from the remote ciierit.
terminal.
Il. The user footprint is used to locate the VirtualSAFE VSC , 106 and Virtual Identity 105 for the particular user.
III, Upon retrieval of the VI 1,0S for the particular user, the encrypted resource access query in C1from the SRP 1.03 is decrypted 2fl~ (see FIG. 2) with VCApriv chat reveals message M.
IV. The message ~ M contains formatted instructions for VirtualSAFE to perforrri some transaction or resource access.
V. In order to carry out the transaction or resource access the 1S local VI 105 data must be decrypted with VCApriv: Upon decryption of user data, the transaction must be authorized . . by ~e AA.1Q4.
VI. The transaction authorization is queried and verified as described above with respect to the authentication authority 24 ' ~ module x04.
VII. The transaction or resource access is executed. ' VIII. The decrypted Vi 105 data is destroyed, and the existing user VI 10S record remains encrypted in the VirtualSAFE
Deposit Box 115.
25 1X. Results of the transaction or resource access are returned to VirtualSAFE and the Vi 105 record is updated and encryptedlhashed.
4.0 AMENDED SHEET

19-07-2002 . . CA 02405847 2002-10-10 CA0100504 'X. A confirmation of the transaction or resource access is communicated to the client terminal via the SRP 103 and merchant through a dedicated channel or another form of messaging.
The Virtual Smart Card (VSC) 105 process may be used in the context of a Point-of Sale (PQS) card-swipe terminal at a merchant's store or shop, as follows.
Assume that the customer maintains an $ccoux~t with an existing financial institution_ , The following steps may be included in the use of the VSC IOb:
1. The merchant vswipes the magnetic stripe customer debit or cxedit card at the POS terminal.
2. The POS terminal transmits a request for authorization through the fittanciai network. A connection is made to an intermediate smart card reader at the merchant's score or shop.
3. .The smart card reader includes the merchant's suiart card.
. 4. The transaction authorization request from the- POS terminal prompts the smart card reader to encrypt and sign the data prior to transmission.
5. VirtualSAFE reguires a F1N identiftcarion to authenticate thd customer.
b. VirtualSAFE performs an authentication of the customer.using the Virtual Smart Card process 1U6 (as described above).

7. The customer is authenticated.

8. VirtualSAFE scads an encrypted or digitally hashed and signed transaction request to the financial institution or to an Interac switch.

9. An authorization message is returned to VirtualSAFE or to the merchanr 10. The authorizatidn message is decrypted by the smart card reader.

11. The authorization message is returned to the P4S terminal.
. . . . _~1..
AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 The Virtual Smart Card (VSC) 106 process rnay also be used in the context of check giocessing, as follows. Assume that the customer is already enrolled in VirtualSAFE.
' The following steps may be included in the use ofthe VSC 10b:
1. The customer requests a payment be made to a merchant . using a ViriuaISAFE check by clicking the appropriate Redirection Link (RL) IQ2 on the merchant's web site.
2. The customer is forwarded to VirtualSAFE:
3. VirtualSAFE performs a remote authentication of the user and gasses the . .
customer tp their vsc nab:
14 4: The customer approves a check payment from their personal financial credit portfolio.
5. VirnialSAFE signs the data reguest and sends it to the financial institution.
6. An optional printout of the check is generated inside the physically secure facilities of the financial institution.
~ 7. VittualSAFE receives ~ confirmation of check status (e.g. processed, returned, NSF, etc.).
8. VirtualSAFE encxypts and stores the transaction data in.the customer's Virtual identity SOS. .
9. ,An. optional mess$,ge or prixttout of the transaction is forwarded to the customer or merchant.
.~ Secure 'Data .Repository 307. The serure~ data repository 147 is an internal VircualSAFE module that enables secure storage of dynamic andlor static application data, using a unique pKl based encryption scheme 101 and different crypto-engine security 1d9, in the same database. Existing standards and business practices allow Viriu$1SAFE to maintain an internal secure data repository of certificates in optimized formal as long as the original certificate format eau be exactly reproduced bit-for-bit.

AMENDED SHEET

19-07-2002 . CA 02405847 2002-10-10 CA0100504 These optimizations are implementation dependent for specific operations and may contain a combination of data compression andlor field elimination.
VinttalSAFE includes the following Database Repositories tDR):
1. VSCICusto;uer Database. This DR iscontrolled by VixtualSAFE and contains customer Virtual ldentities ('V1) a05.
2. VSCIMerchant RepOSftOry. 'This DR is controlled by VirnxalSAFE and interfaces with a designated payment server (or other fulfillment resource).
The VSCICustomer aad Merchant Repositories are interlinked based on the business rules and policies defined in accordance with 'business requirements. The VSClCustomer Repository is a composite.af customers' VI 105 records. These records include all personal, financial, and credit data belonging to each customer.
VSClMerchant Repository is based on a fixed schema developed for payment and contains merchant - data profiles. The VSC/Merchant Repository also contains payment transactions in various states'of completion with a credit payment processor.
These states may include rhe~following:, .
Validated ~ Failed Settled These states m~zy be managed, voided, cancelled, etc.; and 'queries, such as.retrieving transaction history, return various responses including transaction content which may include the following.
s Payment Server Transaction ID
Credit Card lumber ~ Expiry Date _ 43 AMENDED SHEET

a Amount a Transaction Date ~ Transaction Status External financial systems are securely interfaced with VirtualSAFE in that S transaction communications are digitally encrypted anii signed.
Payment Processing Engine 110. The payment. processing engine 11.0 enables the processing of financial transactions with remote payment providers. The payment pTOCessing engine ~.1U may include a server and connectivity to a payment gateway that supports wherein the servers support VinualSAFE's compatible client-server SSL
authentication. Payment processing may iaclude the following: credit card payment, ' debit card payment, direct debit, check processing, wire, and EFT. Payments in VirtualSAFB raay be processed in several wades including batch processing and real time processing. Each mode achieves the same set of possible results from a payment request, whether it is authorized, settled, or declinsd. Real-time processing is achieved 1 S by executing a single payment request in real-time while the customer is connected.
VirtualSAFB's payment processing engine 1I0 may support several transactions including the following:
Credit Card Authorization a Address Verif~.cation m Paymezit Submission a Payment Settlement ~ 'Transaction Void Transaction Credit Draw Request lVlessaaes. In the foilow, a detailed description of one method for processing a draw request message in conjunction with a .virtual smart card-is _ q.q.
AMENDED SHEET

19-07-2002 ~, CA 02405847 2002-10-10 CA0100504 presented. Recall that draw request messages were introduced in the description of the VirtualSAFE sever 10g above.
Once a draw request message has been received by the payment server and passed along its terminal, the terminal parses the message~back into individual responses and passes these .responses sequentially to the virtual smart card. In an alternative embodiment, . a dumb terminal is used and the drava request is parsed into its components and otherwise processed ~by the paytnertt server, which then sends, the responses to the virtual smart card itself.
The payment code module of the payment server edits the draw inquest for syntactic I O correctness and logs the draw request message as being received. The draw request is passed ~ to the terminal interface of the payment server. In one embodiment, the terminal interface then requests a terminal frora the payment server's terminal pool.
The payment server may have a pool of terminals connected to a terminal concentrator that is established at start-up. At start-up, the payment server receives a list of all valid terminal identifiers. The payment server uses these identifiers and its knowledge of transactions in progress to determine an appropriate terminal to process the transaction. Once a terminal is -determined, ~ the terminal interface .
builds a ternxinal specific message based upon the draw request and the type of terminal. .
The ~tenninal specific draw request isseat to the chosen terminal over a local area network. ~1. concentrator may act as ' a router between a transaction thread in the payment server and a corresponding terminal if 'many terminals are attacbed to the payment sewer. 'The concentrator looks at a header.on the draw request to determine to whicY~ . terminal the transaction should be routed. In one embodiment of the invention, the concentrator ~is not necessary and the payment server.
~mmunicates directly with the terminal.
The terminal parses the draw request message into its various components and processes each component in turn to emulate a card interacting with the virtual smart card in a physical terminal. Prepackaging of a variety of data into. the draw request message results in fewer exchanges fiver the laternet between the VirntaISAFE
server _45_ .
AMENDED SHEET

19-07-2002 _ CA 02405847 2002-10-10 CA0100504 108 and the payment .server. gy simulating an interaction, the virtual smart card behaves as if it were in a physical terzniual along with an actual smart card.
A. variety of respunses.from a smart card may be emulated. In one embodiment, the tartninal .
sends each of the ~ two commands "Answer to Reset" and "Initialize IE-W for Purchase" down to the virtual smart card individually and waits for a return message, ''Debit IE-W," before sending the next response. For a public key transaction, the certificates read by the client are also included as individual responses. In this way, even though all of the smart card infazmation (the draw request) originating from the VirtualSAFE server 1~8 has been sent at once in prepackaged form .over the htternet, 2 0 the interaction between the smart card and virtual swan card in a physical terminal is simulated at the terminal in a remote locatio».
The terminal reaches a "draw amount" state, indicating that the virtualsmart card is able to generate a debit command. The virtual smart card generates its virtual smart card digital signature and the comnsand "Debit IE-W '. The digital signature and debit 75 commands are sent to the terminal. The debit command issued by tlae virtual smarf card may contain _ a wide variety of information including the virtu$1 srriart card identifier, the transaction identifier, the amount to be debited, the currency and currency exponent for the amount,, the virtual smart card digital signature;
the date, time, and location.1'he terminal in turn sends the digital signature, command, and the' 20 terminal identifier to the payment server.
Risk Management .Engine 111. The risk .management engine Ill is determines transaction validity using detailed heuristic processes.
Certificate authority digital signatures are, not only expensive to manage and computationally burdensome, but they place the issuer, typically a bank, in a risky ZS position. In a Cexti~.cation Authority Digital Signature (CADS) model, the compromise bf a Ceriihcatiori Authorit~s (CA) private key can be catastrophic.
For exartiple, bogus certificates may be issued and iirraudalent transactions iniriated, all seemingly authorized by the CA_ To remedy such a problem, the CA may have to re-issue certificates to every certificate holder and put every previously issued, certificate 30 on a C1Z.L. While a breach is undetected, the CA is in a very risky position.

AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 8 CA0100504 Consequently, Certification Authorities guard their private keys wide expensive physical and procedural security measures.
The Account Authority Digital Signatures (AADS) model, on the other hand, carnes no systemic risk. Without digital certificates, there is no technical need for a bank to have a private key. Most likely, any bank involved in PK.I transactions will likely have a private key,. but no certificates (or hierarchy of certificates) are inherently dependent on the security of that key in the AAI)S model. As attractive as AADS may sound, it will never eliminate the need for digital certificates. Tn cases where two parties have no prior relationship, third party certification makes sense. For example, , consider a retail customer wanting to open a new account with a bank over the Internet. The concept of a thixd-party certificate would aid the bank tremendously in making quick work of the electxonic sign-up process. This resembles the role that credit bureaus play today.
Third party digital cerii$cates will exist. Account authority digital signatures do not l5 preclude the ttse of CADS. They rely on the same cryptographic operations to validate digital signatures..The latter simply requires additional. steps in the validation process.
An accoe3nt authority can easily' become a certification authority by applying its digital signature to,a customer's public key rather than storing the public key in the account record. if an account authority wants to support frost propagation by issuing cenifcates,_it should, but it should do so based on a conscious business decision. $y requiring certificate authority digital signatures, as most existing methodologies do, banks are thrust into the position of propagating trust via digital certificates_ It is no longer a business decision but a technical requirement. Banks may not want to take on the risk of trust propagation. As account authorities they don't have to, and they can 2~ still remain central to the transaction processing business. .
VinuaISAPE's risk management , engine 11~ augments the payment processing functionality by providing intermediate vetting of transactions prior to execution by a remote processar_ Credit Risk Management occurs in different scenarios of customer enrolment, management, arid payment processing. Au individual ct~storner's credit rating is used to determine acceptability of payment transaction processing.
This value _47_ AMENDED SHEET

is collected either' at enrolment time or doting a profile update: It is retrieved by calling the local database using various information fields belonging to the customer.
The risk value returned is stored in the VSDB 1IS. At transaction processing time, the credit value rating is retrieved from'the VSDB 11S and used to evaluate~whether a transactio.~ should be transmitted to the payment processor. VirtualSAFE
raaintains ongoing transaction logs or a system transaction journal- That is, any transaction (e_g.
payment, customer profile modification, etc) executed using VirtualSAFE is stored along with the inform~atior identifying the transaction, issuer, date, resources affected, and T~egistered Resource Site status.
1U 2'S-ansactior~ Fulfillment Jl~echanicm (?'FM) vI2_ 'The transaction fulfillment mechanism lIZ is completes e-commerce transactions by means of a secure connection . with fulfillment providers. The TFM 112 includes a set of fraud management heuristics that are invoked in a progression that leads to a final fulfillment condition. The fiilfliment condition will dictate what type of delivery is to 1S be made and the associated criteria for completion. The TFM '~1~ and fraud management heuristic is comprised of several steps including the following:
1. Customer Authentication Scahring - .
2. Credential Identification Scoring . .
3. Transaction Risk Scoring 20 4. Fulfillment Response 5. Ful~llniem Delivery The first three of these steps are coxribined to achieve a transaction score that is used to determine ,the fulfillment response xnd type of fulfillment delivery. Each step is mutually exclusive with the corabined result determining fulfillment completion- The 25 above steps may be described in more detail as follows:
_4g_ AMENDED SHEET

w 19-07-2002 , CA 02405847 2002-10-10 _ CA0100504 Customer Autheiltication Scoring, This step is initiated by compiling the browser Ibgon criteria into a composite score. Elements from the.browser logon that may be considered include the following:
~ Certificate Authentication S . ~ Secure Cookies .
~ PIN or PIN value o SItP Verifications o ~ Other ~ .
Credential Identification Scoring. This . step creates a composite score based on the identifying elements in the order informarion. Each '~ai~e weighted and summed based .
on various criteria which may include the following:
~ Address o Amount Over Llmlt ~ s Declined ~ . Piug in Verifications Risk Assessment Tra3lSa~Cti4u type a Payment type ~0 - o ' Fraud ~. .

Third party assessment proof or change _ 4g _ AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 Transaction Scoring. This.,step involves computing a value and risk for the actual transaction being processed based on transaction attributes as follows:
a External:, Third Party Fraud Assessmern that' . is used for clarification of iatemal scoring and adjusts final conclusion and , instruction for fulfillment execution.
a Internal: Primary Attribute, Secondtuy Attribute,' Reduction, ~ Tune Up; Risk Adjustment, and Fraud Data Con~~gt~ation_ .
Fulfillment response. This, is' the required response to ~ the established criteria. The transaction will be tleated~ as a variant of "card pc~scitt", where the physical credit I0 card is actually .present, or "authorization", where the credit issuer must confirrit available credit.
Card Present V
4 Card Present R
. o Authorization I5 Fulfillment Deliver ..This is the resulting action taken on the composite score aver all . of the scoring attributes are evaluated and checked. The resulting delivery may include the following:
Request for signature Drop off 20 , .o Delivery 9 Signature a Photo 1D
-s0-AMENDED SHEET

19-07-2002 " CA 02405847 2002-10-10 CA0100504 Insurance Module T13. Through the insurance module 113, ViruialSAF1= provides liability and Transaction value insurance. A transaction value insurance algorithm is an .
active link to the Risk Management Engine. The adjustable architecture of this module provides a full and flexible policy for cumulative, minimum, and contractual . coverage related to policy and deductions.
Secure Transaction Repository 114. The transaction secure repository 114 records and securely stores every single transaction that is made by the user.
hirntalSAFE Deposit Box (VSDE~ 115: Through VirtualSAFE's implementation of an authentication authaurity Server. 10$, multiple entities {see below) may inter-operate on an open and non-misted network by means of AC access control.
VirtualSAFE permits electronic payment, credit cohection, and secure remote - fulfillruent processes. 'Through the use of the Virtual Smart Card IOfi, Secure Remote Pointer 1.Q3, Attribute Authority 104, .and other modules, ViriuaISAFE may be .
implemented in a variety of ways. Modularity of security objects and application .
objects enable .V 'irtualSAFE to be applied to numerous electronic commerce -environments: In ViriuaISAFE, an electronic inter=networking payment system provides for transactions using an electronic payment VSDB lLS for keeping money, credit cards, and other forms. of payment organized. Access to the instruments in the VSD'13 11S is restricted by encryption and authentication to avoid unauthorized 2U, ' payments.' A successful cryptographic authentication is required ill order to obtain access . to the - VSDB 115. The authentication protocol obtains the information necessary .for creating a network session granting authority to use an instrument, a payment holder, and a complete electronic wallet. Electronic approval results in the generation of an electronic transaction to complete the order.
?5 . C?peradan. Referring to FTG. 30, there is shown ~ a black diagram illustrating VirtualSAFE from a business-to-business perspective, and including an e-portal, in accordance with an embodiment of the invention. Referring to FIC. 3I, there is shown a block diagram illustrating the VirtualSAFE system from a business-to-consumer perspective, and including a merchant, in accordance with an embodiment of the 30 invention. Vit~tuaISAFE ensures security through a combinatiow of public key AMENDED SHEET

19-07-2002 P. o53/t t a CA0100504 certificates and attribute certificates which are deployed for authentication and authorisation purposes for each entity in the typical e-commerce transaction.
The following entities are typically involved in an electronic commerce (e-commerce) . transaction: Customer (or User); Merchant) Business; Shipper; Payment Processor;
Credit IssuerlCredit AcquirerlCredit Caid Vendor; ' and Bank Account. In order to ~maintai.n a strong coiuiection between security and business process, security objectives and business requirements are defined and merged in VirtualSAFE.
The security objectives are based on fundamental principles of canftdentiality, entity authentication, data integrity, and non-repudiation. In ge~tal, VimiaISAFE
provides 10, the following features and advantages to e-ccimnoerce entities:
I . Customer (or User).
~~ Customers may affect confidential purchases from merchants.
~ Only customers may access their purchase data.
2. ~IvlerchantlBusiness ~ . -Merchants have access to the following information: purchase related data submitted by customers; shipping related ~ data (e.g.
personal contact information); and, relevant payment information. ..
3. Payment Processor. . .
. o The Payment Processor require only payment processing credit information.
4. Credit Issuer l Credit Acquirer I Cxedit Card Yer~dor.
a ~ The Credit Issuer requires alI of the above ~nformarion.
.. 5. Bank Account.
m The aanlt requires only confirmation of the payment transaction.
-52=
AMENDED SHEET

19-07-2002. CA 02405847 2002-10-10 3 CA0100504 In operation, an electrotuc commerce system in accordance with an embodiment of the invention includes a client terminal, a merchant server, a payment server, and a VirtuaiSAFE server 108. A virtual smart card inside the terminal is in communication with the payment servex and other modules supported by a multi-tiered authentication authority. A method for conducting an electronic commerce transaction over the Internet using this electronic commerce system maybe describEd as follows:
Tnitially, a suitable web browser imi.tiated on the client ternunal is used to access a merchant server web site_ The user selects goods andlor services from the merchant site and~indicates to the site that the he or she wishes to purchase these items using a virtual smart card.
The merclxant sewer receives this request for a virtual card a~ansaction.
The merchant server builds an HTML page that includes several parameters.
These parameters include the total cost of the t;~ansaction as .detemtined by the merchant server, the type of currency being used, the part and IP address of the payment server, and a unique transaction identifier used by both the payment server and the merchant server to track a transaction. Also included is a .unique merchant idenrifier assigned to the merchant by the acquirer and known to the payment server. Other information znay also be included such as the cuttency's exponent, a status LTRL address of the merchant server used for communication fxom. the client terminal, and a merchant server generated key and other security in~ormatiou to ensure the identity of the .
merchant server and the integrity of the message. Other process related information such as software release level, encryption methodology, and keys may also be conveyed_ Once this page has been built, the page, is sent to the requesting client browser and triggers the iriitiatibn of a client terminal module in the client terminal.
Some browsers may not allow an applet to invoke a d~rnamic link library ("DLL") due to security reasons, . As such, in one embodimetlt of the ittvenrion, the client terminal apples, along with any DLLs needed, are pre-initiated on the client tet~ninal.
Then, the merchant server is allowed ~to invoke the client terminal apples and DLLs AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 dynamically to circumvent this security precaution. In an alternative embodiment, the client applet is signed to ensure its authenticity and integrity.
The client terniinal module then displays a screen containing the amount provided by the merchant acid requests that the user authorize the amount by entering their user , identifier (which preferably is masked on screen) and PIN. lJnce entered, the client terminal module routes the purchase request (including purchase parameters from the merchant server, user identifier and FII~ to the VirtualSAFE ~ server 108. The VirtualSAFE server 108 then validates the user idenii$er and PIN' with the user verification module.
1 U The client code module, of the VirntaiSAFfi server 108 then interacts with the pseudo technology process module to build a draw request message for later transmission to the payment server. It should be noted that at this.point tvc~o types of emulation occur.
The VirntaISAFB server 10S neither includes a physical smart card nor a virtual smart card. The physical card is represented as a virtual card in a recoxd of the card Z 5 database, while the virtual smart card is attached .to a remote payment.
servei. Thus, the client code module will emulate commands that a virtual smart card would issue lo build the draw request, while the pseudo technology process module; the smart card emulator and the database emulate a physical smart card.
In one embodiment of the invention, the client code module initiates a local DLL, 20 rr~akes an API call to that libraxy, which in turn makes a call to another l7Lh that finally makes a call to the pseudo technology process. An "Initiate VSDB for Purchase" command (Initiate VSDB) is created and forwarded to the emulator via the card reader module. This command is modified izl a suitable fashion to identify which record in the database will be debited (i.e. which virtual yard). For example, the user 25 identifier or FIN may be included. Next; the emulator parses the incoming~cammand.
and does a database fetch to obtain the virtual card record from the database.
In another embodiment of the invention, the fetch may '6e optimized to only retrieve certain information. The emulator then sends the record to the CEV 109 for decryption of the card data found in the record_ AMENDED SHEET

Unce responses to the "Initiate IE;W' (i.e. Intersectar Electrbnic-Wallet) command from the reader are received, the client module combines these responses into a byte stream suitable for transmission over a network to 'a payment server. Also at this paint, the currency type and expiration date of the virtual card in the database are checked, and the total cost of the ordered merchandise is checked against the card balance to ensure that the value on the card is great enough to~eover the txansaetion.
If the checks axe not successful, a message to that effect is delivered to the user and the transaction terminates.
Since the virtual smart .card is remotely located, it would not be advantageous to engage in numerous commands and respoxtses between the virtual smart card and the client code module over an open network such as the.Internet. In the interests of speed and reliability, it is advantageous to have fewer messages exchanged.
Accordingly, the client module emulates ' a variety of virtual smart card commands in order to receive responses to these commands from the pseudo technology process_ To operate securely and reliably in this environment, in one embodiment of the present invention, the client module emulates a virtual smart card and gathers all the responses for transmission in orie draw request message. The commands and . responses take ~ place, between the client code module and the pseudo technology process as if there were an actual card reader with a physical smart card inside. In other words; the client code module need not be aware that a virtual card is being used. The dxaw request message may include a variety of data including a draw request token, state information, the merchant identifier, the -transaction identifier, security information, a wallet provider identifier,: and an intersector electronic wallet ("iE-W ') identifier. Also the message may include an, algorithm used by the card, an 25~ expiry date, the balance of the card, a currency code, a currency exponent, the authentication mode of the IE-W, the transacrion number of the IE-W, a key version, and the purchase amount. As all of this information is prepackaged into a single draw request message, the number of messages over the lntemet between the ~irnzalSAFE
server 108 ~ and the payment server is greatly reduced.
3.0 In one embodiment, the draw request message is built by packaging the virtual card's '.
response to the "Reset". and "Initiate IE-W for Purchase" commands, any public key ' .

. AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA01005041 certificates, the total Cost, and the currency of the transaction received from the HTML page. For public key cards, the card and the issuer certificates are obtained from read conunands and may also be included in the draw request. By packaging aII
of this information together into one draw request message, it is possible to cut down on the number of messages exchanged between the 'VirtualSAFE server 1U8 and the l payment server and hence reliability and speed are improved, .
Next, the Virnu.aISAFE server x.08 accesses the payment server using the IP
address received from the merchant server. The VirtuaISAFE server 1Q8 sends the draw request message to the payment server,. The VirtuaISAFE server 108 also creates a log of the message being sent.
The payment server sends to the' client terminal the draw reQuest and processes the draw request in conjunction with an associated virtual smart card. In one embodiment of the invention, the payment server creates a transaction thread for each connected client modiilc to service it through the life cycle of the.trarisaction. The payment , server receives a debit command and a virtual smart card digital signature from the vit-tual smart card. .
The virtual smart card digital signature is a value that uniquely identifies and validates the virtual smart card to prove to the ViriualSAFE server 108 that the incoming debit command, is a valid command from a real virtual smart card. This validation ensures ZO _ that when the virtual card is debited the financial totals in the virtual smart card are updated. Thus, the user of the virtual card is guaranteed that a valid debit of the card has occurred. In one embodiment of the invention, the virtual smart card digital signature is an encrypted'value ensuring that no other entity can forge'an identity of a virtual smart card.
The payment server sends the debit command along with the virCUal srrrart card digital signature to the VirtuaISAfi~ server 108 to show die virtual card to accept the debit, At this time, xhe payment server also logs the debit command into its database. Upon receiving the debit command from the payment server, the client module replaces the a~naurtt in the debit command with the arigznal amount (from the merchant server] to AMENDED SHEET

19-07-200 , CA 02405847 2002-10-10 CA0100504 ensure that the amount has not been tampered with. while traveling over the network.
At this time, the client module may also create a log of the debit conunand_ The client module forwards the debit command and virtual smart card disital signature to the emulator and it again retrieves the appropriate virtual card record from the database for proeessiiyg. The card record is retained in memory while a transaction is occurring. The card record, debit command, and digital signature are gent to the CEV I09 where the vimtal smart card digital signature is verified and a virtual card digital signature is generated. 'tee card record is updated in the CEV Xp9 with revised parameters (ipeluding balance sad transaction ID) to reflect the purchase transaction and returned to the card database. The 4lieut module xeceives the CEV
~U9 response and generates a "bebit Response" message along with the card digital signature. If the virtuah card does not have enough value to satisfy the purchase amount, , thezi ~a "Debit Response" message indicates as such. The card digital signature is a unique value identifying a valid virtual card in the card database. In one embodiment of the invention, the digital signature is in ' encrypted form .to prevent tampering.
The emulator sends the response message along with the card digital signature back to the client module. At this point, the purchase amount has been deducted from the balance on the virtual card (assuming a successful transaction). Next, the client module packages the response message along with the card digital signature and sends them back to the payment server. .'Ihe client module also logs the result of this virnual card debit.
The payment sewer receives the incoming message and creates a log and updates the transaction status in its database for future error recovery. The payunent server then 25' directs this .received message to the. virtual smart card in the terminal.
Next, the virtual .smart cud processes this response i'rom the VirtualgAFE server 108 and verifies the received virtual card digital signature..
As the virtual smart card contains the keys and algorithms necessary to compute card digital signatures, the virtual smart card is abxe to validate that a received virtual card _57_ AMENDED SHEET

19-07-2002;" CA 02405847 2002-10-10 CA0100504 digital signature is in fact a valid one by comparing this card digital signature with a generated expected value: A successful comparison indicates that a response message received from the virtual card is in fact a valid message and that the vimtal card has been debited. An error result code or a comparison that is not successful potentially indicates that the virtual card Iias not been debited. This comparison of card digital signatures by the virtual smart card ensures that a virtual card is in fact debited before the merchant server is directed to release the purchased merchandise to the user. The virtual card digital signature is compared to an expected value and performed by the virtual smart card for the highest Level of security possible. This comparison of virtual card digital signatures may also take place in the payment server, in the YiriuaISAFE server ~ Og, in the client terminal, or in the merchant server, with a variety of other.advantages. Assuming~that the transaction is so far valid, the virtual smart card sends a response indicating the result of the digital. signature verification.
The payment server uses this response to build a '°Debit Result"
message. If the transaction was invalid ar if the verification failed, then an exception would be returned.
The terminal updates its data store with the virtual card number, a transaction count, and the total sale amount. Also updated is the response from the virtual smart card and transaction numbers from the virtual card and from the virtual smart card.
The 20~ payment ~servet also logs the response receivers from the terminal along with the merchant identifier, etc. Next, the payment server packages the result message including the transaction identifiers and se~ads this message to the VirtualSAFE server 108 ~ in encrypted form. The server then passes the result to the emulator far appropriate' database updates such as balance and Il?. The transaction is also logged in the history file.
The result message is then forwarded to the client terminal. At this point, the transaction thread of the payment server that was used for the curreat transaction may release the terminal, thus allowing the terminal to be used by other uansactions. The transaction thread then exits at this time.
-~8-AMENDED SHEET

By sending this result message in encrypted farm, the confirmation included in the message may be passed to the merchant server by way of the client terminal without fear of tampe>-ing. As the result message is encrypted, it would be extremely difficult for the client termixial or another entity to forge a confirmation and trick the merchant server into thinking that a transaction had taken place. In one embodiinetit of the invention, if the elieut terminal is a trusted agent, then the result message need not be encrypted. Fn yet another embodiment of the invention, the payment server may send two confirmation messages, one not encrypted for the client terminal to process, and vne encrypted for the merchant.server, or both-messages encrypted under different keys.
The client terminal then passes the result message on to the merchant server at the URL address previously received from the merchant server. The client may also post a message to the user informing that the debit has been completed. The client may also log confirmation of the payment. The merchant server registers the confirmation I S included in the message and checks for success. The merchant server calls a validate routine withixl the merchant code module to validate the result message received via the client terminal. The .validation routine decrypts the transaction identifier along with the encrypted result message. If the decrypted result message is:acceptable, the merchant server then determines that & successful transaction leas occurred.
next, the merchant server generates a message with the purchased information and delivers this information ro ,the client terminal. The merchant server may ~,ene~rate a purchase receipt to deliver to the client terminal indicating that goods and services are to be rendered. At this point, the client terminal may Iog the merchatlt server's response.
'-Completion of these steps indicates a successful financial transaction over the lnternet using a virtual smart caxd.
Far greater. clarity, the above method may be .described from a user's perspective as follows.
. First, a user sets up his or her virtual card within VirtualSAFE. In one embodiment of the invention, a physical card in the possession of the user is used.to provide some of the information requested by the VirtualSAFE server 10g. The user accesses the - - AMENDED SHEET

19-07-2002 CA 02405847 2002-10-10 . CA0100504 VirtualSAFE server 108 over the Internet using a VSAA login CTRi:. to access the user verification u~oduie. A screen is presented to the user which requests that the user enter his or her user identifier, a funding account number, the card verification value ("CVV"), expiration date of that account, billing address, electronic mail address, and a chosen PIN: Typically, the card veril'tcatian value is a 3-digit value on, the digital signature panel of a card and is used internationally for fraud deterrence.
The first _ time the user identifier is entered it is in the clear. Hovsrever, when the identifier is entered again by the user, this time perhaps for a nansaction, it appears rraasked on the ~' screen so as to be kept secret. The user vet~ification module then presents a screen to the user indicating that a confirmation will .be sent to .the user's electronic mail address. The user then logs out.
Later, an electronic mail confirrriation is sent that contains a one-time logon PfN. The user receives the electronic mail and begins the setup process by logging on to the URL of the VirtualSAFE server 108 and entering his or her user identifier and one-time PIN for checking by the user verification module. Once these are verified, the user is prompted to change the onetime PIN to a new user-selected PIN. The, user verification module then assigns a unique identification number ('°VSAA
card identifier") to the user.
During this session ar at a later time, the user initiates value .onto .the vimial card.
~ Initiation may be accomplished in several different ways. In one embodiment of the invention, a virtual card may come pre-initiated with. a certain amount when an account is set up, that is, the balance in the database is positive for a particular record.
Ocher methods of initiation may also he used.
The user accesses the merchant server web site via a communication link over she Internet. This web sit access znay be performed in any suitable fashion such as by using any commercially available web browser. Once at the merchant web site, the user is prompted to choose payment via either a physical smart card or via tlse virtual smart card of the present invention. Tf the user chooses payment via a physical smart card, then a purchase may proceed as described, in U.S. Patent Application No.
081951,614, which is incorporated herein by reference. If the user chooses the virtual _~0_ AMENDED SHEET

card method, then the user is prompted for his or her user identifier (which preferably is masked an screen) and PiN that is verified by the VirtualSAFE server 1U8.
Next, the user browses the merchant web site. and selects goods and services for purchase frn~u the merchant using the web site ipterface that the merchant has provided. The user then selects an appropriate button on the merchant web size to indicate what the user wishes to make a purchase. Next, the user receives a total sale amount from-the merchant server, a current balance from the VirtualS.AFF
server 108, and is directed to actuate a button on the web site indicating that the user-wishes to proceed with the purchase using the virtual card.
The system. processes the user order by way of the payment server, the YirtualSAFE
server 10~, the tem2inat, $nd the virtual smart card. 'The user's virtual smart card i5 debited by. the total sale amount and the user receives a "debited" message at the user's terminal. This message is optional and is dependent on system design.
The user receives a confirmation message from the merchant serer indieatiug that the 1 S transaction has been completed. The user may now dov~Ioad the purchased information andlor receive a receipt for goods and services to be reudered.Qr delivered from the merchant at a later date. ~ The merchant, via a clearing and setElement sysiem, receives payment to its bank account for the goods and services rendered by way of . ' . information collected from the payment server. In one embodiment ~of the invention, , an existing clearing aizd settlement system is used as is existing methodology ~ ~or transferring information from a smart card for, later reconciliation. This use of an existing "back ezid" allows the present invention to~be implemented more quickly and less expensively.
User Ercrollrtrent. Before using VirtualSAFE, users must be enrolled.
Referring to FIGS, 3 through 12, the following is a description: of the enrolment and sign-up process when. a user is initially introduced and registered as a primary new user within VirNaiSAFE, Merchant Enrolment. For merchant enrolment, the merchant has to authenticate an authorized person for VirtualSAFE. The authorized person enrolls the merchant by - ~1 -AMENDED SHEET

19-07-2002 ' ~ CA 02405847 2002-10-10 CA0100504 providing required iitformarion and documents, necessary for credit checks by a ciedit bureau or equivalent, as per local gQ:vernment regularions.
User Erwolment: Case 1. Referring to FIG. 3, there is shown a #lowchart illustratirZg the steps for user enrollment in VirtualSAFE, in the general case, in accordance with an embodiment of the invenrian.
User Enrolment: Case 2. Referring to FIG. 4; there is shown a flowchart illustrating the steps for user {or resource) eufollment in VirtualSAFE, in the case of "No Weh certificate + ~l VirtualSAFE Siga-Up Process + Payment Processing", in accordance with an. embodiment of the invention. The following steps are included:
Step 1- ACCESS ~ , ' User decides tv proceed'with purchase (BU's Step 2 - SSL Certificate Handshake Attempted .
The . Erst authentication takes place . as soon as the user has been accepted as a Registered User Site by use of the Secure Sockets Layer 1 S ~ (SSL). ~ ~ .
Step 3 - Is the User's WEB- Certificate present'?
The system checks to see whether or not the user's WEB certificate is present. Tn the case illustrated by FIG. 4, it isn't available or present.
Therefore, 'message 407.3 gets sent through the VirtualSAFE Web ?0 ~ . . Certificaie present site to the VirtualSAFE Web Certificate not present ' site indicating that no Web Certificate exists to authenticate the. user.
The user is redirected.
Step 4 ~- No Certificate SSL Session SSL session is established by the Well. Server generating a temporary 25 user session certificate.
AMENDED SHEET

Step 5 - Existing VirtualSAFE User Is the user an existing VirNaISAFE client or is this the first time they arevtrying to sign-up and process a payment? NO
Step 6 - Active ~XlJava ~ Applet/Application sends dedicated public WEB
S server key to client Once this has been done.
Step 7 - EnrolmentJregistratioti page The client is hyprrlinkad to the Enrolmetttlregistration page where They enter their personal. data, credit data, email data, etc. A(ote: The data i0 entered. by the user will not have to be entered again, as all of the information provided will be -stared in VirtualSA.Fl~. Once the user has completed entering their,.information:
Step 8 - Partial Enroizrient o A VirtuaISAFE certificate will be created for the user 15 o The user's data and the user's . VixtuaISAFE eerrifieate will be stored to the Secure Dana Repository.
~ . All of the user's VirtuaISAFE ~ data will be stored to the .
VirtualSAFE x500 ~ . The user's WE13 certificate will be created .
20- ' ~. The user's WEB certificate will be downloaded azid sent to them ~ The user's WEB data will be stored to the WEB x500 Step 9 - Confirmation to the user -- FuII enrolment WQUId you like to enroll with VirtualSAFE? ~'ES

AMENDED SHEET

Step 10 - Enrolment to VirtualSAFE community This is where the final user setup is confirmed and additional data is encrypted with the VirtttaiS,AFE Certification Authority Public Key, which also includes:
~ ~ ~ 1st identification string 2nd identi&catiou string a ' pyp,~c PIN' (pre'generated number) ~ Additional data eucryptect with. a VinualSAFE CA Public Key . . . . .
. ~ And, any keywords) that may be need for further au~~~catian Step 1 I - Tile enabler The user has become a registered and authenticated VirtualSA.FE user and can nuw shop anywhere an the net, their information is stored in encrypted form to Oracle, or any .database, etc., and an email ~af registered confumation- is sent tv them, as welt as a cancellation procedure. . . . . .
User Enrolment: Case 3. Refeixing to FIG. 5, there is shown a, flowchart illustrating the steps for user (or resource) enrollment in VirtualSAFE, in the case of "No WEB
certificate + Only Payment Processing' ; in accordance with an embodixneut of the invention. The following steps are included:
Step 1 - ACCESS
ITsex decides to proceed with purchase (EUY) Step 2 - SSh. Certificate Handshake Attempted AMENDED SHEET

' 19-07-2002 T' CA 02405847 2002-10-10 CA0100504 The first authentication tales place as soon. as the user has been accepted as 'a Registered ~Tser Site by use of the Secure Sockets Layer (SSL). ~ ~ ' Step 3 - Is the User's WEB Certificate pxesent?~
The system checks to see whether or not the user's WEB certificate is present. In the FIG. .5 ease, it isn't available or present_ Therefore, message 407.3 gets sent through the VirtualSAFE Web Certzficate present site to the VirtualSAFE Web Certificate nat present site indicating that no, Web Certif cute exists to autiaenticate the riser. The 1 D user is redirected.
Step 4-No Certificate SSL Session SSL session is established by the Web Server generating a temporary user session certificate.
Step 5 -- Existing VirtualSAFE User 3, 5 . Is the user ~an existing 'VinuaISAFE client or is this the first time they are trying to sign-up and process a payment? NO
Step 6 = Active X/Java AppletlApplicatian sends dedicated public WEI3 server key to diem t7nce this has been done.
2Q Step 7 ~ Etuolmentlregistrarion page The client is hyperlinked to ttie Enrolmentlregistration page where they enter their personal data, credit data, email data, etc. Note: 'The data entered by the user will not have to be entered again, ~as alI of the information provided will be stored in the 'VirtualSAFE. Qnce the user 25 has completed entering their i~orznation: _ .

AMENDED SHEET

1 9-O7'2OOi.. CA 02405847 2002-10-10 CA~~ ~~5(j4' Step 8 - Partial Enrolment ~ A VirtualSAFE cersificate will be created for the~user ~ The user's data and the user's VirtualSAFE certificate will be stored to the Secure Data Repository. - .
~ . ~ AlI of the user's VirtualSAFE data will he stared to the ViriuaISAFE x500 a The user's Wlr~ certificate will be created ~ The user's WEB certificate will be downloaded and sent to them ~ The user's WEB data will be stored to die WEB x5Q0 I(1 Step 9 - Confirrnarion to the user--Full enrolment Would you like to enroll with VirEUaISAFE? NO
Step I 0 - The enabler The user has become a registered and authenticated VirtualSAFE user and can now shop anywhere on the Internet, their iaformarion is stored I 5 ~ . zn encrypter~ form to Uracle, or any other database, etc., and an eiraait of registered corthrmation is sent to them, as well as a cancellation . . procedure.' .
User Enrolment: Case 4. Referring to FIG. d, there is shown a flowchart illustrating the steps for user {or resource) enrollment in VirtuaISAFE, in the case of "No Web 20~ certificate + Already a VirtuaISAFE member + Known PIN", in accordance with ari embodiment of the invention. Tlie (allowing steps are included:
Step 1 - AGCESS
User decides,to proceed with purchase (BUY) -bb-AMENDED SHEET

19-07-2002 w CA 02405847 2002-10-10 CA0100504 Step 2 - SSI. Certificate l~andshalce Attempted T'he first authenticatioa takes place as soon as the user has been accepted as a Registered User Site by use of the Secure Sockets Layer (SSL).
Step 3 - Ts the. User's 'W1~8 Certificate present?
Ttie system checks to see whether or not the user's WEB certificate is present. In the FIG. 6 case, .it isn't available or present. Therefore, - message 407.3 gets sent thmugh VirtualSAFE Rreb Certificate present site to t'~e Vittu,alSA.FE Web Certificate not present site indicating that IO . ~ no Web Certificate exists to authenticate the user. The user 1 is . redirected.
Step ~ ~ No Certificate SSL Session 5SL session is established by the Web Server generating a temporary user session certificate. .
, Step 5 - Existing llirnzalS.AFE User ' Is the user arr exisring VixxualSAFE client or is .this the first time they are trying to sign-up and process a payment? YFS
Step 6 -. Active XlTava AppledApplication sends dedicated public WEB
' server key to client . .
~ Qnce this has been done.
Step 7 - Identification strings authenticated ~ 1 st identificatifln string 2nd identification string a Search of x500 directory is done AMENDED SHEET
..

Step 8 - Is the user attthenricated? ' The system checks the VirtuaISAF>r x504 far verification,YES.
Step 9 - Creates new WEB Certificate (3nce the user has been authenticated, the system creates a new WEB
S certificate and downinitiations it w the client, and the Session Cookie is sent to the user.
Step I 0 - PIN idenrifxcation ~policyj The systcm.displays to tZle user the PII~t Identification Policy page.
Step 11-- Encrypted PIN authentication page The system checks to ensure whether the encrypted PIN number entered by the usex matches the encrypted PiN on the system.
If YES, the encrypted PIN matc3ies, then the user is sent to:
Step 12 - User Preference Page; and then to wherever they would like to shop on the net. ' i5 1-Iowever, if N4 the encrypted PI~T~ doesn't match, then the method illustrated in FIG. 5 is followed.
' User Enrolment: Case .5. Referring to FIG. 7, there is shown ~a flowchart illustrating the sieps for user ~(Qr resource) enrollment in VirtualSAFE, in the,ease of "No Web certificate wr Already a VirtualSAFE member -r Unknown encrypted PIN + email 24 notification", in accordance with an embodiment of the invention..The following steps axe included: . ' .
Step 1 -- PTI~f authentication page The system checks to ensure whether the encrypted. P1N number entered by the user matches the encrypted PIN on the system. If T~fO
_~g_ AMENDED SHEET

the encrypted PIN doesn't match, then: Message is seat by email to the user, and the user is redirected to the WEB enrolment page.
Step 2 - EnralmerJtIR.egistration page The client is hyperlinlced to the EnralmentlR.egistration page where they re-enterlar con~nn their personal data, credit data, email data, etc.
Mote: The data entered by the user will never ever have to be entered again, as ali of the information provided will be stared in the VirtualSAFE. Once the user has completed enteriri~ their intbrmatian:
Step 3 ~- A VirtuaISAp'E certificate will be created for the user ~ The user's data 'aud the user's VirtualSAl: E certificate will be . stored to the Secure Data Repository, ~ . .
o AII~ of the user's VimuaISAFE data will be stored ~ to the VirtuaISAhlr x50Q
1 ~ ~ ~ The user's WEB ce~.ttificate will be created ~ .The user's WEB eertifcate will be downini.tiationed and sent to them ~ . .
~ The user's WEB. data will be stored to the WEB xS00 Step 4 - Confirmation to the user Would you like ~ta enroll with VirtualSAFE? N~
Step S - The enabler The user has became a registered and authenticated VirtualSAFE user -and can now. shop anywhere on the net, their information is stared in ' ' encrypted form to Oracle, or any other database, etc., and an email of -fi9-AMENDED SHEET

registered confirmation is sent to therri, as well as a cancellation procedure.
User Enrolruent: Case 6. Referring to FiG. 8, there is shown a flowchart illustrating the steps for user (or resource) enrollment in VirtualSAl='E, in the case of "NQ Web S certificate + Already a VirtualSAFE member + no xS00 entry", in accordance with an embodiment of the invention. The following steps are included;
Step 1'- ACCESS
User decides to proceed with purchase (BUY) Step 2 - SSL Certificate Handshake Attempted The first authentication takes place as soon as the user has beetz accepted as a Registered User. Site by use of the Secure Sockets Layer (SSL):
Step 3 - is the User's ~B~ Certificate present?
The system checks to see whether or not the user's WEB certificate is present. In the FIG. 8 case, it isn't available or present, Therefore, message 40'7.3 gets sent through VirtuaISAFE Web Certificate present site to the VirtualSAFE We6 Certificate not present site indicating that no Web Certificate exists to authenticate the user. User redirected. .
Step 4 -- No Certificate SSL Session ~ SSL session is established by the Web Server generated a temporary user session certificate_ Step S - Existing VirtualSAFE User .
Is do user. an existing VirtualSAFE client yr is this .the first time they are trying to sib-up and process a payment? NO .
AMENDED SHEET

' 19-07-200 CA 02405847 2002-10-10 CA0100504 Step 6 - Active XlJava AppletlApplication sends dedicated public' WFB
server key to client Once this has-been done.
Step 7 - Identification swings authenticated ~ .' 1 st identification, string a ?nd identification string o Search of x500 direGtary is done Step 8 - Is the user authenticated? .
The system checks the VirtualSAFE x500 for verification. NQ:
Step 9 - EnrolmentlRegistration page The client is hyperlinked to the Bnrolzne~at/Registratiou page where they re-enterlar confirm their personal data, credit data, email data, etc.
Note: The data eutered~ by the user will never ever haire to be entered again, as all. of the information provided urill be stored in the I S . VirtuaISAFfi. Once the user has completed entering their information:
Step. I0 - o A VirtualSAl~E certificate will be created for the user s The user's data and the user's VirtuatSAFE certificate will be stoxed to the Secure Data Repository. .
~ AlI of the - user's VirNaISAFE data will be stored to the VirtualSAFE x500 v .
' . ~ ~ The user's WEB certificate will be created _7I_ AMENDED SHEET

J
19-07-2002, , CA 02405847 2002-10-10 CA0100504 ~ The user's WEB certificate will be downinitiationed and sent to there ~ The user's WEB data will be stored to the WEB x500 Step I 1- Confirmation to the user . Would you like to enroll with Yiztttal.SAFE? Y'1=S/Na Step I? - The enabler The user has become a registered and authenticated 'VirtualSAFE user and Can, now shop anywhere an the net, their information is stored in encrypted form to t?racle, or any other database, etc., and an entail of registered confirmation-is sent to them, as well as a cancellation procedtue.
User Enrolment: Case 7. Referring to FIG. ~, there is shown a flowchart illustxating the steps for user (or resource) enrollment in VittualSAFE, in the case of "Web certificate t Unknown/ICnown PIN", in accordance with an embodiment of the invention. The following steps are included:
1.5 Step I - ACCESS
User decides to proceed with purchase (BUYy Step 2 - SSL Certificate Handshake Attempted . The first authentication takes place as soon as the user has been accepted as a Ttegistered User Site by use of the Secure Sockets Layer 20. (SSL).
Step 3 -- Is the WEB Certificate present?
The system checks to see whether or, not a WE13 certificate is present.
In the FIG. 9 case, the WEB certificate is present.
Step 4 - WEB Certificate is present _~2_ AMENDED SHEET

The system performs a two-way authentication process.
Step 5 -- Checks VirtualSAFE certificate - xS00 The : system checks the VirtualSAFE x500 to Electronically Authenticate the computer. -- Step 6 - Checks for VirtualSAFE certificate The system checks for a l~irtyalSAFE certificate by #lacing the VirtualSAFE 'x.500 directory. When the system cotifirins that the VirtualSAFE certificate is avaslable, the user is routed to Step 7.
Step 7 : - Active XlJava Applet/Application ' sends dedicated public WEB
server key to client Once this has been done.
Step 8 - Identification strings authenticated 1st identification string 2nd identification string (optional) 1 S , o Search of x500 directory is done Step 9 -.T~ the user authenticated? ' The system checks the VirtualSAFE xS00 for verification. YES. ~ , Step i0 - Active .XlJava AppletlApplication sends dedicated public WEB
server key to client ' Once this has been done. ' Step 11- PIN identification (policy) ' ~ ' The system displays to the tuer the F.IN Identification Policy page.
_73_ AMENDED SHEET

' 19-07-2002, CA 02405847 2002-10-10 CA0100504 Step 12 - PTN authentication page The system checks to ensure whether the PIN number entered by the user matches the PiN an the' system. If YES, the PIN matches, then the . user is sent to: Step 13 - User Preference Fage, and then to wherever .
they would like to shop an the net. However, if NO the PIN doesn't match, then the FIG. 7 method is followed to completion.
User Enrolment: Gale 8. Referring to FIG. I0, there is shown a flowchart illustrating the steps far user (or resource} enrallment in VirtuaiSAP'E, in the case of "Web certificate (No VirtualSAFE) + Unknowt>lKnown PIN", in accordance with an embodiment of the invention.. The following steps are included:
Step 1- ACCESS -User decides to proceed with purchase (BUI~
Step 2 -- SSI. Certificate Handshake Attempted The first authentication takes place as- soon as the user has been r 5 accepted as a Registered Uses Site by use of the Secure Sockets Layer (SSL): .
Step 3 - Is the WEB Certificate present?
The system checks to see whether or not a WEB certificate is present.
1n the FIG. 10 cue, the WEB certificate is present.
~ Step 4 - WEB Certificate is present The system performs a two-way authentication process.
L
Step S - Checks VirtuaISAFE x500 ~ ' The system checks 'the Vit2ualSAFE xSUU to Electronically Authenticate the user. The e-authenticate interoperable module checks the validity of the web certificate by checking the content of the AMENDED SHEET

19-07-2002. CA 02405847 2002-10-10 CA0100504 directory of the originating CA. The VirtualSAFE Policy will determine whether the VirtualS.AEE directory, or. the originating directory is checked or bath are checked.
Step 6 - Checks fox VirtuaISAFE certificate The . system checks for a VirtualSAFE certificate, by flagging the YirtualSAFE x500 directory. If the VinuaISAFE certificate cannot be verified, then the user will go to Login to Virit~alSAFEIEnro1 in VirtualSAFE to be confirmed and then carry on to Step 7.
. Step 7 -- Active XlJava ApgIetlApplioatiori sends d~adicated public WEB
server key to client .
Once this has been done.
Step 8 - Identification strings authenticated a 1 st identification string 2nd idenrification string (optional) .
, ' g Search of xS00 dixectory is done Step 9 - Ts the user authenticated?
The system checks the VirntalSA~L x500 for verification. YES.
Step 10 = Active Xl3ava Appiet/Application sends dedicated public WEB
server key to client -Once this has been done, Step 11- PIN identification (policy) The syste~t displays to the user the P1N Idenrivcauon Policy page_ Step I2 - P1N authentication page AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 The system checks to ensure whether the PIN number entered by the . user matches the PiN on the system. If YES, the PIN matches, then the user is sent to: Step 13 - T.Jser Preference Page, and then to wherever they would like to shop on the net, However, if NO the I'IN doesn't rilaich, then the meth4d of FIG. 5 is followed to eampletion.
User Irtirolment: Case.9. Referring to FIG. 11, there is shown a flowchart illustrating the steps for user (or resource} enrollment in .VirtualSAFE, ~ the 'case of "VVEB
certificate (No . VirtuaISAFE) + EnroimentlPayment Process", in acGardance with an embodiment of the invention. The following steps are included:
Step 1 - ACCESS
User decides to proceed with purchase (BLJY) Step 2 - SSr, Certificate Handshake Attempted The first authentication takes place as soon as the user has been accepted as a Registered I3ser Site by use of the Secure Sockets Layer is (ss~.).
Step 3 - Is the VVEB Certificate present?
The system checks to see whether or not a WEB certificate is present.
In the FIG. 11 case, the WfiB certificate is gresent. .~
Step 4 - WEB Certi$caie is present ' The system performs a two-way authentication process. -Step 5 - Checks VinuaISAFE xS00 The system checks the VirtualSAFE x500 to Electronically Authenticate the user. The e-authenticate interoperable module checks the validity of the web certificate by checking the content of the ' . . directory of the originating CA. The VirttfalSAFE Policy will _70_ AMENDED SHEET

detemline whether the VirtualSAFE directory, or the orFginatiny directory is checked or both are checked.
Step 6.-- Checks for VirtualSAFE certifecate The system' checks fox a VirtualSAFE certificate by flagging the ' VirtualSAFE x504 iiirectary. When , the system confirms that the VirtualSAF)r certificate is available, the user is routed to Step 7. If the VirtualSAFE certificate cannot be verified, then the user will go to Login to VirtuaISAFEIEnroll in VirtualSAFE to be confirmed and then catty on to Step 7. ~ ~ .
. y Step 7 - Active Xldava AppletlApplication sends dEd,icated public , WE8 server key to client . -Once this has been done.
Step 8 - Enr olment/Registxaliail page The client is hyperlinked to the Enrolment/Registration page where they re-enterlar conErm their personal data, credit data, email data, etc.
Note: The data entered by the user will never ever have to be entered again, . as all of the information provided will be stored in the VirtualSAFE. Once the user has completed entering their information:
Step 9 ' a ~ A VirtuaiSAFE certificate will be created for the user a 'fhe user's data and xhe user's VirtualSAFE certificate will be stored to the Secure Data Repository.
~ Ah of the user's VirtualSAFE data will be stored to the VirtualSAFE x50Q
. Step 10 - Confirmation to the user AMENDED SHEET
_77_ Would you like to enroll with VirtualSAPE? NO
Step 11- The enabler The user has become a registered and authenticated VirtualSAFE user and can now~shop anywhere on the net, their information is stored in encrypted.form to Qracle, yr any other database, etc_, and an email of registered confirmation is sent to ahem; as well as , a . cancellation procedure.
CA Processes. Referring to FIG. 12, there is shown a flawchatt illustrating C~-process steps in accord~ce with an embodiment of the irivetttioa. Tl~e steps to be . followed are as per Cerrificate Policies (CP) and Certificate Practice Statements {CPS).
Enrolment Policy. Procedures for handling incorrect PIN or tnistyped PIN are handled in accordance to VirtualSAFE Paliey and/or MerchantJT3usiness Policy.
Module Black Diagrams. In the following, and referring to FIGS. I3 through 29, block diagrams and more detailed descriptions are included for selected VirtualSAFE
modules.
Participants. Referring to FTG. I3,. there is shown a block diagram illustrating the participants and their contractual relatidnships~in VirtualSAFE in accordance with an embodiment of the invention. 'fhe electronic commerce environmenn requires signifccant security and auditing processes bound to the actual business operations and processes. Accordingly; the primary concerns are the contractual relationship between parties, the enfarcemeztt of the business policy, and the transparency of the processes.
1. ViriuaISAFE Business Policy. Within the VirtualSAFE Business Policy there are three main components that that will never be comproraised and 2S theyV are: Privacy, Security, and Ease of Use. -o Privacy- The securely structured attributes that are handled arid covered under the Privacy aspect of the VirtuaISA);E Business Policy include:
_78~
AMENDED SHEET

I 19-07-2002 CA 02405847 2002-10-10 ~ CA0100504 o ACCESS And PRIVILEGES. In VirtualSAFE, only the user Itas access to their private information.
Compliancy And ~ Standards. VinuaISAFE adheres to the World Privacy Regulations and Standards-' ~ Higher Power Rule. in VirtualSAFE, Third Party access to . ~ private and personal information can only be granted by Court Order. This, signifies the only time when a user's private information can be attained other than by the user.
Security: The securely seructured~ attribuW s that ure handlrd ~cnd covrrrd , under the Security aspect of the VirtualSA.FE Business Policy include:
o - International ' Security Standards. ViriuaISAFE follows ail international standards for the security within x500 directories and is 140 FIPSl3 Complaint.
a Ivlonitoring, Support And Control. VinuaISAFE is ~ comprehensively monitored 24 howl per day, 7 days per . week. There is no shutdown time and support is readily available if required.
g Remote Virus Scan. VirntaISAFE is contir<uously being ' ' upgraded With new virus protection directly and remotely to ensure the optimum in service, and security structure. As a leading technology . in commerce secure systems, VirtualSAFE provides their users with the confidence that their information is secwre from any virus and/or unwelcome invasion.
0 Ease of Use. The securely structured attributes that are handled and covered under the Ease of Use aspect of the VirtualSAFE Business Policy include:
_7g_ AMENDED SHEET

m User Experience. VirtualSAFE does not change the experience of the present user meaning that the user already has whe basic skills that are required in order to use VirtualSAFE=
~ a Info Entered C)nce. In YirtuaISAFE, the user only has to input their piivate and peTSOnal infozma~on once, and then it is stored in the VircualSAFE. Hvery time they login afterwards, their identity and credit attributes are linked to their digital 1D.

Click And-Go. - VixtualSAFE users inexperience Click-and-~'ro from any VirtualSAFE site. E Their digital IAs are recognised everywhere and they can jump from site to site quite easily.
2. Business Folic~Third Party). VirriialSAFE has the capability, and 1S . complies to other businesses' business policies, so as not to comprise their way of doing business.
Enrolment. Referring to FIG. 1~, there is shown a block diagram illustrating the enrollment process in . VirtualSAFE in accordance . with an embodiment of the invention. VirtualSA.FE registers users' personal data (i.e. credit card information) 20 once. Data pertaining to their enrolment, autlrentication, and reference is contained within VirtualSAFE. The User is issued a digital ID so that the user never has to enter their data online again. .Enrolraent data is stored securely ~ in VirtualSAFB
under a strict policy.
1. Eurolemept in VirtualSAFE.' In VirtualSAFE, there are four enrolment 2S levels: resource enrolment, customer enrolment, attribute resource enrolment, and employee enrolment. With respect to employee enrolment levels, two controls are established, both locally and remotely: IT Access Control fuid Physical Access Control.
-SO-AMENDED SHEET

19-07-2002. CA 02405847 2002-10-10 CA0100504 2. VirtualS.AFE Customer Authentication Enrolment.'OVithin VirtualSAFE, customers are authenticated using their digital IDs.
.3. User Authentication. Within VirtualSAFE, the users are authenticated using their digital IDs. , 4. Reference Validation. If for some reason there is a problem in recognition, then reference validation is the next step used to authenticate the user, customer andlor resoexrce.
(online Transactions. Referring w FIG..IS, there is shown a block diagram illustrating the online transacrion process in VirtualSAFE in accordance with an embodiment of the inyerltian. VirtualSAFlr operates as . an authentication layer or ~
authentication authority between the .usex, the terminal and the ViriuaISAEE server. Through a multi-tiered autixentication mechanism, ~ the remote user is queried and authenticated to produce smart card emulation as if the physical card was present. , 1. Customer' Browses Site. In VirtualSAFh, customers using their digital , ' certificates enables them to browse their online banking sites and use the smart card application.
Z. Secured And Authenticated Access. Ortce-the userlemployeelcustomer has been authenticated. in VirtualSAFE, they have access to online banking, the onli~cie brokerage, account data aggregation reports and audit performance, and online payment transaction requests; such as creditldebit card, electronic check, wire transfer, etc. They also have access to a VirrualSAFE Aepasit 8a~ tVSDB).And f~cnally, the users have access to other valuable services such as, the following:
Secure e-mail ' o Logistics support for individual, small and medium-sized businesses. ' ~ An application front-end that is easy to understand and use_ AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 Application accessible through the interJititranet.
VirtualSAFE is interoperable with existing pr6fessional or custom applications.
1 Secure collaboration place.
S Server Authentication. Referring to FIG. 1b, there is shown, a block diagram illustrating the server authentication process in llirtualSAFE in accordance with an .
embodiment of the invention. The Secure Remote Pointer (SRP) is a VitntalSAFE
compatible application that inns as a web browser plug-in, applet or.application. The, SRP is used by the user browsex client io conduct secure commuuicaticn with VircualSAFE. This pxocess is initiated when the user clicks on a redirection link (RL) that requires an authentication and authorization , check. ~ The SSL Server Authenticatiotz is established as follows:
I. .VirtualSAFE Server Initiates one-Way SSL xiandshake With User.
2. Server Authenticarion. The server is then further authenticated as VirtualSAFl~ stores the transmitted irifozmation and queries the received digital. certific$te.
Computer Authentication. Referring to FIG. 17, there is shown a block diagram illustrating the computer authentication process in't~irtuaISAFE in accordance with an embodiment of the invetltiatl. The VirnvaISAFE Virtual Identity (YI) process involves the use of a PKl Digital Ceni~cate: The Virtual Identity (VI) includes the following:
A Web certificate from a third party or ECA public and private key of the . .
user.
a Authentication is initiated over a secure SSL channel Computer Authentication is established as follows:
2. VirtualSAFE Server Initiates a One-Way SSL Handshake.
_$2_ AMENDED SHEET

2. Aigital Certificate (Pt~l~ Establishes a T~?vo-Way SSL Handshake. 'The two-way 5SL handshake ensures that VimxaISAFE interoperability functions properly, VizxualSAFE is X509 compatible with Entrust, I3altymore, Verisign,~ etc., VirtualSAFE second phase is EC~2 compliant (Certicom), and that 'YirtualSAFE is compliant with other PK.I standards (i.e. Meta, etc.).
3. By Verification of X504 Global Directory. VirtuaISAFE is fully capable of determining certificate authenticity by verifying public directories (e.g.
Entrust, Baltimore, Vensagn, etc.).
User Authenticarian. Referring to FIG. 18, there is shown a block diagram illustrating the user authentication process in VirtualSAFE in accordance with an embodiment of -the invention. 'fhe entire communication will take plarx over a client-sewer authenticated SSL channel establishing two-way .- authentication using digital certificate distri~hution. Encryption and signing of the data package is completed 1 S entirety within the secure confines of the Secure Remote Pointer (SRP).
The user data stored in the Virtual Identity may include the following:
a Encrypted f IN and other access data Authentieauon Authority (AA) reference data ~ Personal User Data . o ~ Financial User Data - -tarlce the user.data has been stored withitl VirtualSAFE; the following steps may take place to ensure that the~user is authenticated:
1. Virtual SMART GARD (VSC) is~ activated. A remote virus. check is peifarm.ed and an optional keystroke is checked and the VirtualSAFE
certificate application is validated.
2. VirtuaISAFE Secure Plug-In I Application Aecivated.

AMENDED SHEET

3. User Presents Identification Strings.
4. . Virtual Smart Card=Identi$es User in VS XS00 Directory.
5. lJser's Pir~. And Tiruestarttp are Triple Encrypted - Digitally Sigied.
G. VirtualSAFE Decrypts Digitally Sigied User's Pin And Timestamp.
S 7_ I3ser Encrypted Pin Is Validated by VirtualSAFE.
8. VirtuatS.A.FE Encrypted~Prefix Validated by Supervisor.
9. VirtuaISAFE Proceeds with Back-End Authentication.
Back-End Authentication: Referring to FIG. 19, there is shown a block diagram illtistratitlg the back-end authentication process in VirtualSAFE
in'$ccordance with an la exnbodimettt of the invention. The VirtualSAFE Payment Processing Engine consists of servers , and connectivity to a payment ,gateway_ The VirtuaISAFE Risk Management Engine augnents the payment. processing fun.ctianality by providing . intermediate vetting-of transactions prior to execution .by a remote pirocessor. Credit Risk Management occurs in different scenarios of customer enrolment, management, 15 and payment processing. An individual customer's credit rating is used to determine acceptability of payment transaction processing. For back-end authentication, the following six steps are included in the authentication: process:
1. Risk Management. Score value verificateans are done.both internally and externally and VirtualSAFE stores the assessment result.
20 ~ 2. Insurance Module -~ Policy Adjustment Limit.
a $usiness Liability Policy- Transaction Value ~. User Liability Policy - Limited by Credit Worth 3. lVlessaging - E-Mail or Notification a Internal - Business Unlit or Adzninistxator AMENDED SHEET

R ' External - Business Partner or User 4. ViitualSAFE Encrypted Transaction Log. An encrypted txansactian lag that stares all transaction records going through the VirtualSAFE.
S. Policy. Three policies are used in hack eud authentication: PK.I Policy (PC
and PCA) as regulated by standard procedure; VinualSAFE Privacy and Business Policy; and, Third Party Business Policy.
6. Fulfillment Procedure. The fulfillment procedure for back-end authentication is just that, a fulf'~llm.~t. Authentication of transactions, communications, data . storage, acrxss control, administration, . and VirtualSAFE value-added services is completed.
Fullllment. Referring to FIG. 20, there is shown a block diagram illustrating, the fulfillment process in VirtualSAFE in accordance with an embodiment of the invention. The VitrtualSAFE Transactiah Fulfilment Mechanism (TFM) consists of a set of fraud rnanageraent heuristics that are invoked in a prbgressian. The fulfilment condition will dictate what type of delivery Z5 t4 be made. The TFM and fraud management heuristic is comprised of the following steps:. .
1. Customer Authentication Scaring 2. Credentyal Idenuficanan Sconng 3. Transaction Risk Scoring 2Q ~t. Fulfilment Response 5. Fulfilment Delivery The transaction fulfilment mechanism (TFM) assures the following:
Secured txarisactions Customer and merchant audits -SS-AMENDED SHEET

' 19-07-2002 CA 02405847 2002-10-10 ~ CA0100504 ~ Customer and merchant liability insurance ~ Transaction value insurance ~ Fraud control Delivery control ~ Loyalty program v 3n assuring these items, the' transaction fulfillment mechanism (TFM) .
allows for the following payment types to be performed:
~ . Online credit card payri~ent ~ . .
~ Debit card payment.. ~ , , m Electronic check ~ . ' ~ Wire ~ ' Eiectronic transfer of funds . _ ' ~ Cain payments _ ' b Stared-value cards ' The transaction fulfillment mechanism (TFM) also provides the fohowing services:
~ ~ Data storage , .
Secure e-mail 4 . Logistic ~ support for individual, ~ small and 'medium size businesses including the following features: an application front-end that is easy to understand arid xhat is user friendly; the applicarion is accessible through the intemetlintranet; and, VirtualSAFE is interoperable with existing professional or custom applications.
-~86 -AMENDED SHEET

19-07-2002 ~~~ CA 02405847 2002-10-10 .CA0100504 Secure collaboration place Attribute Authentication Authority. Referring lo FIG. 21, there is shown a block diagram illustrating the attribute. authentication authority process in VirtualSAFE in accordance with an embodiment of the invention. By definirion, access control entails the limiting of activities of a user on the system. Enforcement of such controls is accotttplished by maintaining a reference monitor that mediates access attempts by consulting an authorization base to det~xriine if the user attempting the access is authorized to do so. A distinction is made here between .authentication and access control, where authentication merely confirrris the identity of the user, while access ~ control establishes identity privileges on the basis of successful authentication.
Virtual Identity ~VI~ Referring to FIG. 2Z, there is shown a block diagram illustrating the virtual identity (VI) process in ViriuaISAFE in accordance with an embodiment of the invention.'~3ser.identity authentication is initiated for each individual transaction by triggering a rnulti-tiered algorithm that employs Vinual Smart Card technology to interface with standaxd PKI. . Authentication, is only possible when the user.'S
personalized "virtual smart card" allows VirtualSAFF to access the respective 'virtual identity".
1. Vixtual Identity (VI] Private Information. VI is used to create and maintain encrypted data from source data based on provided and validated information.
2. Virtual Identity (V t) Secret Information. VI maintains this information that is. encrypted and accessible only to a single user. Only the user knows secret information whose secret it is.
3_ Virtual Identity (VI) .Shared Secret Information. VI maintains this information that is encrypted and accessible only to the .user and the VirtualSAFE proxy. Secret information is latown only by the user whose secret it. is and by the VirtualSAFE proxy.
_87_ AMENDED SHEET

J
19-07-2002 ~ ~ CA 02405847 2002-10-10 ~ CA0100504 4. Virtual Identity (VI) Physical Material. ' Physical material could be represented by digital certificate or a unigue software code (e.g. script, prQgtarri or special code). Physical material zriay include the following:
Local, Digital Certificate (Personal Computer, Computer andlor Web I?igital Certificate, Smart Card, Magnetic Card or any device operated by the user); VirtualSAFIr Certificate (Digital Certificate is a Digital Certificate stored in any type of Repository or VirtualSAFE Repository managed by VirtualSAFE); ~ axld, Unique Tdentifier (Identifier issued uniquely to a user). Technological standards may include the following-Encryption Basis (RSA, Cl?V and other types of algorithm) and Public Key Infrastructure (PKI, X500, IViETA, etc.).
Virtual Smart Card ~VSC). Referring t4 FIG. 23, there is shown a black diagram illusuatirtg the virtual smart card (VSC) process in VirtuaISAFE tat accordance with an embodiment of the invention. The Virtual Smart Card (VSC) is a VittualSAFE
1 S internal application . that , acts as a local secure ' proxy to an external virtual authentication token accessed via the Secure Remote Pointer (SRP). The- VSC
authenticates, encrypts and decrypts VirtualSA~E user data using a multi public I~,ey infrastructure (PK.I) managed service. The VSC implen~e~nts a mufti-tiered PKI
by designatixlyduai sets of key pairs for each user: one External and one Internal Public-Private key pair.
1. Virtual Smart Card {VSc) functions a The Virtual Smart Card is the emulation base of the reader and the smazt card an a remote location.
~ The Virtual Smart Card is used to authenticate user access.
?5 . ~ All information belonging to enrolled members is stored and protected by. ~a proprietary encryption scheme .using a high-speed hybrid approach. .
The Virtual Smart Card coordinates the privacy policy.
_88_ AMENDED SNEET

19-07-2002. CA 02405847 2002-10-10 ~CA0100504 ?. VirtualSAFE Digital Certificate (I3C) Repository w Users reruote or roaming digital cetti&cates are stored securely.
3. Virtual Smart Card Authenrication User authenticarion using virtual idenrity_ S ~ User identity is combined of secret, shared secret arid physical elements (PKr}.
4. Access Portfolio o Private, Shared, .business or Crovernment.
5. Personal a»d Financial (P/F) hnformariozz . .
o Personal identity data {e.g. ID, driver's license, address, health card, etc.).
Financial information {e.g. account numbers, creditldebit card, wire, etc.). .
G. Applications ~ ' . ~ . , ~ Remote so~hvare licensing.
7. Back-tip ..
Transaction logs.
a Transaction revisions.
~ Logs.
S. Internal Access a VirtuaISAF~, Private, Shared, Business and Government.
_g~..
AMENDED SHEET

19-07-2002 , CA 02405847 2002-10-10 CA0100504 VirtualSAFE Deposit Box i~VSDB~.. Referring to FIG: 2~, there is shown a block diagram illustrating the Virtu.alSAFE deposit box (VSDB) process in VinualSAl:E in accordance with an embodiment of the invention. VirtualSAFE inay also include an ASP (Active Server Pages) module. This will allow a user to access over nvo hundred news, stock, and information sources. The user can choose fxom entertainment headlines, custom stock quotes, horoscope and relationship information, health and lifestyle stories, sports scores, news, and much more. To take advantage of~these opportunities, the user will need to sign in with a VirtualSAFE VSC (Virtual Smart Card}. The VixcualSAFE VSC is a single name and PIIV that users can use to si,au on to a number of major sites .from ViriualSAFE compliant companies. VirtualSAFE
uses AA to store the users VirtualSAFE settings, such as th.e content and colors they would like to see on their VirtuaISAFE page. Usexs' , personal and financial information, and their preferences, etc., are also stored.' Since VixtualSAFl3 uses AA
and VSDl3 to store these settings, the user may View their VixtualSAFE page from any computer connected io the Internet. Also, each utember of the user's family with a VirtualSAFE VSC may create and view his or her own. personal. VirnzalSAFE
page from the same computer. The user simply has to sign into VirtualSAFE when they.
visit the VirtualSAFE web site. The user may obtain a VirtualSAfE VSC and learn more about the advantages of having a VSC from a VirtualSAFE web site.
2Q By signing into VirtualSAFE with a VSC, a user will be able to:
a Find out if they have mail or if their friends are online.
Persflnaliae their VirtualSAFE home page once and view it froth any computer, at home, at work, or on the road.
a Choose headlines from popular websites.
a Sign in safely and securely to access their personal settings. The user, and only the user; is the only person who may . access his or her choices.
_9p_ AMENDED SHEET

A user may also create a VinualSAFE VSC test account. To do this, a user must register for a new' VirtualSAFE account directly at the domain authority. Once the user's account is created, they will need to sign into a VirtualSAFE VSC
Purchase {WP) service site as a registered user. This allows the user to add a credit card, billing address, and shipping address to their. VSDB. The user may want to create 'VSDB information for test-purposes that does not have .genuine and negotiable credit cards attached to it.
The VSDB servex code may run a Luhn checksum test against alI provided card numbers at input tittle. The Luhn checksum test is mainly intended as a convenience for users who may have mistyped their number,, but it is not a credit card verification, security check, or authorization per se. The Luhn checksum test will prevent a purely random credit card number from being accepted as part of VirtuaIS.AFE Deposit Box data_ VirtualSA.FE may performs other basic authorization and validation checks (e.g.
statelZIP code or Province/Postal code) when establishing a VSDB far a VirtualSAFE
user. A phone number and e-mail addresses,may be required fields for establishing a VSDB, even,thou~;h they may be optional for a ViritzalSARE profile.
The WP service -is an easy-to-implement, server-based VSDB system that uses standard HTTP and Secure Sockets Layer (SSL) methods/PrGl-based tv post payment information to participant sites. ViriuaISAFE supports the Irlectxonic Commerce 20. Modeling Language (ECML)'which is ati industry-standard e-commerce schema.
The V SDB is compatible with popular web browsers. The V VP futlctions as follows:
1. When a user clicks an express purchase link at a participant site, the WP
..
service sends the user forward to the VirtualSAFE VSDB and then authenticates 'tbe user and presents- a page showing a. list of that user's 2S credit cards and addresses. This information represents the user's V SDB.
The user selects the means of payment and. the address to use for the transaction and then presses a button to continue.

AMENDED SHEET

19-07-2002. CA 02405847 2002-10-10 ~ CA0100504 2. The WF service then delivers the requested information from the user's VSDB to the participant site using a VVP order form returned over the SSL.
3, VirtuaISAFE is responsible for authorizing the payment from the user. -'The participant site is then resp4nsible for, adding any gi$ options, and completing the optional fulfillment transaction.
4. If the user is a first-titn.e VSDB user, the VVP service presents an empty form into which the user would enter the card,and address he or she wants to use for the nransaction. 'f'he user would then have to be authenticated prior to the purchase being approved, and the next time the user makes a purchase at. a 'V'irtualSAFE participant site, he or she would not need to retype any credit-card or address information as it will be already stored in VirtualSAFE and will automarically be passed on to the VSDB.
Policy issues related to VVF service and participant sites may include the following:
I $ ~ Cotncni.tments ' and contractual obligations may be made when registering as a VirtualSAFE participant site.
~ Requirements may be established regarding the ~disptay of VirtualSAFE links or images on participant sites. .
The VVP service may also include a fund allocarian feature which may be entitled "VirtualSAFE Trust and Allowance". This feature allows children and parents, or any authori:ced shared person, to ielate to one another at a different level.
Parents who are registered .and authenticated users of VirtualSAFE may allocate a certain amount of pre-authorized spending inaney per month to their children on their creditldebit card.
Similarly, businesses or fiiends . who are registered and authenticated users of 2S VimiaISAFE may allocate a certain amount of pre-authorized spending money from their accounts to authorized persoilnel, friends, etc. These values may be added, modified, and authorized at the beginning of each month. Consider the following example: . .
-92- .
AMENDED SHEET

Pare~slBusineSSesIPriends Pie-authorized PayiuentJTrausfer with Shared-' Access X450.00 , . .
S
Child's.hlame Pre-authatrized Amount put~hasas Balance Paymetat .

R.oberx Smith 150.40 100.00 50.00 Anna Smith 150.00 ~ ~ ' 57.00 93.00 Billy Smith 150.00 148.00 ~ 2.00 Now consider the situation of business-to-business shared accounts in which two businesses operate with one another. According to agreement, this application allows one 'business to access the other business's account for a ~ pre-authorized and IO predetemnined amount. A lender opens an account or allows shared access to a bozrov~rer. Furthermore, this application allows financial transactions equivalent to the commercially known line of credit; mortgage loan, or loan. Here, a borrower, as permitted by a shared access agreement, can debit a particular lender's a~ecount using the strong authentication provided by VirtualSAFE's Authentication Authozity or, if 15 necessary, by VirtualSAFE's predefined Attribute Authentication Authority.
The pre-authorized user is able to both dEbit and credit the account as per agreement and policy. The same approach may be used , for sharEd_access in a document environment, or application environment, in which one entity (i.e. the account holder) may allows another user access for sharing in accordance with user definitions and 20 . privileges.
Referring again to FIG. 24, further features of the VSDB will novv be described.

AMENDED SHEET

Using a PKI-based secure application, an enrolling applicant is prompted to store personal information to the VirtuaISAFE local or remote VirtualSAFE deposit box (V SD$). The depositing of information is a unique process. Tt involves encrypting Urte information with a PICI cryptographic scheme that uses a high-speed hybrid approach and then staring elements of it in a fragmented arrangement. Only the authenticated user c:an'bring these pieces together again to xerzder the information usable.
In this process, the user profile becomes a virtual safety deposit box or part of a "virtual identitya', the contents of which are accessible only to VirtualSAFE for the purpose of authentication, arid only in the presence of the authorized.user. The secuxe data is not . accessible to any entity or . application requesting user authentication or to VirtualSAFE administrators.
1. , VirtualSAFE Deposit Box (VSDB) Functions ~ VSDB is a secured remote storage conaol with access control maintained by the Virtual Smart Card_ IS ':~.. VirtualSAFE Deposit Box (VSDB) Usage Single or multiple users cait operate VSDB.
~ Users of VSDB will have different levels of privileges based on defined policy.
~ Users can communicate and store dada in the following general formats: mufti-lingual, mufti-calendar, mufti-currency, and mufti-. , format (i.e. documents, drawings, formulas, and other file formats)_ 3. VirtualSAFI;.Deposit Box (VSDl~):Types. VSD13 supports the following Deposit Box formats: .
~ Private (i:e. Private anal Family related information and Third Party authentication meclianisins, PThIs, etc.) _94_ AMENDED SHEET

19-07-2002, CA 02405847 2002-10-10 CA0100504 ~ Financial (i.e., Au Private fiinancial related and ausinesslGovernment Financial related data.) ~ Business (i.e. All Business related data - Business Numbers, Documents, Legal and/or HR Documents, Drawings, etc.) Governmene (i.e. All Government related data - Business Numbers, l:7ocuments, Legal andlor QTR Documents, Drawings, etc.) ~, General (May be local or remote for customer based on Policy.) a Transaction (May be local or remote and this type of VSDB
10' supports all data related to all transactions maintained by VirEuaISAFE - All Private information is encrypted and maintained as per Privacy Policy and Government regulations.) POS-VSC Emulation. Referring to FIG. 25, there is shown a block ' diagram illustrating the point-of sale (POS) andwirNat smart card (VSC) emulation process in 15 VirtualSAFE in accordance with an embodiment of the invention. P~~S-VSC
emulation is a low cost replacement for the,. physical smart card application.
POS_ VSC may be easily implemented on an existing financial network. Using the Virtual Smart Card. {VSC),reduces.the high cost of physical smart card implementation and critical maintenance issues. VirtualSAFE's PKI strtteture is used to authenticate users 20 on, any POS premise based on individual PINS (Personal Identification Numbers) in accardapce with selected European standards. The Point of Sale (POS)/Virtual Smart Card emulation process may be performed as follows:
1: Magnetic Card a User uses CreditlDebit card.
1 ..
25 2. Point Of Sale (POS) o POS requests Cxedit113ebit card payment authorization.

z AMENDED SHEET

3. Srriart Card Reader . . Merchant Smart Card identifies raerchant to VirCualSAFE.
~ Received message from FOS sent to VirtualSAFE.
4. Transaction Request ~ a VirtuaISAFE receives transaction request.
~ VirtuatSAFE requests user PIN for authentication purposes.
5. User Authentication. Pin ' ~ , User eaters PIN for authentication purposes:
Smart Card reader sends encrypted data to VirtuaISAFE.
14 6. Authentication VirtualSAFE process authenticates customer. .
. 7. Messaging ~ Payment requested from the bank.
S, i'ayment Frocessirtg ~ , ' a Credit/Debit card payment authorizedlsettled.
9. . ?ransactian Lag ~ Message sent to VirtuaiSAFE.
~ Au transaction steps are recorded.
1 D. Smart Card deader Confirmation -. -95-AMENDED SHEET

a Smart Card reader receives authorization from Credit card processing department.
a Decrypted message is seot to POS.
I 1. Point Of Sale Authorization S ~ POS receives authorized message in standaid format:
o Transaction authorized and printed.
ATM-VSC Einulatifln. Referring to FIG. 26, . there is shown a block diagram illusuating the ATM and virtual smart card (VSC) emulation process in VinualSAFE
in accordance.with an embodiment of the invention- ATM-VSC Emulation-provides a solutions for physical smart card applications irxiplemented on existing networks.
Using a Viz2ual Smart Card (VSC) reduces the high cost of physical smart card itnplementati,an and critical maintenance issues. The user autlientication process is based on VirtualSAFE's PKI structure. VirtoaISAFE applications implemented on supported servers does not requixe sigaificant changes to existing ATM
applications 1.5, and networl',s. A security layer is implemented in existing applications and financial networks in accordance with current standards. The ATMIVirntal Smart Card emulation process may be performed as follows: .
1. Ma~etic Card User uses CreditlDebit magnetic card.
?0 2. Automatic~TellerMachine(A'hM) o, The ATM requests CreditlDebit transaction authorization. .
3. Add-On ATM Application s Add-on ATM application maintains digital certificate with all security functions.
25 ~ Magnetic reader reads card hash information.

AMENDED SHEET

~ Digital certificate encrypts and signs transaction and private information.

4. Transaction Request o , VirtualSAFE received transaction Tequest.

VinualSAFE requests User PIN for authentication purposes.

5. User Authentication PIN , . User enters PIN for authentication purposes.

A.TM seeds encrypted data to VinuaISAFE.

6. Authentication ..

1 U a VirtualSAFE process authenticates customer. v ?. Messaging .

. a Payment requested from the bank.

8. Payment Processing a CreditlDebit card payment authorized/settled.

9. , Transaction Log ~ . .

Message sent to VirtuaISAFE.

All transaction steps are recorded.

10: ATM Confirmation s ATM receives authorization message from Credit Card processing 2Q department.

I 1. ATM Authorization -~S-AMENDED SHEET

~ Transaction authorixed and printed.
POSIATMIWireless. Referring to FIG. 27, there is~ shown a block diagram illustrating the wireless POS and ATM process in Vir;uaISAFE in accordance with an embodiment of the invention. With respect to wireless VirtualSAFE access, the~user may access the ViituaiSAFE application through an analog or a digital wireless network using one of the following devices: cellular phone, P17A, two way radio, satellite, etc. ViriuaISAFI: provides a secure wireless application both locally and via the server. To wirelessly communicate with VirtualSAFE, either a standard wireless network can be used or a local wireless network (i.e. 131ackberry, Blue Tooth, ~ Infrared, ctc.) may be usrd. With respect to local wirclcss VirtualSAFE
access, the user may access the VinualSAFE wireless application either locally or remotely. The Iocal wireless application may. communicate to a remote . device through a converttiottal or wireless network. The local wireless authentication application may communicate to ,a remote VirtualSAFE device through .a conventional or wireless 1 S network.
SAFEcheck. Referring to FIG. 28, there is shown a block diagram illustrating the SAFEcheek process in VirtualSAFB. in accordance with an embodiment of the invention. The Yirtt~alSAFE Check Processing (VCP) enables streamlined and secure check processing and ~ payxueuts 'titrou~,h a remote network connection. The VirCUaISAFE method and system is employed in a traditional check processing protocol in which VirtualSAFE authenticates a check clearing transaction. .
This capability allows for the integration of electronic payments and check processing. The SAFEcheck process may be performed as follows:
1. User Browses The Merchant Site .2. User Selects SA~'Echeck Payment ~ A digitally signed shopping cart contents and payment amounts are sent to VinualSAF)w.
_gg_ AMENDED SHEET

o User is then redirected to the VirtualSAFE secured site for further authentication:
3 , User Authentication a Virn~alSAFE defines authentication level depending on payment amount and SAFEchec~. Policy.
4. Account Selected User.selects appropriate checking account from availability list.
5. Account Digital Sigiature (DS) o User digitally Signs SAhEcheck. ' .
~ SAFEcheck signed with web certificate.
~ SAFBcheck signed with VimtaISAFE certificate.
6. Clearance Request ~ VirtuaISAFlr issues clearance request.
7. Financial Institution ~ Receives SAPEcheck for check presentment.
8. Check Printer ~ SAFEclteck .has been printed an premises .including customer signature.
~ Printer uses regulated check paper with appropriate coding.
9. Electronic Check Presentment (ECP) ' .
- l OQ -AMENDED SHEET

19-07-2002 - ' CA 02405847 2002-10-10 I CA0100504 VirtuaISAFE application interfa~ces~ with Electronic Check Presentment module.
~ SAl~ Echeck cleared and processed.
lfl. Confirruation ~ -ViriuaISAFE receives confirmation.
Virtu,aISAFl: sends conf rmation to merchant and user to complete transaction. r 11. Merchant Prints SAFEcheck ~ Merchant prints out user signed copy of cleaxed check.
~ User optionally signs SAFEcheck at merchant premisss.-Physical~Access Control. Referring to FIG. 29, there is shomi a block diagraiu illustrating physical access control in VirtuaISAFE in accordance with an embodiment of the invention.. Physical Access Control or SAFEpac refers to the storage in VirtualSAFIof secure entry ~ information. With respect to eaiployeehrisitor door ' access, at least three scenarios may be supported as follows:
1. Local Physical Access ~ Local office user access requested.
r Request is processed locally.
2. Remote Physical Access 2(? a Remote office user access requested:
Request is processed remotely.
3. VirtualSAFE Controlled High Security Access AMENDED SHEET
z 19-07-2002, CA 02405847 2002-10-10 CA0100504 . . a Remote office user access xequested.
~ Request a processed remotely.
Multiple entry levels may also 15e supported as follows:
1. Entry Level 1 ~ ~ Building user reguests access to local branch, ~ Building, control unit validates Digital Certificate access Level and ' authorizes access.
. . . 2. Entry Level 2 ~ Building user reQuests access to building Secured room.
~ a building Comrol Unit validates Digital Certificate access Level and requests User PIN.
3. Entry Level ~
~ Building user requests access to building High-Secured room.
. ~ a Building Control 'Unit forwards validation of the Digital Certificate from Security Company Controller.
a User must provide PITT.
4. Entry Level 4 ~ Building user requests access to building Restricted Area.
' a~ Building Control Unit forwards validation of the Digital Certificate ..from'ViriualSAFE through Security Company. .
~ User must provide VirtualSAFE P1N.

AMENDED SHEET

rfnique Features and Advantages. To reiterate and expand, VirtualSAFE includes the following unique features aitd advantages:
a VirtualSAFE includes a reraatc mufti-tiered Authentication Authority ("AA") infrastructure for performing secuxity functions:
a VirtualSAFE provides for payment and initiation using a ~cornputer network, Specifically, VirtualSAFE provides a payment and initiation system for a virtual smart card using an open network tike the Tnteinet.
~ VittualSAFE includes highly secure dedicated servers. Built upon a "need ~o know virtual identity' principle of access, VirtualSAF~? securely procCases tuna stores information such that only an authorized user who is vigorously and firmly authenticated can access it. While the secure session andlor the SSL protocol authenticates and secures, communications with the server, .and Public Key Infrastructure (PKl) combined with third party trusted Certificate Authorities authenticates the device or. computer; VinuaISAFE functions to authenticate the server, computer, and the user.
~ t3sing a PKI based secure application, an enrolling applicant is prompted to score personal information to a VirtualSAFE remote repository. The depositing of information involves encrypting the .information with a PKI cryptographic scheme that uses a high=speed hybrid approach, and then storing elements o~ it in a ~ fragmented anrangenient. , Unly the authenticated user can bridg these pieces together again to render the information usable. In this process, the user profile becomes a virtue! safety deposit box or part of a "virtual identity", the contents of which are accessible only to VirtualSAlE for the purpose of authentication, and only in the online presence of the authorised user. The secure data .is not accessible to any entity or application requesting user authentication, or to 'VirtualSAp'E administrators.
~ User identity authentication is initiated for each individual transaction by triggering a mufti-riered algorithm that eraaplays "virtual smart card"
technology to interface with standard PKI. Authentication is only possible when the user's -i03-AMENDED SHEET

19-07-2002 a CA0100504 ~ CA 02405847 2002-10-10 personalized ~"virtual smart card" allows 'VirtualSAFE to access the respective "virtual identity". . .
ViriualSAFE raay be applied to credit or debit card, safe check, wire, or other forms of electronic payment processing.
0 ' VirtualSAFE functions as both a means of network access control and secure data storage.
m Over a remote network, ViztualSAFE is configured as an Attribute Authentication Authority ("AAA") and provides an access control portal to sensitive applications ,and data, management facilities hence enabling a secure end-to-end extranet for 1 U maintaining authorization, authentication, and accountability of all external users or applications, ' Strong user andloi application authentication via virtual smart card directs, controls, and audits access to sensitive resources to any Ievel of granularity in accordance with the ISO 8583 standard.
VinuaISAFE provides for the complete payment and fulfillment process as conducted over a communicatton network, and more specifically, VirtualSAFE
provides. a secuxe virtual entity that includes : purchase transaction, ~
payrnern transaction, and shipping and delivery components..
VirtualSAFlr executes a complete electronic financial transaction for goods or services, which previously was transacted with credit card, cash or other payment of goods, and subsequently fulfilled separately..
~ , By . enabling, an iulprecedented level of security in online authentication, VimtaISAFE reduces the current constraints an businesses, governments, and individuals that keep them from fully leveraging the flexibility and advantages c~f communicating and transacting over the Internet, intranets, ~extranets and ?5 enterprsse netwoxks. This is achieved by VirtuaISAFE's mufti-tiered Attribute Authentication Authority (AAA) infrastructure which includes secure means for processing electronic data and transactions over conventional and wireless AMENDED SHEET

net<vorks, authenticating users at the application level, and for network access, transactions, and communicatibns:
~ Viz'tuaISAFE includes a secure, dedicated server that exceeds standard sessions or Internet security protocols such as SSL. While SSL authenticates a network server ~ and Public Key Tnfrastrueture ~PK~ combined with third party trusted Certificate Authorities authenticate the device or PC, VirtualSAFE authenticates the user.
VirrualSAFE provides for the payment and fulfillment processes involved in completing a financial exchange of goods or services for monetary payment.
~ VirtuaISAFE ineludes secure encrypted digital communications, existing payment methods (i.e. cash, check, credit and debit card payment systems, wire payment and electronic funds transfer systems, etc.), and fulfillment and clearinghouse processes for ~ delivery of goods ' and services. VirtualSAPE cases electronic representations of money and shnppi~ig entities which are designed to be sectu~ely housed in a digital environment that is independent from the remote shopper's Z 5 computer terminal.
VirtualSAFE enables an enterprise to resolve many of the security, privacy, convenience and cost impediments that exist with present online commerce systems.
VirtuaISAFE makes it easier and~less risky for businesses of all sizes to engage in . e-commerce.
~ VirtualSAhE makes it easier for potential online xuerchants of goods and services to build a website and enteF the world of e-commerce.
VirtualSA,FE allows merchants~to readily obtain blanket fraud insurance. ' a . VirtualSAFE registers consumers' persona! data (i.e. credit card information) once 25 ~ and then isSUes a digital ~ to that~individuai. Iiencefoxth, the consumer does not have to enter their data online again, an obvious attracrion to consumers. The data is held in a database file on a highly secure and insured server site.
-105 '-AMENDED SHEET

19-07-2002. CA 02405847 2002-10-10 CA0100504 ~ With VimialSAFE, all parts of a transaction are ranted through a '°safe"
component, with private data being protected. ~ A purchase can then be made with all interested parties (i.e. merchaat, credit card issuer, bank, couriers) accessing only infarmatiort that is absolutely pertinent to their roles_ At the same time, S VirtualSAFE ensures that it is exceedingly unlikely that anyone other than the card holder could execute the transaction. An advantage of VirtualSAFE is that online fraud may be reduced.
~ VirtualSAFE includes a remote secure repository for fulfillment data.
~ VirtualSAFE electronically emulates a wallet or a purse cuswmarily used for organizing money, credit cards, and other forms of payment. Access , to the instruments in the wallet or purse is restricted by an encryption and authentication processes to avoid - unauthorized .payments. A successful cryptographic authentication is required in Order to obtain access to the wallet or purse.
The authentication protocol obtains the information necessary for creating a netvsrork session , granting authority to utilize an instrument, a payment bolder, and a complete electronic wallet. Electronic approval results in the generation of an electronic transaction to complete the order.
~ Upon selection of a particular payment transaction by a user, a particular transaction notification will be generated based on the order. The transaction notification is processed by means of a seeitre connection to a transaction server.
vThe transaction server includes ~ elements fax order fulfillment, including connectivity to:, credit card issuer, acquiring bank or foods-holding institution, product or service titerchaztt, delivery provider, snd the user or customer account.
. ~ With VirtuaISAFE an electronic .payment transaction is generated for ~affectirig a , transfer of funds from an account of the payer in the funds-holding institution to the payee. The electronic instrument includes a cryptographic digital signature of the payer, digital representations of payment , instructions, the cryptographic authenricated identity ofthe payer, the identity of the payee, and the identity of the funds-holding institution.

AMENDED SHEET

19-07-2002, ~ CA 02405847 2002-10-10 CA0100504 ~ VittualSAFE .has a secure infrastructure which includes the following components: PKI; a Redirection Link; a Secure Remote Pointer~Piug-In Application; a Vittual identity; a Virtual Smart.Card; a VirtualSAFE Deposit Box ('~SAB); an Attribute Authority; a Crypto-Engine; a Payment Processing Engine;
a Risk Management Engine; a Transaction Fulfilment Mechanism; ' an Insurance Module; and, a Transaction Secure Repository. w a VirtualSAFE augments the existing capabilities to process: payments by simulating a physical smart card, reader, and umi9ue identity in a remote online environment. This is accomplished without compromising existing capabilities of 1i1 remote aonneetiop, browsing, and.interactivity already inherent in the network.
These exisitn~~ capabilities are enhanced by VixtualSAFB's ability to strongly authenticate the identity of online users far the purposes of processing payments.
~ By incorporating cryptographic and networking elements, VirtuaISAFE operates as an authentication layer or authentication authority between the buyer, the terminal, the merchant, and payment server. Through mufti-tiered authentication, the remote client . is queried and authenticated to produce effective smart card emulation as if the physical card was present.
~ VirtualSA.FE includes au online purchase and initiation server (VimtalSAFE
Authentication Authority . or "VSA.A") that implements virtual smatt cards.
2p VirtuaiSAFE cozupiements existing lntemet payment and .initiation systems by providing software . emulation of smart cards and smart card readers. Other components of the.existing Internet payment and initiation systems (e.g.
merchant server and payment servex), and the techniques for processing payment and initiation transactions, may remain the carne. Use of the VSAA .server is transparent to merchants on the Internet. In one embodiment, a smart card and its associated card reader are emulated on a remotely located VSAA. server cpn~puter, thus reducing the need for physical smart cards and smart card readers. The existing client terminal acts as a pass-thxough device that is transparent to a user, a merchant server, or a bank server. This improvement to Internet payment and iziitiation systems provides several advantages. p'or example, the aciopti4n o~
-107 -.
AMENDED SHEET

electronic . market systems may be accelerated by avoiding the cost snd distribution prableans associated with physical cards and card readers.
VirtualSAFE includes a means to address the low value (e.g. less then US$ld) electronic commcxee ~ market ~ in a 'rapid manner using an infrastructure that is S easily scaleable.
By remaining integrated with the hardware-based approach to electronic commerce, VirtualSAFE facilitates the accelerated development of Tnternet payment and initiation systems. With VirtuaISAFE, a consumer base may be created which may subseguentlybe transferred to the hardware~approaeh when the I O; required htirdware~is more widely available.
o VirtualSAFE is secure in that the cryptographic functions normally performed' within a smart card are performed securely within the remote VSAA server which may be under the control of an issuing bank or a trusted third party.
~ VirtualSAFE allows value to be credited to a consumer's account. This may be 15 done quickly and easily by VirtualSAFE's . VSAA sexver (i.e. the virtual smart card that is being emulated). A special initiation server . is not necessarily required, but may be used.
With VirtualSAFE, by permitting the use of a virtual card to make purchases over the Internet for small dollar amounts, a merchant ztiay very well be able to begin 20 , charging for goods and services, that he provided for free in the past.
VirtualSAFE
is suitable for purchases of under US$I4 while purchases of any amour<t may be made. VirtualSAFE allovsrs rnerchaats to recover costs of services not previously charged for and allows merchants to access to an existing and rapidly growing consumer base.
25 ~ VirtusISAFE integrates into existing clearing and settlement systems such t3~ax merchants need not implement nor become familiar with new procedures for the recoriciliati4n Of transactions.

AMENDED SHEET

19-07-2002 -- CA 02405847 2002-10-10 ~ . ~ CA0100504 p With ViriuaISAFE, a merchant need only make a minimal investment in time and money to take advantage of and to accept payments aver the Internet. With VirntaISAFE, a merchant need not engage in the development of complex software or accounting procedures. . Smaller merchants will especially benefit from VirtualSAFE. By establishing a business relationship with an acquirer and inco~parating standard merchant software; a merchant is ready to begin selling goods and services from his web site. Since a virtual smart card with a stored-value application is used; the payment server arid the VSAA server perform the details of and provide security for the ~transactiou. Hence, merchants are relieved from having to control and.keep track of transactions. From a merchant's point of vie~r, the merchant knows that a consumer desires to punch se an item. and that a cost has been nransmitted to the consumer, thus, when .the merchant receives a confirmation message, the merchant rnay release the item to the consumer_ Tile merchant need not be concerned about security nor be responsible far ~ auther~ticatipg a card nor for determining a balance on the card.
~ VirtualSAFE may facilitate freguent flyer miles or award points. A consumer rnay wish to~access any of a variety of Web servers in order to redeem frequent flyer miles, award points, . eic.,~ that he or she has accumulated as pan of a loyalty program. The consumer may have aceutnulated points through any of a vai'iety.of 20, programs with airlines, restaurants, rental car companies, hazels, banks, credit or debit card issuers, telephone oz other communication company, etc. Often the consumer wishes to redeem these points to receive free airline tickets, meals, car rental, overnight stays, prizes, awards, discounts, or Other benefits. It is important to the airline (or other company) to be able to authenticate that the person trying to . redeem points is the actual ~ person who owns the points. By accessing a Web .
server associated with the parn'cular pragtam, VirtualSAFE allows the consumer to ase a virtual card in the VSAA server to authenticate that he at she is the true owner of the points and to receive benefits from the program.
VirtualSAFE allows consumers to conveniently initiate value on virtual cards from any suitable device via an open network such as the Internet. A consumer may use any suitable coz~zputer at the home, office, or elsewhere in order to AMENDED SHEET

Connect to his bank or other financial institution. Using, appropriate massage integrity, value is transferred from the bank to the consumer's virtual card.
At the same time, the corresponding value is transferred from the bank to the virtual card issuer through existing networks for later settlement with a merchant, from whom S the . consumer purchases goods or services. This embodiment makes use of an existing clearing and settlement system for eventual settlement of the transaction between the ruerchant and the card 'issuer. ,The invention allows consumers to conveniently ,initiate value on virtual cards while maintaining a high level of security. From the consumer's perspective, this initiation feature operates in a fashion similar to the initiation of a physical card at an A'f Ivi machine, except that the consumer need not insert cash or an additional debit or credit card, nor is the consumer required to ttavei to a bank. The initiation functionality is distributed across the lnteitlet between the. VSAA server, a bank server holding the consumer's account, and an initiation server with a security trtodule. All of these 1 S entities may be physically remote frorri one another with router functionality being provided by the Tnternet.
~ , VirtuaISAFE may use existing _ clearing . and ~ settlement systems to reconcile transactions and to pay the appropriate parties once the value has been spent.
~ VirtualSAFI: includes the integration of at least four separate networks, namely, . "VIRCOhI", "VrRSBUS", "V>RM~US", and "Vll~.BIJS". These networks are defined as follows: VIRCaN is a virtual contractors network; VIRSBUS is a virtual small business network; VIRMBLlS. is a viriuai medium-sited business network; raid, VIRLBUS is a virtual large business network: As members of one these networks, contractors will have access and will be able to run all of their business affairs via VirtuaISAFE. For example, contractprs may login to VirtualSAFE and download all of their companys' documents (e.g. purchase orders, invoices, change orders, material order forms,, outstanding bills, etc.) and have all of their e-commerce transactions handled right at their customers' sites.
v . ~ For materials that they require, eonails will be sent to their suppliers. Far invoices that require payment, the opportunity for their immediate payment exists through VirtualSAFIr.

AMENDED SHEET

Claims (6)

THE EMBODIMENT OF THE INVENTION IN WHICH AN EXCLUSIVE PROPERTY
OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:

1. A, method of performing a secure electronic commerce transaction over a network using a smart card, said network having a client terminal, a merchant server, a payment server, and an authentication server, said smart caid being a physical smart card or a virtual smart card, said smart card being associated with a user at said client terminal, said smart card having associated smart card information, said smart card information including an account balance, said smart card information being stored at said client terminal and at said authentication server, said method comprising the steps of:
sending a transaction request message from said client terminal to said merchant server identifying a product for said transaction, said product having associated product information, said product information being displayed on a first web page supported by said merchant server, said user being able to view said web page at said client terminal using a browser;
sending transaction information from said merchant server to said client terminal in response to said transaction request message, said transaction information being contained in a second web page generated by said merchant server and, displayable to said user through said browser, said transaction information including a price for said product, an IP address of said payment server, a transaction identifier, and a merchant identifier, said transaction identifier for tracking said transaction by said merchant server and by said payment server, said merchant identifier for tracking said transaction by said client terminal and said payment server;
receiving a user identifier and a PIN from said user at said client terminal for authorizing said transaction;
sending said user identifier, said PIN, and said transaction information from said client terminal to said authentication server;

comparing said price of said product to said account balance for said smart card at said authentication server to determine if said transaction can proceed, said account balance being stored at said authentication server and being accessed using said user identifier and said PIN, said transaction being terminated and a first termination message being sent from said authentication server to said client terminal for display to said user if said price exceeds said account balance by a predetermined amount;
sending a draw request message from said authentication server to said payment server using said IP address of said payment server, said draw request message containing said transaction information;
sending said draw request message from said payment server to said client terminal;
sending a debit request message from said client terminal to said payment server in response to said draw request message, said debit request,message including a first digital signature, said first digital signature for verifying that said debit request message originated from said client terminal, said first digital signature being generated at said client terminal using said smart card information stored at said client terminal;
sending said debit request message from said payment server to said authentication serves;
comparing at said authentication server said first digital signature contained in said debit request message to a first check digital signature generated at said authentication server using said smart card information stored at said authentication server to determine if said transaction can proceed, said transaction being terminated and a second termination message being sent from said authentication server to said client terminal for display to said user if said first digital signature does not match said first check digital signature;
updating said smart card information by debiting said account balance by paid price to produce an updated account balance and storing said updated account balance at said authentication server;

sending a debit response message from said authentication server to said payment server, said debit response message including a second digital signature, said second digital signature for verifying that said debit response message originated from said authentication server and far verifying that said account balance has been debited, said second digital signature being generated at said authentication server using said smart card information stored at said authentication server;
sending said debit response message from said payment server to said client terminal;
comparing at said client terminal said second digital signature contained in said debit response message to a second check digital signature generated at said client terminal using said smart card information stored at said client terminal, said smart card information stored at said client terminal including an expected updated account balance, to determine if said transaction can proceed, said transaction being terminated and a third termination message being displayed to said user if said second digital signature does not match said second check digital signature;
updating said smart card information by debiting said account balance by paid price to produce an updated account balance and staring said updated account balance at said client terminal;
sending a verification response message from said client terminal to said payment server, said verification response message including an indication that said second digital signature matches said second check digital signature and that said transaction can proceed;
logging said indication and said transaction information at said payment server;
sending a debit result message from said payment server to said authentication server, said debit result message for confirming that said transaction has been logged and that said transaction can proceed, said debit result message including .said indication and said transaction information;
logging said debit result message at said authentication server;

sending said debit result message from said authentication server to said client terminal to confirm that said transaction has been logged and that said transaction can proceed;
sending said debit result message from said client terminal to said merchant server to confirm that said transaction has been logged and that said product.can be released to said user; and, sending a purchase receipt message from said merchant server to said client terminal, said purchase receipt message indicating that said product has been released to said user, thereby completing said secure electronic commerce transaction.

2. The method of claim 1 wherein said network is the Internet.

3. The method of claim 1 wherein said debit result message is encrypted.

4. A transaction server for performing a transaction over a network using a virtual smart card said server comprising:
a) a virtual smart card database having a plurality of records each record including a virtual card identification and a value corresponding to a single virtual smart card;
b) a security module;
c) an emulator for emulating a smart card, said emulator for receiving smart card commands and processing said commands in conjunction with said virtual smart card database and said security module; and d) a virtual card reader module for receiving said smart card commands and relaying said commands to said smart card emulator whereby transactions are performed over said network using one or more said records and said virtual smart card database.

5. A method for performing a transaction over a network using a virtual smart card and a server, said method comprising the steps of:

a) creating a plurality of records on a virtual smart card database, each record including a virtual card identifier and a value corresponding co a single virtual smart card;
b) receiving smart card commands via a smart card emulator and processing said commands in conjunction with said virtual smart card database and a security module; and c) receiving said smart card commands via a virtual card reader module and relaying said commands to said smart card emulator whereby transactions are performed over said network using said server and one or more of said records in said virtual.
smart card database.

6. A server as defined in claim 4, said security module including a plurality of encryption algorithms.