CA2260002C

CA2260002C - System and method for multi-currency transactions

Info

Publication number: CA2260002C
Application number: CA002260002A
Authority: CA
Inventors: Brian Paul Boesch; Stephen David Crocker; Donald Eggleston Eastlake Iii; Alden Sherburne Hart Jr.; Andrew Jackson; Robert A. Lindenberg; Denise Marie Paredes
Original assignee: Verisign Inc
Current assignee: PayPal International Ltd; PayPal Inc
Priority date: 1996-06-14
Filing date: 1997-06-06
Publication date: 2002-12-31
Anticipated expiration: 2017-06-06
Also published as: US5897621A; AU3306597A; EP0910840A2; WO1997048078A3; USRE41619E1; US6205433B1; CA2260002A1; AU713339B2; USRE44502E1; WO1997048078A2

Abstract

A system for determining approval of a multi-currency transaction between a merchant and a customer using currency exchange. The customer and merchant obligations relating to such a transaction can be fixed at the time of the transaction. Risks to these parties heretofore associated with currency exchange is minimized. The parties to a multi-currency transaction authorize an approving entity to settle the transaction. Authorization is granted by virtue of the customer and merchant setting up accounts knowing that transactions will be submitted and processed by the entity holding the accounts. The parties transmit data representing the transaction to the approving entity. This data includes an amount in a first currency that a customer is willing to pay for a product and a price in a different second currency which a merchant is willing to accept for the product. Using predetermined criteria, the approving entity approves the transaction. Once the transaction is approved, the approving entity may settle the transaction at its discretion thereby bearing the risk associated with currency exchange . The parties, however, incur no risk. The customer will pay the amount in the first currency and the merchant will receive the price in the second currenc y. These are values known and agreed to by the parties at the time of the transaction.

Description

~AJ697/09961 IPEAlllS 0 2 JAN ~998 SYSTEM AND METEIOD FOR MULTI-CURRENCY TRANSACTIONS

RA(~K(~.R()lJNn OF T~ NT~ON
l . FieJd of Inv~ntion 2 The present invention generally relates to a system and method for approving a 3 transaction over a communications network between a merchant and a customer. More 4 specifically, the present invention is directed to a system and method for approving a transaction between a merchant and a customer, wherein the transaction occurs over an electronic network 6 (such as the Internet) and wherein the customer pays for a product using electronic cash in one 7 currency and the merchant receives electronic cash for the product in a di~erenl currency.
8 2. nese~ I ;o~ of the Prior Art g Soon, ;Ille- IlAlional commerce may be a common experience for almost everyone.
This is due, in large measure, to computer networks, inrlll~ine the Internet, which link individuals, 11 con~umers, busin~-sses, finAnri~l in~titution~, educ~tional in.ctitlltions, and gov~l "~ nt facilities.
12 In fact, the growth in ;,11~- llAl;onAl coll.ll-elce appears limitless, given the forecasts relating to the 13 commercial use of the ~nternrt and the like.
14 There is a problem, however, iQl~elelll in il lelllalional commerce, electronic or otherwise.
The problem exists, for the most part, because monetary systems differ from country to country.
16 That is, money is generally expressed in di~crclll currencies in di~c elll countries and the value 17 of the di~crel~l currencies vary greatly. Currency co.~vc ~ion is widely used to convert money 18 from one currency into money of a di~erenl currency.
19 As used herein, the terrn "currency" inrlllde~, but is not limited to, denominations of script 2 o and coin that are issued by govcllllllent authorities as a mef~ m of exçhAnee. A "currency" also ~c~n ~

A \1~

may include a privately issued token that can be exchanged for another privately issued token or 2 government script. For .oy~mp1e a company might create tokens in various denominations. This 3 com~ally issued 'money" could be used by employees to purchase goods from merch~l~ In this 4 case, at exchange rate might be provided to convert the company currency into currencies which are acceptable to melchallts.
6 In each in.~tAnr~ currency conversion rel)lese,lls a ~i~nifir~nt economic risk to both buyers 7 and sellers in intrrn~tionA1 commerce. For example, assume a customer desires to buy a product from a merchant. Further consider the scenario where the customer pays his credit card bills in g United States dollars and the merchant only accepts French francs for the products he sells. The c~1stom~r uses his credit card to pay the n~e~ for the product. The ~e~hat~l receives French 1 1 francs.
2 Typically, at an undetermined later date, the colllpa.~y issuing the credit card would bill 13 an amount to the customer in United States dollars. The amount billed to the customer is 14 determin~d by an eyrh~nge rate used at the time the credit card company settles the trAn.~A~ction This sett1~mPnt is often at an indetc~&le time and could be on the date of purchase or several 16 days or weeks later. The time of this sett1~m~nt is at the credit card coll,pa~s discretion. The 17 risk to the credit card co~ A~ is minimAI it can settle the tr~n~Action when exchange rates are 18 favorable. Thus, in this case, it is the ~lo~ who bears the risk that the value of the cUstom~orls 19 currency will decline prior to this settlpm~nt As another e ple, consider a cash t~ ~c~ction where a lll~rcllanl accepts a ~;U~21 other than that of his countrys ~;Ull~ ~. In this case, the ~ ~l sells the ~;ulle~ to a 22 currency trader, usually at a ~ u---.l The price the lllc;~ha~l charges to the a1stom~r who pays 23 cash refiects both the cost of currency conversion (the discount) and the risk that the rate used 24 to ~ h1i~h the price ofthe product in a particular ~UIl~ ~ may have c1~n~d This results in the ~P~AJVS U ~ JAN 1 customer paying a higher price for the product and the merchant incurring risk due to a possible 2 change in currency exchange rates.
3 Thus, the described post sale methods of currency exchange may impart significant risk 4 upon the customer and the merchant. Risk is typically on the side of whoever commits to the currency conversion. Specifically, in a cash transaction, the customer bears the risk when 6 currency is converted prior to purchasing a product. The merchant sust~in.c the risk when he 7 converts the customer's currency into his own currency. Also, in the case of transactions on the scale of a few cents, the cost of currency conversion may be greater than the currency is worth.
g As yet another example, consider the risks that an individual acsl.mes when he collvells from the currency of his country ("native currency") to a di~elelll second currency. In this case, 11 the individual can purchase goods at a price in the second currency, but cannot be certain of the 12 value of the second currency relative to his native currency. In this case, the currency exchange 13 has occurred pre-sale. Thus, the individual ~Cs~-m~s the risk of devaluation of the second currency 14 against the first. Further, the customer bears the risk that the second currency may cease to be ' cGllvell;ble into his native currency.
16 It is noted that if the individual desires to purchase an item in a third currency which differs 17 from the native and second currencies, he must undertake at least one additional currency 18 conversion (C~ llillg either his native currency to the third currency, the second currency to the 19 third wr~, or a comhin~tiQn of both). In this case, the c~stom~r ~C~lmes an additional risk.
The present invention reco~i7es that int~rn~tion~l co.. -ce over electronic n~ lw~lks, 21 such as the TnJ~rn~t, cannot reach potential unless customer and nler~ anl oblig~tionc relating to 2 2 tr~n~actionc are fixed at the time of the tr~nC~ction so that risk to these parties associated ~,vith 23 currency eYf.h~nge is l~;n;n~i7ecl Thus, what is needed to encourage the development of 24 int~rn~tion~l comm~rce over such networks is a system and method that offers a means of - ~MEND~D SHEE~

çlimin~tinp, the unce~ y associated with multi-currency transactions. One aspect of the 2 invention disclosed herein shifts the risk associated with currency exchange from both the 3 merchant and customer to a third party 4~g., a server) in real time. This server may assume the 4 risk itself or may choose to subsequently pass on the risk to a fourth party ~.~,, a bank or other fin~nni~l institution).

