Note: Descriptions are shown in the official language in which they were submitted.
CA 02309013 2000-OS-23
Tlt~e
METHOD FOR SECURE PAYMENT WITH STANDARD CREDIT
CARDS IN ELECTRONIC COMMERCE SYSTEM
~ Field of the invention
This invention relates to electronic commerce and, more particularly, to
a system and method for credit card related transactions an open
electronic public system such as the Internet.
~ Background of the invention
With the rapid growth of Internet sites along with the advent of flat rate
pricing, millions of Internet users now rely on multiple sites for e-mail,
chat, news, and many other products and services involving transaction.
Presently there are over 1 SO million Internet users, each of whom must
use a browser to "surf' the Internet. By 2001, it is estimated that there
will be over 700 million worldwide Internet users.
And, in the next five years, conservative forecasted volume of
transaction on the web will exceed 57 billion of dollars.
This invention significantly improves the level of confidence and the
actual security of payment transactions on the web.
While most major banks are currently using a form or another of high
security encryption for at home banking and investment, which appears
to satisfy sophisticated and learned users, none of those systems have
yet provide the level of comfort and comprehension needed for the
average user.
Businesses of all sizes are struggling to take advantage of the relatively
new electronic marketplace. But the development of systems for
executing secure credit card transactions across electronic networks
hasn't follow course. Most existing or proposed schemes are essentially
existing credit card systems adapted for operation over the Internet.
I
CA 02309013 2000-OS-23
The biggest challenge appears to securely obtain or transmit a
customer's credit card information in a way that simulate what happens
in bricks-and-mortar stores. Traditionally, a customer would give his
credit card information on a paper imprint or via a magnetic reader, a
payment amount would be associated with it, the information would or
would not be scrambled to verify card validity and obtain an
authorization number from the issuer. Since credit electronic payment
systems are built around the conventional, bundled service credit card
transaction processing systems, the same basic architecture has been
applied to web sites ~in order to avoid replacing existing equipment and
protocols at the merchant's end. The merchant still acts as the main
transaction hub. It is the merchant's responsibility to verify the
cardholder's legitimacy and to obtain clearance from the issuer.
Merchants have access to the standard customer information. Even if
some of the systems provide authentication using digital signatures or
the added security of smart cards through peripheral computer
apparatuses, hackers or fraudulent employees may still have access to
stored data. It is worth to note that one of the major sources of fraud is
not illegal transaction as much as pirating legitimate cardholders' data to
manufacture counterfeited plastic cards.
Other desirable aspects of a standard credit card secure system is that it
would allows all cardholders to make transaction on the Internet with
existing and familiar credit account, while giving the credit card
company a significantly increased level of security against fraud, that in
turn may help merchants to deal with charge-back problems.
Brief description of the drawings
In the appended drawings:
Figure 1 is a block diagram illustrating an actual transaction according
to the prior art;
Figure 2 is a block diagram illustrating a first embodiment of the data
flow of the method of the present invention;
Figure 3 is a block diagram illustrating a second embodiment of the data
flow of the method of the present invention;
CA 02309013 2000-OS-23
Figure 4 is a diagram illustrating the external specifications of the
presentinvention;
Figure 5 is a block diagram illustrating the architecture of a system
embodying the method of the present invention; and
Figure 6 is a diagram illustrating the internal specifications of the
presentinvention.
~ Summary of the invention
This invention relates to an electronic commerce and transaction system,
its components and methods for their use.
This invention accessibility and simplicity allows everyone to
understand why they can now safely use their existing credit or payment
card account for any type of transaction on the Internet.
In this invention's system, vital information that appears on credit cards
and are stored in financial institutions' current and well-protected
internal system will remain securely there. They will never be
transferred to a third party on the Internet (or via any other means).
The sensitive information that will eventually be transmitted on the
Internet to merchants, service providers or anyone accepting credit card
payment, is an EphemeralTM Credit Card Numbers (ECCN) that is
virtually useless to any other party but the legitimate users.
In one aspect, the invention is a method of credit card payment in an
electronic commerce environment wherein customers have existing
accounts with a Bank and where each customer shares a respective
secret with that same Bank. This secret is set up prior to any actual
transaction and, in preferred embodiments, is a dynamic secret. This
secret is used to uniquely identify a customer in the encrypted
communication established to obtain an ECCN.
In some embodiments, the shared secret is a private key (PHI) stored in
the user's computer andlor a computer agent's software access password
known only by the user.
3
CA 02309013 2000-OS-23
According to the method of this invention, a given Bank issues a
computer agent software to all customers. The software is capable of
establishing an encrypted secure session that provides a unique
identification of the customer. In preferred embodiments, the customer
must use a private password to get access to the computer agent
software application.
The customer first visits merchant website and shops as usual.
Once an intent of purchase is expressed, customer's computer agent
automatically obtains from the Bank's system server an ECCN with
which a credit or payment card transaction may be completed as usual.
In some embodiment, the user enters a distinct private password to
confirm his purchase intent.
In preferred embodiments, segments of data obtained by cardholder at
merchant site are linked to the ECCN to make it purchase, merchant
and/or user specific.
The merchant obtains the ECCN and order information from the
customer's computer, and processes ECCN the way standard credit card
numbers are currently processed.
The ECCN is checked by the current credit card checking system/agent
for credit limit and validity after which it issues the usual authorization
number to the merchant.
The Bank's system server will eventually correlate the amount charged
to the ECCN with the actual customer account for usual billing.
'The merchant provides the goods to the customer in response to
receiving the authorization number from the credit card checking
system/agent.
In preferred embodiment, the method also comprises a limited time
period of validity for any given transaction, which may also be
purchase, merchant and/or user specific.
Once the transaction is completed, the ECCN becomes automatically
void and useless, like non-valid or stolen card numbers. In some
CA 02309013 2000-OS-23
embodiments, the ECCN may remain attached to a specific transaction
for a certain period of time for refund purposes only. Yet in other
embodiments, refunds are processed with complementary ECCN that
replace the one used in the initial transaction.
While embodiments of the present invention have been described with
particular setup and initialization procedures, other setup and/or
initialization procedures can be used.
Further, while some of the system's element may have been said to be
performed in a particular order, one skilled in the art would realize that
other orders are possible and are considered to be within the scope of the
invention.
Thus, a secure electronic credit card payment system preventing access
to vital information is provided.
CA 02309013 2000-OS-23-
Introduction
The purpose of this document is to present the overall architecture of Twin
for secure transactions in e-business, B2B, B2C, and also C2C.
TwinGate is an Internet Portal for secure transactions implemented o~i~ a fry
end server
for Customers and Merchants.
TwinGate is also an information routing device. This aspect
wil~~'~c~escrWd.~~n a sub-
- ,~ - _:
sequent document.
TwinGate implements Profiles for Users (Merchant, Custor~ei ~'
~..__.
a Profile is a list of Services a User can access. ~-_
The features of the TwinGate system include (amoners):
No use of a holder's Credit Card number==~___
Secured Transactions with standard Dh~,S encryp>~~on
-_ .n_
Scalability
Document is orgA~'~ze~ as ~,~ws
v Description of the acG~~l C2B system oftransactions using Credit Cards
~ Description of the form~,hsr~i used
~ Architecture of the 'I~v~yGate EGN sytem (centralized)
_ : ...
- _,~ -
6
CA 02309013 2000-OS-23
Payment ~ C~dNo
authorisation
~rC_ardNo '
Merchant _ Invoice ;~ _ ~ Customer
- ~'_._~der_ ;- _
F
CA 02309013 2000-OS-23 ~ -
Formal Description
To achieve the validation of the systems that are proposed, the agents are vie
w ,~ ~~ com-
municating processes (the data at this point has no importance because it is x
~rvate
information)
In the sequel, the formalism chosen for describing concurrent
commucatigi,~ce~s~s is
the Arnold-Nivat model(2J, implemented in the tool MEC.(3~ T,_ mam f~urr~' of
Model
is its simplicity: it is general enough to describe many formalisms. and
y~~.:,:poerful to
concretely verify properties. MEC has been successfully used for ink. yn
t)~~:~ification
and design of a simple call-processing system (4J, as well a~_,forT~leri~'
_methods for
the design of a switching program ~5). The tool MEC allows s_er to ge ~-- y
ormation on
the behavior of a transition system. In particular, it can corri'pu ° '-
- s of~s~ates (or sets of
transitions) having a property expressed in some langua~s~ the :scan be used
as a
_..
._
model checker. -~ ~~
The communicating processes are Cutomer, Merchant, I, TwmT . They are
described
as transitions systems having given states and perforn-~ons.
.:.__ r_~_ --
Customer
The Customer is an agent that has twca..s~~~es: Active, Sleeping. It can
perform actions like
the following
1. SendOrder
2. GetInvoice
3. SendCCN
Merchant
The Customer is an agent that has two states: Active, Sleeping. It can perform
actions like
the following
1. GetOrder "-'~ .
~'_~-...
e~
2. SendInvotc
".. -:::~~,
-... ° _.;_=-~:_
3. CCNRe~est _ __
5. GetAuthori~ationNr
8
- CA 02309013 2000-OS-23
1. GetECCNRequest
2. SendAuthorizationNr
3. SendRefusedTrxn
Synchronization
CA 02309013 2000-OS-23
. . . . .~:;-.:.;,~~::: .:: -v:.:,:..-.-
Payment
P°%
_ .... _ . _.....:_~~ Payment req.
-~ ECCN_ ;
~ .,
_Invo~ce ; ~ ~stomer
___
'- ______.
tation, the ECCN is created by the TwinGate Server. It should be
Bank} may be willing to manage these actions, leading to a different
(U
CA 02309013 2000-OS-23
CCN Request
L.ogin + Amount
_~r__'
Autfiori~i~f
~- .: _=:
ECCN ~"
with
ECCN
Payment Request
Authorization
#
End Trxn
:w
Refused Trxn
Remarks
1. The specificatio ven ab'"a~~es not take into account the TimeOuts,
inherited from
the Bank's spe~.,_ion, ani'~9 that can occur in the processes. Yhese timeouts
are
inherited from the ~t~~Bauk).
___:~_ ~; __...-
2. It is also sume~,t when a Customer logs in he can access an
administrationmodule
eallowing . me admii~~strative tasks such as password changes etc..
.4_'~~ _ . '".
.:.~.~:~z_~:~- - y
_-~~ In this imp . .lion, the ECCN is created by the TwinGate Server. It
should be
'noted that ~ CCI(or Bank) may be willing to manage these actions. In that
case the
External Specification is modified accordingly: ECCN is provided by the bank
with
-........ the Authori,tion number.
Image
CA 02309013 2000-OS-23
j...'
.y _.. _ _: : .- ~ ..::'- : J/
't
TyvinGate Server Internal Specification
..
New ECCN
~09~ + Amount +ECCN Storage quest
o9rn + Amount +E~ - _ _ _ _ _
~':PI Z2t)On ~
Authorization # Storage Request
Q _________ __
Cel Authorization #
Forward Refused
rretused Trxn
Refused Ttxn
_:.;:',:., _ '_.. ::__. . p .
~~~T'~~~uTe 4. ~_wmGate.. .Internal S ecification.
Remarks. .:-.<_-._:-::,.:
>.;''::.:~:._j':,--_:;:. >_-:-=...:
1~. The Tim~Outs that"=ccui in the system and generated 17y the accessed
CCI(Banl;) will
~cxllow the~~rocessing of etceptions_
v'~a In this impI~i~tt~ation; the ECCN is created by the ECCN Generator. In.
the case
where a CC~(or Bank) manages these actions; the htterrnal Syecification is
modified
accordingly: I;CC~ is provided by the bank with the Authorization number. and
the
. ECCN_G~t%I module is rerno~red with the In and Out transitions.
t3
Image