Note: Descriptions are shown in the official language in which they were submitted.
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 .
-2-
AMENDED SHEET
CA 02405847 2002-10-10 CA0100504
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
-3-
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
-4-
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,
1
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
-6-
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
CA 02405847 2002-10-10
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.
2Q
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;
-10-
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; .
-11-
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;
-12-
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
-14-
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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,
-15-
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-
- 16-
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
-17-
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
-20-
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
CA 02405847 2002-10-10
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
CEV 109
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
CA 02405847 2002-10-10
19-07-2002 - CA0100504
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
- 23 -
AMENDED SHEET
CA 02405847 2002-10-10
. 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
-24-
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,
S/M1ME
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:
-25-
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.
-28-
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
-29-
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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,
-30-
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.
-31-
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)
-33-
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.
-34-
AMENDED SHEET
r
CA 02405847 2002-10-10
19-07-2002 CA0100504
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:
-35-
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-
-36-
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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.
37
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
-3S-
AMENDED SHEET
CA 02405847 2002-10-10
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.
-42-
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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.
- 46 -
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
-51-
AMENDED SHEET
19-07-2002 P. o53/t t a CA0100504
CA 02405847 2002-10-10
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
-53-
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_
-S4-
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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 ' .
-55-
. 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
-56-
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
-59-
- - 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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
-63-
AMENDED SHEET
CA 02405847 2002-10-10 CA010Q504
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
- 64 -
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: _ .
- 55 -
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
-67-
AMENDED SHEET
..
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
- 74 -
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
- 75 -
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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_
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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.
14
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_
-81-
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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.
83 -
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
-84-
AMENDED SHEET
19-07-2002 -- CA 02405847 2002-10-10 CA0100504
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
19-07-2002 CA 02405847 2002-10-10 GA0100504
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.
-91-
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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.
93 -
AMENDED SHEET
19-07-2002 - CA 02405847 2002-10-10 CA0100504
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.
-95-
z AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
19-07-2002 -- CA 02405847 2002-10-10 CA0100504
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.
-97-
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
~ 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
19-07-2002 CA 02405847 2002-10-10 CA0100504
~ 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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
-101-
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.
-102
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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
-104-
AMENDED SHEET
19-07-2002 CA0100504
CA 02405847 2002-10-10
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.
- 106
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
19-07-2002 CA 02405847 2002-10-10 CA0100504
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.
- 108
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
-109-
AMENDED SHEET
19-07-2002 CA 02405847 2002-10-10 CA0100504
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.
- 1I0-
AMENDED SHEET