.. . .

.....

! vt ~e!i ~ ~ / U 9 ~ 1 IPE~IIJS O 2 JAN lg9~

SUMMARY OF INVENTION
2 The present invention is directed to a system for determining approval of a transaction 3 between a merchant and a customer. The system comprises a merchant device associated with 4 the merchant. The merchant device has a first set of data inclu~ing a product price in a first currency The system also has a customer device associated with the customer. The customer 6 device has a second set of data inrl~ltlin~ a first amount in a second currency. The system further 7 has a server device connected to both the customer device and the merchant device for receiving the first and second sets of data and for approving the transaction when the first amount in the 9 second currency is within a risk range of the price in the first currency in accordance with current exchange rates.
11 Another aspect of the present invention is directed to a system for det~rmining approval 12 of a transaction between a merchant and a customer. The tr~neactinn in~ludes the merchant 13 providing a product to the customer at a price in a first merchant currency. The price in the first 14 IllClCIlalll currency is known by the c~-etom~r. The system cony ri~s a c -etomRr device associated ~ ~ with the customer. The cu.stQmPr device has a first set of data inr.lu~ling a customer amount in 16 a clletom~r currency. The system also inrl~ldes a server connected to the customer device having 17 the merchant price in the first merchant currency for leceivh~g the first set of data, and for 18 approving the tr~n~ctinn when the customer amount in the customer currency is within a risk 19 range of the price in the merchant currency in acc~ rdance with current eYch~e rates.
Still another aspect of the present invention is directcd to a method for detRrminir~
21 approval of a~r~n~ction bet~,veen a ~e~ch~l having a merchant device and a c~l.stomRr having 22 a c~-~tom~r device. The ~c~ &.l device and the c~l~om~r device are c4nl~ecled to a server. The 2 3 method CQ~Ip~ transmitting a first set of data from the merchant device to the customer device.
2 4 The first set of data inrl~ldes a merchant price in a first Illcrch~l currency. The method inr.ludes IPEA~JS O 2 JAN 1~98 receiving the first set of data by the customer device, wherein the customer device has a second 2 set of data inrl~l~in~ a c~lst~m~r amount in a first customer currency. The method further includes 3 tran.~mitfing the first and the second sets of data by the customer device to the server and 4 ~ ".;~t;"g the first and second sets of data by the customer device to the server. The server is s for approving the transaction when the customer amount in the first customer currency is within 6 a risk range of the merchant amount in the merchant currency in accordance with current 7 exchange rates.
RRTF.F l)~ RrPTION OF nR~WTN~.~
g Representative embo~im~nts of the present invention will be described with reference to.
the following drawings:
11 Figure 1 is a diagl~llllatic represPnt~fion of one aspect ofthe present invention.
12 Figure 2 is a diagr~mm~fic representation of another aspect of the present invention.

14 TT~F. PRF,FF,RRF,T- F,MR~l)TMF,NT~
Reference is now made to Figures 1-2 for the purpose of desc,il.ing, in detail, the 16 preferred embodiments of the present invention. The Figures and accolllp~ing det~iled 17 description are not int~n-led to limit the scope of the claims appended hereto.
18 The prtrtllcd ~ re ofthe present invention is generaUy ~Ficted in Figure 1. Figure 19 1 shows three entities: a server 100, a cl~stQmlo~r colll~.ulcr 200, and a ll~crchalll comr~lter 300, 2 0 c~-nn~ted to each other via a network 50. The network 50 may be a private, public, secure, or 21 an i~.e ~ .Ul~ The ple~l~d embo~im~nts of the present invention co~ .nl late use of an 22 il~s~e nCIWOlk~ for example, the Tnt~n~t The conl-ec!;~n~ to the n~lwulk 50 are id~ntifiçd by 2 3 lines 105, 205, and 305, lespe.,li~rely, and are well known in the art.
24 The Illelcha,~l computer 300 l~l~se.lls the computer of an individual, for example, a AI~END~D SHEEt ~ ~ ~~ ~ ~ ~~
. .

~l~q~,n~q~;
IPE~/US O 2 ~IAN 1998 merchant user 303, who sells products via the network 50. A "product" may include goods, 2 services, information, data, and the like. The customer computer 200 represents the computer 3 of an individual, for example, a customer user 203, who wants to buy a product (or products) 4 from the merchant user 303 over the network S0. The me~h~niim of delivery of the product is not a part of this patent. Product delivery could be coincident with payment, before payment, or 6 after payrnent.
7 The server 100 represents a computer of an entity who processes transactions between the c ~Q~tom~r user 203 and the Illelcl~ll user 303. The server 100 has a ~t~b~e in~ lin~ at least g one ~lstomPr account in a first currency ~Qso~t~ with the custom~r user 203 and one merchant account in a second currency associated with the merchant user 303. The first currency differs from the second currency. The accounts preferably store electronic funds of the parties, for 2 example, electronic cash. The electronic funds are a lepresellLalion of funds (real cash, credit, 3 etc.).
14 The server lO0 also has its own server accounts. The server accounts are in currencies corresponding to the currencies of the custom~r and l~ ,halll accolmts. The server accounts 16 repl~selll real cash, credit, etc. corresponding to the elc~,l.onic funds stored in the customer and 17 Il.elch~l accounts.
1 8 We prefer to ~ ;.. local accounts at the mercha.ll computer 300 and the customer 19 co~ 200. The local a~ ntC lCpl~t the el~cllonic funds in the ~c~chal~l account and the 2 o ~ .... ~col~nt mairlt~in~ at the server 100, respc~ ,ely. The local accounts ofthe c ~stom~r 21 and the l-lerch&lt are s~ s referred in the art as "wallets" and "cash le~;,lel~", respe~ ,ly.
22 The server aGCol~nts may be all~ged with a bank or other fin~n~l inQtitution 2 3 To illustrate how these accounts might be set up, conQ;der the .~ tion where a ~Istomer 24 user 203 lives in the United States and purchases products using U.S. dollars. Further assume ~CtOC 97/ 0 9 9 6 1 ~PEA/IJS 02 JAN 1998 that a lllèrcl~ll user 303 located in France conducts his operations in French francs. In this case, 2 the server lOO may have a customer account in United States dollars and a merchant account in 3 French francs. The server 100 processing transactions between these parties may have two 4 electronic accounts repres~ntin~ all user accounts whose currencies are in dollars and all user 5 accounts whose currencies are in francs as well as two real accounts in a bank. one server account 6 would be in United States dollars and the other server account in French francs.

7 When the network 50 is insecure, we prefer to take measures to assure that the server 100, customer computer 200, and the merchant computer 300 can communicate securely over the g net~,vork SO. Of course, secure co~unication is not recluired for the present invention, but is 10 only a prerellèd form of such communication.
11 Central to achieving such security while m~ a high pelÇoll lance payment system 12 is the use of "se~ion~". A session is an opportunity (or window) in which the customer user 203 13 may purchase a product from the merchant user 303 over the network So or which the merchant 14 user 303 may sell a product to the customer user 203 over the network 50. By using a session, a Illel~l~l can securely commllnicate with a customer over an i~se~iule network. The customer 16 user 203 and the lllèr~halll user 303 have their own in~lepen~ent ses.~ on~. Sessions are of limited 17 duration. This duration is governed by predetermined pal~eters. These parameters are 18 plerel~ly set by the ~l~lc.. ~r user 203 and the lllel~ .ll user 303. However, the server 100 may 19 set or limit values of such parameters..
We prefer that the p~,lers relating to the session of ~.~4r~ r user 203 limit an amount 21 of ~ ;llun~c funds (the "session a~ulll"), a ~..~ amount oftime that the cllstom~ s session 2 2 may last, and a ~il~ number of tr~n~ions that the alstomer user 203 may con-~uct The 2 3 session amount is the ~ulll amount of electronic funds that the customer user 203 may spend ~ 4 dunng the c~ lol~ . 's session. Also, we prefer that the session of lll~,,cl~l user 303 is limited by .. . . ...
- ~MENI~E) 8~1iE~

~l~c97109961 lP~ S O 2 , l~l N 1998 a maximum amount of time that the merchant's session may last and a maximum number of 2 transactions that the merchant user 303 may conduct.
3 To accomplish such secure communication over the insecure network, a first session 4 associated with the customer user 203 is created. The first session has first use parameters for limiting the duration that the first session can be used and a set of customer data. The first use 6 parameters and the set of customer data are idçntifi~ble by the server l00. A second session 7 associated with the merchant user 303 is also created. The second session has second use parameters for limiting the duration that the second session can be used and a set of merchant g data. The second use parameters and the set of merchant data are identifi~l3le by the server l00., Over the insecure network, a portion of the first session and a portion of the second session,are 11 linked. The portion of the first session inrl~ldes the set of c lstom~r data and the first use 12 p~elers. The set of c ustQm~r data may include a cll~t< m~r identification string which identifies 13 the customer user 203. The portion of the second set of data in~ des the set of merchant data 14 and the second use parameters. The set of mercha.~l data may include a merchant id~ntifirAtion string which i-~PntifiPs the ~,l~l user 303. The server 100 verifies the customer user 203 and 16 the merchant user 303 based upon at least portions of the set of cll~tom~r data and the set of 17 merchant data and detP-rmines that the first and second sessions can be used. In this manner,--18 confitlPnti~l details ofthe pa~ l b~,lw~l~ the customer user 203 and the merchant user 303 are 19 assured of being comm~ icated se~,~cly. Of course, other mPtllot~ and systems for est~b!ishing 2 0 secure commlln;~~ti~ n over an i~ wulk may be used to use the invention set forth herein.
21 The lii~,.ch~l user 303 and the c~1.stQmP~r user 203 endeavor ultim~tPly to effect â
2 2 "tr~n~C~ion"~ that is, the ~ur~ase of a product by the c~lstom~r user 203 from the l.lerch~l user 23 303. The merchant user 303 and the customer user 203 need not have any prior existing 24 rd~tionchir to transact business. This is so because the merchant user 303 and the c~stQmPr user ~697/0~961 IPEAIUS O 2 . I a ~1 1998 203 each have a preestablished relationship with the server l00 prior to tr~n~acting business.
2How the parties form this relationship is not part of the present invention. Rather, what 3is important is that the customer and merchant accounts, described above, exist with the server 4l00. To form the relationship, we prefer that the customer user 203 provide information using 5cl-~tonl~r computer 200 to the server l00. Such information may include the name of customer 6user 203 and the currency in which he intends to purchase products. In the case of the merchant 7user 303, this information may include the name of the merchant user 303 and the currency in which he intends to uhim~t~ly receive for providing products. Other information can be provided gas deemed necess~y by the server 100.
1 0This relationship may be either direct or indirect. An indirect relationship, for example, 11would include the ~it~l~tion where one or more entities, previously known to the server l00, vouch 12for the lllc;lcl~ll user 303 and/or the customer user 203. Public key cr~vpto systems are generally 13used in this type of vouching process and are well known to those skilled in the art. The process 14of using public key crypto systems as such is known in the art as "certificate management" . In this case, vouching entities are known as "c~; liLc~le a~ . Certific~tes, certificate management, 1 6and certificate ~uthorities are well known in the art and are not the subject of the present invention.
17The present invention is directed toward "approval" of a multi-currency tr~neactiQn in 18which the c~lstom~r user 203 pays in a first currency and the merchant user 303 accepts the 19payment in a second ~ en~ which differs from the first currency, rather than the completed 2 0 lr~ ~ ~~ction itself. As will be des-,lil)ed below, approval co.. ;l ~ the custom~r user 203 and the 2 1~;l.,l~d~t user 303 to the terms of the tr~ncaction and CG ~ ls the server l00 to pC~ l virtual 2 2settl~mPnt of the transaction.
2 3As used herein, ' virlual settl~m~nt" of the tr~n~action repiesents at least the movement of 2 4el~llolic funds to a merchant account of l~e-c~ ll user 303 held by the server 100. It may also ~697~09961 IPE~JUS 02 .In~i 1998 represent the movement of electronic funds from a customer account of the customer user 203 2 held by the server lO0. This is to be distinguished from actual settlement of the transaction. As 3 used herein, "actual settlement" of the transaction inçl~ldes at least converting real funds in an 4 amount equal to the amount in the customer selected currency into real funds in the merchant accepted currency.
6 The parties are co" " ~ ed as such because of pre-existing bilateral contractual obligations 7 between merchant user 303 and the operator of server lO0 and between customer user 203 and the operator of the server lO0. The contractual obligations are preferably formed during the g CO",~ n~ of service rPI~ion~hir between the server lO0 and the customer user 203 and the.
merchant user 303 respectively.
The obligations may include the agru,~ l of cl.sto~ner user 203 and the merchant user 12 303 to permit the server lO0 to pelru.lllvirtual settlement ofthe transaction. In return, the server 13 100 may agree to incur the risks associated with currency exchange when it performs actual 14 settl~mPnt of the transaction. We prefer that the custûmer user 203 and the merchant user 303 agree to allow the server lO0 (on behalf of the opcl ator of the server lO0) to 1~ lAi~ Ail~ accounts 16 and b~ ~s offunds ~ ~ag~l by the server lO0. Further, we prefer that the movement of funds 17 between those accounts be coin~id~nt with the tr~n~action 1 8 In this way, the cU~tc)m~r user 203 knows ~.lb~ nl ;~lly the amount in the currency he will 1 9 pay for the product. Similariy, the ,l~ t user 303 knows ~b~ lly the price in the ~ .lC~
he will receive for the product. Thus, the ~ lo.. ~ user 203 and the ~e.challl user 303 do not 2 1 bear the abové~e~ - il qd risks ~c~ ~t~ with currency e~ ~e. The amount the customer user 22 203 knows and the price the lllc.cLalll user 303 knows is s~lb~ ;Ally the lespe~ e amount and 23 price because there may be minor factors that affect these actual values. Such factors will be 24 ~ interms of risk factors. It is the entity ch~ged with pe~ro;~-~ actual settlement ofthe A~N~O SHEE~

~ 97/ ~99 6 1 IP ~ S ~ 2JA~ 8 transaction who bears such risks when the transaction is actually settled.
2 The present invention is directed to approval of multi-currency transactions in which the 3 customer user 203 pays in a first currency and the merchant user 303 accepts the payment in a 4 second currency which differs from the first currency. To transact business, the customer user 203 may shop over the network 50 among the merchant users 303 who also have been permitted by 6 server lO0 to transact business (which may be, for example, those who have merchant sessions) 7 Using well known techn;que~, the customer user 203 and a merchant user 303 agree on a product to be purchased at a price and in a currency.
g Thus, the ~ user 303 will accept a price and receive payment for the product sold to the c~)stQm~r user 203. The price for the product is in a currency accepted by the merchant user 11 303, ~erelellced herein as the "price in the merchant accepted currency P(MAC)II. The customer 12 user 203 will pay an amount to the ll-e ~ dnl user 303 for a selected product. The amount will be 13 paid in a currency selected by a-.~tcm~.r user 203, rere.~.lced herein as the "amount in the customer 14 selected currency A(CSC)tr. The currency sPIected by the ~ user 303 is diLrere~ll than the currency selected by the customPr user 203. Hence, currency ~Yc~l~e is used to applove the 1 6 transaction cont~mrl~ted by the present invention.
17 In a first embodiment of the present invention, the server lO0 is used to approve the 18 transaction b~t~n the ~llclchalll user 303 and the c~l~tQmer user 203. As stated previously, 19 approval commits the .~ u~ user 203 and the ~l-.,.cLa,l~ user 303 to the terms ofthe tr~n~otion 2 0 and con;Ls the server lO0 to p~ru-l virtual settl~m~nt of the tr~n~action 2 1 In this ~llbO'~ d, the u ~.to.~ user 203 and the ~ ,.. ,L_lt user 303 have established and 22 agreed upon a product to be IJul~,l~d at a price the ~lchaul user 303 will accept. This product 23 and price are lefe -ed to herein as the "agreed product" and the "agreed price", respectively - ~MEN~ StlEET--.

CA 02260002 l999-0l-06 r~r~6 97/ 0 9 9 6 1 IPEAJUS O 2 J,~N 1998 Having agreed upon the product and the price, the melcll~ll computer 300 transmits a first 2 set of data to the server l00. This first set of data in~ dçs the agreed price that the merchant user 3 303 is willing to receive for his product. The tr~ncmitted agreed price is in the merchant accepted 4 currency. Other i~ "alion may be transmitted by the merchant computer 300 as needed by the server l00, for example, information identifying the merchant user 303, the product to be 6 purchased, account information, etc.
7 Having agreed upon the product and the price, the customer computer 200 transmits a second set of data to server computer l00. This second set of data incl~ldP~s the amount that the g customer user 203 is willing to pay for the agreed product. The tr~n~mitted amount is in the cl~ctomPr sPIected ulllen~iy. As previously stated, the customer selected currency is contemplated 1 1 as being di~r~lll than the merchant accepted currency.
12 In a further aspect of this embodiment, we prefer that along with providing the amount in 13 the customer selected currency A(CSC), the customer computer 200 also transmit the agreed 14 price in the ~l~cr~ t ac~ted currency P(MAC) to the server 100. This assures that the customer user 203 and the ll.c.chal~l user 303 have actually reached a~.l.enl on the terms of the 16 transaction and precludes either party from denying such a~ ,~e.ll. Other inro~",ation may be 17 tran~mitted by the cllctomP,r computer 200 as needed by the server, for CA~U~IC~ a requested 18 p&,~ t range (d~ il.e~ later), inro,l.,dlion ide,lliryillg the customPr user 203, the product to be 19 purchased, account il r~ alion, etc. It is not required that the L~.cl~l user 303 know or 2 0 approve the ~lctomPr selected currency, that is, the currenc.,v in which the cl~stomer user 203 will 2 1 pay. There is no reql~irtlll~.lt that the ~ Q~ r user 203 al~plo~, the Ille.~ accepted ~ n~iy~
22 that is, the ~ n~iy which the lllc.-,l~l user 303 will receive. What is required in this 2 3 embodiment of the present invention is that the server 100 be able to convert one such currency ~IENOED SHEET .

IPEAQJS O2 .1~Al lqaQ
into the other.
2It is noted that not rcqlliring "approval" of a currency by the merchant user 303 and/or the 3 customer user 203 is di~tin~ h~ble from the approval of a "transaction" by the server lO0.
4 Approval of a currency would be, for example, where the customer user 203 would need the 5 permission of the merchant user 303 to pay in a given customer selected currency. Approval of 6 transaction, on the other hand, commits the customer user 203 and the merchant user 303 to the 7 terms of the transaction and commits the server 100 to pelÇo~ll virtual settlement of the transaction. The present invention does not require approval of a currency.
gThe first and second sets of data l~ led to the server lO0 need not come directly from 10the ",~ l~l computer 300 and the c~lstomPr computer 200. This ;llrolllldlion may be lli~n~ led 11 via alternative routes. For PYAmrlç~ we pref er that customer computer 200 ll~ l the second 2 set of data to the merchant computer 300. Upon receipt of the second set of data, the merchant 13 computer 300 l~ lflls at least the amount in the cl~tc mPr selected currency A(CSC) and the first 14 set of data in~ ling price in the mclchanl accepted currency P(MAC) to the server lO0 for approval of the transaction. In this case the second set of data may be protected to prevent the 16 merchant from altering it.
1 7Upon rec~ i~ the amount in the c~lstom~r selected currency A(CSC) and the agreed pric~
18 in the mercl~l accepted currency P(MAC), the server lO0 approv~s the transaction. The 19 appluv~l process pe- fi~....~d by server lOO is based upon the relative value ofthe c~stomPr sPlected 2 o currency in terms of the lllc ~halll accepted ~iull~,nc~l. This relative value may be established by 2 1 the op~.~tor of server lO0, a third party, or in other aspects of the present invention, the customer 22 user 203 or the ll.erchallt user 303. This pi~,fel;.bly inrl~ldes a rate of P~ A~ge at which the 23 clletomPr sPIected currency canbe converted into the lll~,.cL~L accepted currency. ~ItPrnAtively, 24 or in addition, this i~ulmalion may include a rate at which the ~llerc~ l accepted ~iUllen~ can ~C~97/ (~99~1 be converted into the customer selected currency.
2 Approval of the transaction occurs when the amount in the customer selected currency 3 A(CSC) is sufficient to pay the merchant user 303 the agreed price in the merchant accepted 4 currency P(MAC). The sufficiency determination process preferably includes converting the amount in the customer selected currency A(CSC) into an amount in the merchant accepted 6 currency, referenced herein as the "amount in the merchant accepted currency A(MAC) ", using 7 a current exchange rate.
The current exchange rate data is preferably m~int~ined by the entity charged ~,vith g approving the tr~nC~c~iQn Thus, in this embodiment, the server lOO may obtain it from a currency broker or bank. In a further aspect of this embodiment, the approving entity may decide to buy and sell currencies and establish its own exchange rates. In addition, as the server 100 has the 2 opportunity to aggregate transactions prior to committing to actually exchange currency with an 13 external agency, it may obtain plcçerel~lial exchange rates by converting money in relatively large 14 units.
The frequency that the current ~ UI~e rate data is updated dep~n~l~ upon the level of risk 16 that the approving entity may be willing to accept and the availability of updates from currency 17 brokerage services. It is p-crc~led that when the server lOO is the approving entity, it receives 18 updates to the eYch~nge rate data on-line from one or more currency brokers. Frequency and 19 timing of updates are based on business rules agreed b~ en the operator of the server 100 and 2 0 the currency broker or brokers. This m~nag~ the risk of a significqnt change bcll ~n the current 21 ~Yçh~n~e rate and the exchange rate used when the tr~ncaçtion is actually settled.
22 Approval of the tr~n~action by the server lOO is preferably based upon predetclmmed 2 3 criteria. These criteria may be established by any of the parties to the tr~n.~actiQn or a third party.
24 For e.~ , we prefer that the server 100 approve the transaction if the amount in the merchant AMEIYDE~ SH~

~C~97/09961 iP~ ; Q~

accepted currency A(MAC) equals or exceeds the price in the merchant accepted currency 2 P(MAC).
3 Alternatively, the server lO0 could approve the transaction if the amount in the merchant 4 accepted currency A(MAC) is less than the price in the merchant accepted currency P(MAC). In this instance, the server lO0 may absorb di~le~llials (as where the cost associated with 6 disapproving the tr~n~ction and reprocessing it exceeds the di~relenlial). Acceptable di~le,llials 7 may be depen~ nt upon the credilwol ~hiness of the customer user 203 or the merchant user 303, the accept~le deficit balance that the customer user 203 or the merchant user 303 are allowed to g incur, or other market con-lition~ such as, for example, fluctuations in exchange rates. These acceptable di~ele,llials are lefelled to with respect to each party of the tr~n~action as a ''risk 11 range".
12 Also, in the case where the amount in the ll~lel~l accepted currency A(MAC) is less than 13 the price in the ".~l~l~l accepted currency P(MAC) but within a predet~rmined range, the server 4 lO0 could record the di~renlials as they occur and collect them from the cUctQm~r user 203 at a later time. This range is co.,l~...pl~ted as being a small range and is ,er~".d to herein as the 16 "payment range". The pa~"lcnt range may be predel~ ed by the cu.stQm~r user 203 or 17 preferably, by the server lO0. For the purpose of this applic~tion, the amount in the customer 18 selected currency A(CSC) is equal to the amount in the customer selected currency A(CSC) plus 19 or minus the p~~ l range. The pa,~ l range thus defines the amount of co~els,on error p~ ed inthe l,~n~ ;on 21 Approval of the tr~n.~action may also be co.. ~ g~ ~~ upon the cl~stomer user 203 having 22 access to electronic funds in an amount equal to or e ~ g the amount in the cl~st~mer selected 23 currency A(CSC) These funds may be stored or r~l~.llod in a c~lstQmer account associated 24 with the cU~tomer user 203. In this case, the server appn~s the transaction when the amount in , . .. . . . . . . ~ . .. . .. . ..

PCT~J6 9 7/ 0 9 9 6 1 IPEA/U~ ~ 2 JA~i IJ~
the merchant accepted currency A(MAC) meets the predetermined criteria described above and 2 the customer account contains electronic fi~nds in an amount at least equal to the amount in the 3 customer selected currency A(CSC). Using any of the above methods for approval, alone or in 4 combination, the server l00 approves the transaction.
5In order to avoid having to access the customer account of the customer user 203 and for 6 security reasons, we prefer to limit the amount in the second set of data that a customer user 203 7 can transmit to the server l00 by the session amount. The session amount is an amount known by the server l00 to which the customer has access when the cllstomer user 203 is permitted to g shop. The limited amount is reduced as the customer user 203 purchases products over the 10network 50. The customer computer 200 temporarily prohibits the customer user 203 from 11 tr~n~mitting an amount exceeding the session amount to the server l00 to be considered for 12 ~lffi~ien~y until more electronic funds is added to the session in which case the session amount has 13 been increased. It is plefel-ed that under such cirC~m~t~ncçc~ the existing session will 14 alltom~tic~lly close and a new sessionwill be opened with funds at least s~ffici~ont to complete the tr~n~ction Once the sllbs~l~ session is opened, the trlr-~ction may be approved. Of course, 16if the server computer l00 determin~s that customa user 203 does not have enough funds 17 available to it to open a subsequent session of sllffirient value, the tr~n.~action may be refused by 18 server l 00 altogether or the server l 00 may approve the transaction as described herein.
19It is pl~f~l~d that the funds a~ R to ~ t~ r user 203 during its session and the funds 2 0 received by the l.,e,.,l~&~ user 303 during its session be ~ ;. .ed to two deci al positions to the 21 right of the minor unit of a currency. For ~ rle~ in the case of U.S. dollars, the present 2 2 invention pl.,f~ would carry the value of session funds to one hu~d~edlll of a penny to assure 23 that rounding errors are ~;n.~ ecl during a s~C~ion thus decreas~g rounding errors during 24 currency conversion of small transactions. When a session closes, the balance in the session is JlENOEO S~

r~ 1/ u 9 9 61 IPEAJUS 0-2 J~ ~l 1998 adjusted to whole minor currency units (this adjusfrn~nt may be rounding or truncation).
2 Once the transaction is approved, the customer user 203 and the merchant user 303 are 3 co~ led to the terms of the tr~n~ction Specifically, the customer user 203 is committed to pay 4 the amount in the customer selected currency A(CSC) Similarly, the merchant user 303 is 5 committed to accept the price in the merchant accepted currency P(MAC) for the product. The 6 parties are committed as such through the contractual arrangement previously described.
7 By the contractual obligations described above, the server 100 is committed to perform virtual settlement ofthe transaction. Ther~o~e, according to this aspect of the present invention, g a lllelcl~l account may be l.l~ d for the lllelch~l user 303 and a customer account may be 10 m~int~ined for the customer user 203. The merchant and c~lstomer accounts are plefelably 11 m~int~in~ by the server 100. However, one or both of the accounts may be m~int~ined by a party 12 other than the server 100.
13 The merchant account and cl-stoma account may be debit or credit accounts. We prefer 4 that the customer account be a debit account and that the ~ercl~l account be a credit account and that each such acco~nt repl~d funds in the form of ele~ ouic funds. However, other types 16 of accounts may be used as known by those skilled in the art.
17 In the case where a party other than the sener 100 .. ~ in~ a merchant account and/or 18 a cl-stom~r a~c ~mt, the server 100 rnay l~ data to the party to enable virtual settl~m~nt For 19 exarnple, if the party ~ inçd the ll,e.ch&lll account and the cllctomPr account, the sener 100 20 may l~ns~ l data idenli~jing the machant account and the price in the l..ercl~l accepted 21 currency P(1~AC) to be clediled, and the cllctompr accollnt and the amount in the cu~tom~o-r 2 2 sel~ted currency A(CSC) to be debitec~ Then, the party would debit the c~stom~r account and 2 3 credit the merchant account accordingly.
2 4 In this process, upon approval of the tr~nC~ction~ the cil~tQma account is debited by the AMI~N~E~ ~
. . .

~$us u~ v~

amount in the customer selected currency A(CSC). The merchant account is credited with the 2 agreed price in the merchant accepted currency P(MAC). This amount and price were known by 3 and agreed to by the c~-.etom~r user 203 and the merchant user 303. Thus, there is no uncertainty 4 as to the amount or currency to be paid by customer user 203 or the price or currency to be received by merchant user 303.
6 Several variations on the above described embodiment provides that the currency used in 7 the c ~etom~r selected currency may be selected by the customer user 203 (or the server l00) from a plurality of currencies, referred to herein as "customer currencies". Also, the currency used in g the merchant accepted currency may be selected by the customer user 203 from a plurality of currencies, referred to herein as "merchant currencies". A description of these variations is now 11 provided.
12 A customer user 203 may have access to amounts in a plurality of customer currencies.
13 For ~Y~mrl~, a ~lstom~r user 203 may have accounts co~ in~ amounts in United States dollars, 14 French francs, and J~p~ne,ee yen. The customer user 203 may ~ chase products using amounts from any of these aCcolmtc To effect this option, the c-lctomer computer 200 presell~s an amount 16 in each of the plurality of customer currencies to the customer user 203. This is done using 17 exchange rate data for each customer currency to convert the merchant accepted currency into 18 ~mol-ntc in each ofthe Ul~!lller W lellc;es. It is prefe.led that the exchange rate data be provided 19 to c lctcmpr c~nyuter 200 by server l00 at various times. Other ~.. c ~ cme for obt~ning such 2 0 data include the use of brokers. The customer user 203 selects an amount in one of the plurality 21 of ~ n~ r ~l~,ncies in which the customer user 208 will spend for the product. This selected 22 amount l~lcsenls the amount in the custQm~r se~ led ~ .,~ A(CSC) des- ~ ;l.ed previously.
2 3 In the above d~rirtion~ the method by which the c lstQm~r computer 200 can det~ormine 24 the amount of customer currency to pay for a purchase in the lllc.chal co."~ t~r 300's currency IPEA/US ~ ~ SAN ~9~86 1 is omitted. While there are a number of ways to enable this conversion, we prefer that prior to the 2inception of the customer computer 200's session, that the customer computer 200 request 3 exchange rate data. This data will contain at least conversion rates &om the session currency to 4 other convertible currencies, it may also contain additional data such as anticipated expiration of 5 the exchange rates. These rates are used by the customer computer 200 to estimate the amount 6 of customer currency to pay for a purchase in ,llelcl~l currency. As conversion rates may change 7 rapidly, we prefer that this data be advisory only. the server 100 may send updated data to the c~tomçr computPr 200 during any comm~ln:~~tion between them. The implication of this decision g is that if the customer computer 200 pays insufficient funds to convert, it is viewed as a natural 10 error due to obsolete data, not an attempt to de&aud.
11 This aspect of the present invention may further include an opl;.. ;~A~ion feature. The 12 o~ lion feature is preferably executed by the cUstom~r computer 200 to determine whether 13 it is advantageous for the customer user 203 to pay in one customer currency over another.
14More specifically, the c~ om~or comr~t~r 200 detçrmines the agreed price in the merchant accepted currency corresponding to the arnount in each of the plurality of c~tomçr currencies.
16 For c ~ p'e, assume the ~,..,L&llt user 303 will receive a price in currency C for the product and 1 7 the customer user 203 has two customer currencies A and B available to pay the merchant user 18 303. The ~.~4O.".. r c~ 200 d~lç~ m;~-es amounts in currencies A and B which equate to the 19 merchant price in ~ul~ l~ C. These ~mollnt~ may be com~ ed by collv~ g them to a r~,f~n,nce 2 0currency of the c~lstomçr colll~,uler 200's choice. The cll~tomPr user 203 may choose (or the 2 1 customer compllt~r 200 may be pro~ed to choose) to pay the agreed price in the ~iull~
22 (A or B) which collesl,onds to the lesser amount in the l~relence currency. The amount in the 23 chosen currency lepres~ s the amount in the cu~stQm~r sçlected currency A(CSC).
24According to another variation to this oplil~ ion feature, the c~l~stQm~r computer 200 ~eClEA/US ~) ~ JAN 1~9~

may also determine whether it is less expensive to first convert currency A into currency B, and 2 then to convert currency B into currency C. In any case, the customer user 203 pays using the 3 optimal payment currency. This prerelled mode reduces complexity of currency exchange to the 4 customer user 203 without reducing the options available to the customer user 203.
It is also contemplated that the server lO0 may execute an opthl.i~lion feature. In this 6 case, the server lO0 may include the plurality of c~l~tomPr currencies available to the customer user 7 203. For e~ullple, data in~ tin.~ the plurality of customer currencies may be tr~n.~mitted in the second set of data from the customer computer 200 to the server lO0 in lieu of the amount in the g cu~tomPr selected currency A(CSC) . In a manner sirnilar to that described above, the server lO0.
10 de~ es the agreed amount in the lllel~ accepted ~;Wl~ ;y A(MAC) for each of the plurality 11 of c~stomPr C-wlellC.;eS. The server lO0 then chooses an amount in one of the customer currencies 12 corresponding to the amount in the merchant accepted currency which is least when converted to 13 the ler~lellce currency. The amount in the chosen currency represents the amount in the customer 14 selected currency A(CSC).
In another embodiment of the present invention, it is I ~ y e~lcd that a merchant user 303 16 may desire to transact business in more than one currency. Therefore, the l-ler~ih~l user 303 will 17 accept a price for the product in one of a plurality of"~ercha~l currencies. The merchant computer 18 300 co.~ ni~tes the agreed price for the product in each of the merchant currencies to the 19 customer co.. y~ r 200. The cU~tom~r computer 200 pre3chls the agreed price in each of the 2 0 merchant ~ ,lC;eS to the a~tom~r user 203. The customPr user 203 selects the agreed price in 21 one ofthe lllélel~l ~ 1ell~,;e3 that the lllèr~,l~l1 user 303 will accept. This selected currency may 22 be l~.. en-led by the oy';~ ;on procedure des~,libed above. This sPlected price r._prese.lls 23 the price in the merchant accepted currency P (MAC), although it is actually selected by the 24 c~1stomer user 203.

...... . . .. . . . ..

lPEA/US ~ ~ /J~N91~

According to a variation to this op~ i~lion feature, the customer computer 200 may also 2 determine which customer currency - merchant currency pair represents the best value to customer 3 user 203. This is accomplished by customer computer 200 using exchange rate data to convert 4 the price of the product in each merchant accepted currency into each of the customer currencies and selecting the lowest value arnong the results. For example, if customer user 203 has access 6 to cullellc;es A, B, C and merchant user 203 is willing to accept currencies y and z, the customer 7 computer 200 will determine the cost of the products as quoted in merchant accepted currencies y and z in terms of customer accepted currency A. Wbichever of these conversions yields the g lowest cost to customer user 203 is the optimal customer currency merchant currency pair for customer currency A. This process is ,cpealed until an optimal currency pair is computed for each 11 cu~tom~r currency. For t~lln~ , this process may yield the following results: A to y, B to y, and 2 Ctoz.
13 The next step is to decide which of these currency pairs represents the best value to 14 clletom~r user 203. It is preferred that tbis be accomplished by converting each customer currency to a single reference currency. The cGnvel~;on that yields the smaller number is identified as the 16 "best" choice and is d~l~ed to c~lstom~r user 203. Clearly, other approaches to det~rmining the 7 optimum currency can be devised by those skilled in the art.
1 8 Another embodirnent of the present invention, as shown in Figure 2, again uses the server 19 100 to applo~c the tr~n~ on b~lweell the mercha~t user 303 and the c~lstom~r user 203.
However, the mercha~l computer need not be conne~iled to the n~lwolk 50 according to this 2 1 aspect of the i~vention.
22 More particularly, in this embo~lim~nt, the c~stom~r user 203 has knowledge about the 2 3 product that the merchant user 303 is providing and the price in the lllerchanl selected currency 2 4 for the product before submitting the second set of data to the server lO0. This knowledge need ~ , ~ . . . .. .

PC~16 97/ 099 6 1 not be gained while the cllctompr user 203 shops over the network 50. For example, the merchant 2 user 303 may have distributed catal-ogs to the customer user 203 (via regular mail, email, etc.) 3 illustrating products, prices, and currencies therefor. The server lO0 would receive the same 4 i~ aL~on, that is, data repre~nting the same products, prices and currencies from the merchant user 303. This data may be received by the server lO0 electronically over the network 50 or by 6 some other means. For example, the merchant user 303 might provide the data represP.nting the 7 products, prices and currencies therefor via a network to which the customer computer 200 is not c-~nnPcted or by mail on a diskette. However received, this data would be accessible by the server 9 100.
After viewing the catalog, the cll~tQm~r user 203 may ~ur~ ase a product over the network 11 50. In this case, the a-~tomPr comrutPr 200 transmits to the server lO0 a description of a desired 12 product ~Qg, model number) and an amount in the customer selected currency A(CSC) for the 13 desired product.
14 The server lO0 thus has access to data in-lic~ting the amount in the customer selected currency A(CSC) which the w~lo~ r user 203 is willing to pay for a product and the price in the 16 merchant accepted currency P(MAC) which the ll,e.cha~l user 303 is willing to accept for the 17 product. Wlth this data, the server 100 approves the transaction as indicated above.
18 In any of the foregoing embodimPnts, notice of approval of the tr~n~action may be 1 9 - provided by the server 100 to the n,~-,l~l user 303 and the cl~stom~r user 203. For example, the server lO0 may l~ il data in~iciqiting approval to the ~icha~.l comruter 300. After the 2 1 merchant co.i~uler 300 recei~es the data in~ic~ting appr~ , the merchant comrut~r 300 _ay 22 transmit at least a portion ofthe data indic~ti~g appru~al to the customer computer 200. In a 23 similar manner, data indicating approval may be comm.-nic?ted from the server 100 to the ~, ~ _ . . . .. . .. . .

~6 ~71 ~ 99 6 1 c~lstomPr computer 200, which, in turn, would forward this data to the merchant computer 300.
2 In this manner, the customer user 203 and the merchant user 303 may be informed that the 3 transaction was approved. Alternatively, the server lO0 may separately transmit data indicating 4 approval to the merchant computer 300 and the customer computer 200. In yet another 5 embodiment, the absence of notice from the server lO0 may be deemed as affirmative notice that 6 the transaction was approved. According to any of these procedures, or other preestablished 7 procedures, notice may be provided to the participants in the transaction. Further, once notice of 3 approval is provided, the product which is the subject of the transaction may be provided to the g customer user 203 and the pay~ lll of the funds corresponding to the agreed price will be received lo by the merchant user 303 in the merchant accepted currency.
11 Actual settlPmPnt may occur contemporaneously with the approval of the tr~n~action or 12 it may be deferred. As is described below, it is the entity charged with pelÇoll~ g the actual 13 settlement who bears the risk.
14 We prefer that the server lO0 perform actual settlement of the tr~n~action Therefore, accord~ to this aspect ofthe present invention, the server lO0 also has its own server accounts.
16 The server accounts are in currencies corresponding to the currencies of the c~lstomP,r and 17 merchant accounts. The server accounts represent real cash, credit, etc. corresponding to the 18 electronic funds stored in the customPr and merchant accounts.
1 9 To p~ru~ actual ~ll~ , the server lOG may transmit data to a currency broker, bank 2 0 or fin~n~~' inctihltion to enable ach~al settlPmPnt For P~mpl~, the server lO0 may transmit data 2 1 id~ iryi~g thé server account and the amount in the c -stomPr sPlectP~d currency A(CSC) so that 22 the entity can convert real funds in an amount equal to the amount in the cu~tom~r selected 2 3 currency into real funds in the merchant accepted currency.
24 We prefer that the server 100 aggregate the ~m-~lmt~ in each ~;wlency before settlin~ This r~l697/ 09961 IPEA/US ~ ~ J~

may decrease the number of actual conversions that must be made from possibly hundreds per 2 second to a few times per hour (or day). The frequency may vary depending on the volatility of 3 the currency exchange market and on the relative currency balances in the server lOO's various 4 currency accounts.
Note that the server lO0 is bound even if the later currency exchange rates are or become 6 unfavorable to the server lO0 as compared to the current exchange rates used during the virtual 7 settlem~nt By el;.,.;n~ the risk to the customer user 203 and the merchant user 303, such risk is passed to the server lO0.
g We prefer to take measures to manage the risk associated with the currency exchange to lo the server lO0. For example, we contemplate that the server lO0 may have a preestablished agreement with the bank or fin~n~i~l institution. The terms of such an aglee",e,ll might include 12 a co.. ;l.. ~ on the part ofthe server lO0 to settle tr~n~actiQns within a predetermined amount, 3 time, and/or within a predetermined currency rate deviation. The predetermined amount of time 4 may be on the order of several seconds or mimltes During this predetel"~illed amount of time, we prefer that the server lO0 agg,e~ale tr~n~ctionc and submit them in batch for exchange. In return 16 for the server lOO's co.. ;l.. ~l1, the entity may offer the server 100 a favorable currency PYcl~ e 1 7 rate.
18 It is seen from the above det~iled description that customer and merchant oblig~tion~
19 relating to multi-curr~cy tr~n~tions can be fixed at the time of the tr~n~action In this manner, 2 0 risks to these parties h~.etofole associated with ~,ull~n~ cl~nge is ,;n;i7ed, To this end, the 21 parties to a multi-currency tr~n~action a~tllori7e an applo~ g entity to settle the transaction.
2 2 ,~nl1lo~ n is granted by virtue of the cll~ompr user 2o3 and l,lc.cllanl user 303 setting up their 23 respective accounts, knowing that transactions will be submitted and processed. The parties 24 transmit data lep,e~ the lli~n~ l;on to the al)p,u~ g authority. This data incl~ldes an amount A~NOEDSffE~

~ V~ W 7 t / U ~ ~7 F,~ ~ 2 . ~

in a first currency that a cUstom~r user 203 is willing to pay for a product and a price in a different 2 second currency which a merchant user 303 is willing to accept for the product. Using 3 predetermined criteria, the approving entity approves the transaction. Once the transaction is 4 approved, the approving entity may actually settle the transaction at its discretion thereby bearing s the risk associated with currency exchange. The parties, however, incur no risk. The customer 6 user 203 will pay the arnount in the first currency and the merchant user 303 will receive the price 7 in the second currency. These are values known and agreed to by the parties at the time of the transaction.
g An ~It~m~te method of m~n~f~n~ risk for eAllem~ly volatile currencies, the server 100 may choose to withdraw a currency or currencies from the list of convertible currencies.
11 ~Ith-u~h the particular embodiments shown and described above will prove to be useful 12 in many applications relating to the arts to which the present invention pertains, further 13 modifications ofthe present invention herein disclosed will occur to persons skilled in the art. All 14 such motlifir~tion.~ are deemed to be within the scope and spirit of the present invention as defined by the appended claims.

AM~NDEC~ SH~E~
.,, . . . ~,

Claims

We claim:

1. A system for determining approval of a transaction between a merchant and a customer over a network, wherein the system comprises:
a network;
a customer computer associated with the customer and connected to the network, wherein the customer computer further comprises a first set of data including an amount the customer agrees to pay a merchant for a product in a first currency;

a merchant computer associated with the merchant and connected to the network, wherein the merchant computer further comprises a second set of data including a product price at which the merchant agrees to sell the product in a second currency; and a server connected to both the customer computer via the network and the merchant computer via the network for receiving the first set of data and the second set of data, for converting the amount in the first currency into a converted amount in the second currency, and for approving the transaction when the converted amount in the second currency is within a risk range of the product price in the second currency in accordance with current exchange rates.

2. The system of Claim 1, wherein the server further comprises a customer balance account associated with the customer, wherein the customer balance account comprises a customer balance in the first currency and wherein the server deducts the amount in the first currency from the balance in the customer balance account.

3. The system of Claim 1, wherein the server further comprises a merchant balance account associated with the merchant, wherein the merchant balance account comprises a balance in the second currency and wherein the server adds the converted amount in the second currency to the balance in the merchant balance account.

4. The system of Claim 1, wherein the first set of data further comprises a plurality of currencies, wherein the server selects a selected currency from the plurality of currencies, which when converted to the converted amount in the second currency, the merchant price is the least expensive.

5. The system of Claim 1, wherein the network is selected from the group consisting of the Internet, an intranet, and a Local Area Network (LAN).

6. A system for determining approval of a transaction between a customer and a merchant over a network, wherein the system comprises:
a network;
a customer computer associated with a customer and connected to the network, wherein the customer computer further comprises a first set of data including an amount the customer agrees to pay to a merchant in a first currency;
a merchant computer associated with a merchant and connected to the network.
wherein the merchant computer further comprises a second set of data including a product price at which the merchant is willing to sell the product to the customer in a second currency; and a server connected to both the customer computer via the network and the merchant computer via the network for receiving the first set of data and the second set of data, for converting the amount in the first currency into a converted amount in the second currency, for approving the transaction when the converted amount in the second currency is within a risk range of the product price in the second currency accordance with current exchange rates, and for recording an insufficiency when the product price in the second currency exceeds the converted amount in the second currency.

7. The system of Claim 6, wherein the server further comprises a customer balance account associated with the customer, wherein the customer balance account comprises a balance in the first currency and wherein the server deducts the amount in the first currency from the balance in the consumer balance account.

8. The system of Claim 6, wherein the server further comprises a merchant balance account associated with the merchant, wherein the merchant balance account comprises a balance in the second currency and wherein the server adds the converted amount in the second currency to the balance in the merchant balance account.

9. The system of Claim 6, wherein the first set of data further comprises a plurality of currencies, wherein the server selects a selected currency from the plurality of currencies, which when converted to the converted amount in the second currency, the product price is the least expensive.

10. The system of Claim 6, wherein the network is selected from the group consisting of the Internet, an intranet, and a Local Area Network (LAN).

11. A system for determining approval of a transaction between a customer and a merchant over a network, wherein the transaction includes the merchant providing a product to the customer at a product price in a second currency, wherein the product price in the second currency is known by the customer, wherein the system comprises:
a network;

a customer computer associated with a customer and connected to the network, wherein the customer computer comprises a first set of data including an amount in a first currency; and a server connected to the customer computer via the network and having the product price in the second currency. for receiving the first set of data, converting the amount in a first currency into a converted amount in the second currency, and for approving the transaction when the amount in the first currency is within a risk range of the product price in the second currency in accordance with current exchange rates.

12. The system of Claim 11, wherein the server further comprises a customer balance account associated with the customer, wherein the customer balance account comprises a balance in the first currency and wherein the server deducts the amount in the first currency from the balance in the consumer balance account.

13. The system of Claim 11, wherein the server further comprises a merchant balance account associated with the merchant, wherein the merchant balance account comprises a balance in the second currency and wherein the server adds the converted amount in the second currency to the balance in the merchant balance account.

14. The system of Claim 11, wherein the first set of data further comprises a plurality of customer currencies, wherein the server selects a customer currency from the plurality of customer currencies, which when converted to the converted amount in the merchant currency, the merchant price is the least expensive.

15. The system of Claim 11, wherein the network is selected from the group consisting of the Internet, an intranet, and a Local Area Network (LAN).

16. A system for determining approval of a transaction between a customer and a merchant over a network, wherein the transaction includes the merchant providing a product to the customer at a product price in a second currency, wherein the product price in the second currency is known by the customer, wherein system comprises:
a network;
a customer computer associated with a customer and connected to the network, wherein the customer computer comprises a first set of data including an amount in a first currency; and a server connected to the customer via the network and having the product price in the second currency, for receiving the first set of data, and for approving the transaction when the amount in the first currency is within a risk range of the product price in the second currency in accordance with current exchange rates.

17. The system of Claim 16, wherein the server further comprises a customer balance account associated with the customer, wherein the customer balance account comprises a balance in the first currency and wherein the server deducts the amount in the first currency from the balance in the consumer balance account.

18. The system of Claim 16, wherein the server further comprises a merchant balance account associated with the merchant, wherein the merchant balance account comprises a balance in the second currency and wherein the server adds the converted amount in the second currency to the balance in the merchant balance account

19. The system of Claim 16, wherein the first set of data further comprises a plurality of customer currencies, wherein the server selects a customer currency from the plurality of customer currencies, which when converter to the converted amount in the merchant currency, the merchant price is the least expensive.

20. The system of Claim 16, wherein when the product price in the second currency exceeds the converted amount in the second currency, the server records the insufficiency.

21. The system of Claim 16, wherein the network is selected from the group consisting of the Internet, an a intranet Area Network (LAN).

22. A method for determining approval of a transaction over a network between a customer having a customer computer connected to the network and a merchant having a merchant computer connected to the network, wherein the customer computer and the merchant computer are connected to a server via the network, wherein the method comprises:
transmitting a first set of data from a customer computer to a server, wherein the first set of data includes an amount in a first currency;
transmitting a second set of data by a merchant computer to the server, wherein the second set of data includes a product price in a second currency;
receiving the first set of data and the second set of data by the server; and approving the transaction by the server when the amount in the first currency is within a risk range of the produce price in the second currency in accordance with current exchange rates.

23. A method for determining approval of a transaction over a network between a customer having a customer computer connected to the network and a merchant having a merchant computer connected to the network, wherein the customer computer and the merchant computer are connected to a server via the network, wherein the method comprises:
transmitting a second set of data from a merchant computer to a customer computer, wherein the second set of data includes a product price in a second currency;
receiving the second set of data by the customer computer, wherein the customer computer has a first set of data including an amount in a first currency;
transmitting the first set of data and the second set of data by the customer computer to a sever; and approving the transaction when the server determines if the amount in the first currency is within a risk range of the product price in the second currency in accordance with current exchange rates.

24. A method for determining approval of a transaction over a network between a customer having a customer computer connected to the network and a merchant having a merchant computer connected to the network, wherein the customer computer and the merchant computer are connected to a server via the network.
wherein the method comprises:
transmitting a first set of data from a customer computer to a merchant computer, wherein the first set of data includes an amount in a first currency;
receiving the first set of data by the merchant computer, wherein the merchant computer has a second set of data including a product price in a second currency;
transmitting the first set of data and second set of data by the merchant computer to a server; and approving the transaction by the server when the amount in the first currency is within a risk range of the product price in the second currency in accordance with current exchange rates.