Patent Publication Number: US-RE44502-E

Title: System and method for multi-currency transactions

Description:
RELATED APPLICATIONS 
     This is a continuation reissue application of U.S. Reissue application Ser. No. 10/390,540 filed Mar. 18, 2003, now U.S. Pat. No. RE41,619, which issued Aug. 31, 2010 as a reissue of U.S. Pat. No. 6,205,433, issued Mar. 20, 2001, which is a continuation of U.S. application Ser. No. 08/663,896 filed Jun. 14, 1996, issued Apr. 27, 1999, now U.S. Pat. No. 5,897,621. The contents of each of these patents are incorporated herein by reference. 
     This application is a continuation of patent application Ser. No. 08/663,896, filed Jun. 14, 1996, now allowed, the disclosure of which is incorporated by reference herein, in its entirety. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of Invention 
     The present invention generally relates to a system and method for approving a transaction over a communications network between a merchant and a customer. More 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 (such as the Internet) and wherein the customer pays for a product using electronic cash in one currency and the merchant receives electronic cash for the product in a different currency. 
     2. Description of the Prior Art 
     Soon, international commerce may be a common experience for almost everyone. This is due, in large measure, to computer networks, including the Internet, which link individuals, consumers, businesses, financial institutions, educational institutions, and government facilities. In fact, the growth in international commerce appears limitless given the forecasts relating to the commercial use of the Internet and the like. 
     There is a problem, however, inherent in international commerce, electronic or otherwise. The problem exists, for the most part, because monetary systems differ from country to country. That is, money is generally expressed in different currencies in different countries and the value of the different currencies vary greatly. Currency conversion is widely used to convert money from one currency into money of a different currency. 
     As used herein, the term “currency” includes, but is not limited to, denominations of script and coin that are issued by government authorities as a medium of exchange. A “currency” also may include a privately issued token that can be exchanged for another privately issued token or government script. For example, a company might create tokens in various denominations. This company issued “money” could be used by employees to purchase goods from merchants. In this case, an exchange rate might be provided to convert the company currency into currencies which are acceptable to merchants. 
     In each instance, currency conversion represents a significant economic risk to both buyers and sellers in international 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 U.S. dollars and the merchant only accepts French francs for the products he sells. The customer uses his credit card to pay the merchant for the product. The merchant receives French francs. 
     Typically, at an undetermined later date, the company issuing the credit card would bill an amount to the customer in U.S. dollars. The amount billed to the customer is determined by an exchange rate used at the time the credit card company settles the transaction. This settlement is often at an indeterminate time and could be on the date of purchase or several days or weeks later. The time of this settlement is at the credit card company&#39;s discretion. The risk to the credit card company is minimal because the credit card company can settle the transaction when exchange rates are favorable. Thus, in this case, it is the customer who bears the risk that the value of the customer&#39;s currency will decline prior to this settlement. 
     As another example, consider a cash transaction where a merchant accepts a currency other than that of his country&#39;s currency. In this case, the merchant sells the currency to a currency trader, usually at a discount. The price the merchant charges to the customer who pays cash reflects both the cost of currency conversion (the discount) and the risk that the rate used to establish the price of the product in a particular currency may have changed. This results in the customer paying a higher price for the product and the merchant incurring risk due to a possible change in currency exchange rates. 
     Thus, the described post sale methods of currency exchange may impart significant risk 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 currency is converted prior to purchasing a product. The merchant sustains the risk when he converts the customer&#39;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. 
     As yet another example, consider the risks that an individual assumes when he converts from the currency of his country (“native currency”) to a different second currency. In this case, the individual can purchase goods at a price in the second currency, but cannot be certain of the value of the second currency relative to his native currency. In this case, the currency exchange has occurred pre-sale. Thus, the individual assumes the risk of devaluation of the second currency against the first currency. Further, the customer bears the risk that the second currency may cease to be convertible into his native currency. 
     It is noted that if the individual desires to purchase an item in a third currency which differs from the native and second currencies, he must undertake at least one additional currency conversion (converting either his native currency to the third currency, the second currency to the third currency, or a combination of both). In this case, the customer assumes an additional risk. 
     The present invention recognizes that international commerce over electronic networks, such as the Internet, cannot reach potential unless customer and merchant obligations relating to transactions are fixed at the time of the transaction so that the risk to these parties associated with currency exchange is minimized Thus, what is needed to encourage the development of international commerce over such networks is a system and method that offers a means of eliminating the uncertainty associated with multi-currency transactions. One aspect of the present invention is the shift of the risk associated with currency exchange from both the merchant and customer to a third party (e.g., a server) in real time. This server may assume the risk itself or may choose to subsequently pass on the risk to a fourth party (e.g., a bank or other financial institution). 
     SUMMARY OF INVENTION 
     The present invention is directed to a system for determining approval of a transaction between a merchant and a customer. The system comprises a customer device (e.g., a computer) associated with the customer. The customer device has a first set of data including an amount in a first currency. The system also has a merchant device (e.g., a computer) associated with the merchant. The merchant device has a second set of data including a product price in a second currency. The system further 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 amount in the first currency is within a risk range of the product price in the second currency in accordance with current exchange rates. 
     Another aspect of the present invention is directed to a system for determining approval of a transaction between a customer and a merchant where the product price is known by the customer. The transaction includes the merchant providing a product price in a second currency. The system comprises a customer device (e.g., a computer) associated with the customer. The customer device has a first set of data including an amount in a first currency. The system also includes a server connected to the customer device. The server is able to access the product price in the second currency, receive the first set of data from the customer device, and can approve 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. 
     Still another aspect of the present invention is directed to a method for determining approval of a transaction between a customer having a customer device (e.g., a computer) and a merchant having a merchant device (e.g., a computer). The customer device and the merchant device are connected to a server. The customer device has a first set of data including an amount in a first currency. The method comprises transmitting a second set of data from the merchant device to the customer device which receives the second set of data from the merchant device. The second set of data includes the product price in a second currency. The method further includes transmitting the first and the second sets of data by the customer device to the server and the server receiving the transmitted first and second sets of data. The server is 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. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       Representative embodiments of the present invention will be described with reference to the following drawings: 
         FIG. 1  is a diagrammatic representation of one aspect of the present invention. 
         FIG. 2  is a diagrammatic representation of another aspect of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Reference is now made to the figures for the purpose of describing, in detail, the preferred embodiments of the present invention. The figures and accompanying detailed description are not intended to limit the scope of the claims appended hereto. 
     The preferred architecture of the present invention is generally depicted in  FIG. 1 .  FIG. 1  shows three entities: a server  100 , a customer computer  200 , and a merchant computer  300 , connected to each other via a network  50 . Network  50  can be a private, public, secure, or an insecure network, such as the Internet, an intranet, and/or a Local Area Network (LAN). In the preferred embodiment, an insecure network, such as, the Internet is used. The connections to network  50  are identified by lines  105 ,  205 , and  305 , respectively, and are well known in the art. 
     Merchant computer  300  represents the computer of an individual, for example, merchant user  303 , who sells products via network  50 . A “product” can include goods, services, information, data, and the like. Customer computer  200  represents the computer of an individual, for example, a customer user  203 , who wants to buy a product (or products) from merchant user  303  over network  50 . The mechanism of delivery of the product is not a part of this patent. Product delivery could be coincident with payment, before payment, or after payment. 
     Server  100  represents a computer of an entity who processes transactions between customer user  203  and merchant user  303 . Server  100  has a database which includes at least one customer account in a first currency associated with customer user  203  and at least one merchant account in a second currency associated with merchant user  303 . The first currency differs from the second currency. 
     In the preferred embodiment, the accounts store electronic funds of the parties, for example, electronic cash. The electronic funds are a representation of funds (real cash, credit, and the like). 
     Server  100  also has its own server accounts. The server accounts are in currencies corresponding to the currencies of the customer and merchant accounts. The server accounts represent real cash, credit, and the like. The server accounts correspond to the electronic funds stored in the customer and merchant accounts. 
     In the preferred embodiment, local accounts are maintained at customer computer  200  and merchant computer  300 . The local accounts represent the electronic funds in the customer account and the merchant account maintained at server  100 , respectively. The local accounts of the customer and the merchant are sometimes referred in the art as “wallets” and “cash registers,” respectively. The server accounts may be arranged with a bank or other financial institution. 
     The following example is used to illustrate how these accounts can be set up: customer user  203  lives in the U.S. and purchases products using U.S. dollars (first currency) and merchant user  303  is located in France and conducts his operations in French francs (second currency). Server  100  includes a customer account in U.S. dollars and a merchant account in French francs. Server  100 , which processes the transactions between these parties, further includes two electronic accounts representing all user accounts whose currencies are in dollars and all user accounts whose currencies are in francs. Server  100  also includes two accounts in a bank with one server account in U.S. dollars and the other server account in French francs. 
     Although the system can operate using an unsecured network  50 , in the preferred embodiment, if network  50  is insecure, measures are taken to assure that server  100 , customer computer  200 , and merchant computer  300  can communicate securely over network  50 . Central to achieving such security while maintaining a high performance payment system is the use of “sessions.” A session is an opportunity (or window) in which customer user  203  may purchase a product from merchant user  303  over the network  50  or which merchant user  303  sells a product to customer user  203  over network  50 . By using a session, a merchant can securely communicate with a customer over an insecure network. Customer user  203  and merchant user  303  each have their own independent sessions. Sessions are of limited duration which is governed by predetermined parameters. In the preferred embodiment, these parameters are set by customer user  203  and merchant user  303 . However, server  100  can set or limit values of such parameters. 
     In the preferred embodiment, the parameters relating to the session of customer user  203  limit an amount of electronic funds (“session amount”), a maximum amount of time that the session can last, and a maximum number of transactions that can be conducted. The session amount is the maximum amount of electronic funds that customer user  203  can spend during the customer&#39;s session. Also in the preferred embodiment, the session of merchant user  303  is limited by a maximum amount of time that the merchant&#39;s session can last and a maximum number of transactions that merchant user  303  can conduct. 
     To accomplish such secure communication over the insecure network, a first session associated with 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 parameters and the set of customer data are identifiable by server  100 . A second session associated with 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 data. The second use parameters and the set of merchant data are identifiable by server  100 . Over the insecure network, a portion of the first session and a portion of the second session are linked. The portion of the first session includes the set of customer data and the first use parameters. The set of customer data may include a customer identification string which identifies customer user  203 . The portion of the second session includes the set of merchant data and the second use parameters. The set of merchant data may include a merchant identification string which identifies merchant user  303 . Server  100  verifies customer user  203  and merchant user  303  based upon at least portions of the set of customer data and the set of merchant data and determines that the first and second sessions can be used. In this manner, confidential details of the payment between customer user  203  and merchant user  303  are assured of being communicated securely. This procedure of establishing secure communication is more fully set forth in co-pending U.S. patent application, Ser. No. 08/572,425, filed on Dec. 14, 1995, and entitled “Electronic Transfer and Method” which is incorporated herein by reference. Of course, other methods and systems for establishing secure communication over an insecure network may be used to use the invention set forth herein. 
     Merchant user  303  and customer user  203  endeavor ultimately to effect a “transaction,” that is, the purchase of a product by customer user  203  from merchant user  303 . Merchant user  303  and customer user  203  do not require any prior existing relationship to transact business. This is so because merchant user  303  and customer user  203  each have a preestablished relationship with server  100  prior to transacting business. 
     How the parties form this relationship is not part of the present invention. Rather, what is important is that the customer and merchant accounts, described above, exist within server  100 . In the preferred embodiment, to form the relationship, customer user  203  provides information using customer computer  200  to server  100 . Such information can include the name of customer user  203  and the currency in which he intends to purchase products. In the case of merchant user  303 , this information can include the name of merchant user  303  and the currency in which merchant user  303  intends to ultimately receive for providing products. Other information can be provided as deemed necessary by server  100 . 
     This relationship may be either direct or indirect. An indirect relationship, for example, would include the situation where one or more entities, previously known to server  100 , vouch for merchant user  303  and/or customer user  203 . Public key cryptographic systems are generally used in this type of vouching process and are well known to those skilled in the art. The process of using public key cryptographic systems as such is known in the art as “certificate management.” In this case, vouching entities are known as “certificate authorities.” Certificates, certificate management, and certificate authorities are well known in the art and are used by but are not the subject of the present invention. 
     The present invention is directed toward “approval” of a multi-currency transaction in which customer user  203  pays in a first currency and merchant user  303  accepts the payment in a second currency which differs from the first currency, rather than the completed transaction itself. As will be described below, approval commits customer user  203  and merchant user  303  to the terms of the transaction and commits server  100  to perform virtual settlement of the transaction. 
     As used herein, “virtual settlement” of the transaction represents at least the movement of electronic funds to a merchant account of merchant user  303  held by server  100 . It can also represent the movement of electronic funds from a customer account of customer user  203  held by server  100 . This is to be distinguished from actual settlement of the transaction. As used herein, “actual settlement” of the transaction includes at least converting real funds in an amount equal to the amount in the first currency into real funds in the second currency. 
     The parties are committed because of pre-existing bilateral contractual obligation between customer user  203  and the operator of server  100  and between merchant user  303  and the operator of server  100 . The contractual obligations are preferably formed during the commencement of service relationship between server  100  and customer user  203  and merchant user  303  respectively. 
     The obligations can include the agreement of customer user  203  and merchant user  303  to permit server  100  to perform virtual settlement of the transaction. In return, server  100  can agree to incur the risks associated with currency exchange when it performs actual settlement of the transaction. In the preferred embodiment, customer user  203  and merchant user  303  agree to allow server  100  (on behalf of the operator of server  100 ) to maintain accounts and balances of funds managed by server  100 . In addition, in the preferred embodiment, the movement of funds between those accounts is coincident with the transaction. 
     In this way, customer user  203  knows substantially the amount in the currency customer user  203  will pay for the product. Similarly, merchant user  303  knows substantially the price in the currency merchant user  303  will receive for the product. Customer user  203  and merchant user  303  do not bear the above-described risks associated with currency exchange. The amount customer user  203  knows and the price merchant user  303  knows is substantially the respective amount and price because there may be minor factors that affect these actual values. Such factors will be discussed in terms of risk factors. The entity charged with performing actual settlement of the transaction bears such risks when the transaction is actually settled. 
     The present invention is directed to approval of multi-currency transactions in which customer user  203  pays in one currency and merchant user  303  accepts the payment in another currency. To transact business, customer user  203  shops over network  50  among merchant users  303  who also have been permitted by server  100  to transact business (which may be, for example, those who have merchant sessions). Using well known techniques, customer user  203  and a merchant user  303  agree on a product to be purchased at a particular price and in a particular currency. 
     Thus, merchant user  303  will accept a price and receive payment for the product sold to customer user  203 . The price for the product is in a currency accepted by merchant user  303 , referenced herein as the “product price in the second currency.” Customer user  203  will pay an amount to merchant user  303  for a selected product. The amount will be paid in a currency selected by customer user  203 , referenced herein as the “amount in the first currency.” The currency (second) selected by merchant user  303  is different than the currency (first) selected by customer user  203 . Hence, currency exchange is used to approve the transaction contemplated by the present invention. 
     In a first embodiment of the present invention, server  100  is used to approve the transaction between customer user  203  and merchant user  303 . As stated previously, approval commits customer user  203  and merchant user  303  to the terms of the transaction and commits server  100  to perform virtual settlement of the transaction. 
     In this embodiment, customer user  203  and merchant user  303  have established and agreed upon a product to be purchased at a price merchant user  303  will accept. This product and price are referred to herein as the “agreed product” and the “agreed price,” respectively. 
     Having agreed upon the product and the price, customer computer  200  transmits a first set of data to server  100 . This first set of data includes the amount in a first currency that customer user  203  is willing to pay for the agreed product. The transmitted amount is in the customer selected currency which is in a first currency. Other information may be transmitted by customer computer  200  as needed by server  100 , for example, a requested payment range (described later), information identifying customer user  203 , the product to be purchased, account information, and the like. 
     Having agreed upon the product and the price, merchant computer  300  transmits a second set of data to server  100 . This second set of data includes the agreed price in a second currency that merchant user  303  is willing to receive for his product. The transmitted agreed price is in the merchant accepted currency which is in a second currency. Other information may be transmitted by the merchant computer  300  as needed by server  100 , for example, information identifying merchant user  303 , the product to be purchased, account information, and the like. As previously stated, the customer selected currency (first currency) is different than the merchant accepted currency (second currency). 
     In a further aspect of the preferred embodiment, along with providing the amount in the first currency, customer computer  200  also transmits the agreed price in the second currency to server  100 . This assures that customer user  203  and merchant user  303  have actually reached agreement on the terms of the transaction and precludes either party from denying such agreement. 
     The system does not require that merchant user  303  know or approve the customer selected currency, that is, the currency in which customer user  203  will pay. There is no requirement that customer user  203  approve the merchant accepted currency, that is, the currency which merchant user  303  will receive. What is required is that server  100  be able to convert one such currency into the other. 
     However, it is noted that by not requiring “approval” of a currency by merchant user  303  and/or customer user  203  is distinguishable from the approval of a “transaction” by server  100 . Approval of a currency would be, for example, where customer user  203  would need the permission of merchant user  303  to pay in a given customer selected currency. Approval of transaction, on the other hand, commits customer user  203  and merchant user  303  to the terms of the transaction and commits server  100  to perform virtual settlement of the transaction. The present invention does not require approval of a currency. 
     The first and second sets of data transmitted to server  100  need not come directly from customer computer  200  and merchant computer  300 . This information may be transmitted via alternative routes. For example, in the preferred embodiment, customer computer  200  transmits the first set of data to the merchant computer  300 . Upon receipt of the first set of data, merchant computer  300  transmits at least the amount in the first currency and the second set of data including the product price in the second currency to server  100  for approval of the transaction. In this case, the first set of data may be protected to prevent the merchant from altering it. 
     Upon receiving the amount in the first currency and the product price in the second currency, server  100  can approve the transaction. The approval process performed by server  100  is based upon the relative value of the amount in the first currency in terms of the product price in the second currency. This relative value may be established by the operator of server  100 , a third party, or in other aspects of the present invention, customer user  203  or merchant user  303 . This preferably includes a rate of exchange at which the amount in the first currency can be converted into a converted amount in the second currency. Alternatively, or in addition, this information may include a rate at which the merchant accepted currency can be converted into the customer selected currency. 
     Approval of the transaction occurs when the amount in the first currency is sufficient to pay merchant user  303  the product price in the second currency. The sufficiency determination process preferably includes converting the amount in the first currency into a converted amount in the second currency, referenced herein as the “converted amount in the second currency,” using a current exchange rate. 
     In the preferred embodiment, the current exchange rate data is maintained by the entity charged with approving the transaction. Thus, in this embodiment, server  100  may obtain the exchange rate 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 the approving entity&#39;s own exchange rates. In addition, as server  100  has the opportunity to aggregate transactions prior to committing to actually exchange currency with an external agency, the approving entity may obtain preferential exchange rates by converting money in relatively large units. 
     The frequency that the current exchange rate data is updated depends upon the level of risk that the approving entity may be willing to accept and the availability of updates from currency brokerage services. In the preferred embodiment, when server  100  is the approving entity, server  100  receives updates to the exchange rate data on-line from one or more currency brokers. Frequency and timing of updates are based on business rules agreed between the operator of server  100  and the currency broker or brokers. This manages the risk of a significant change between the current exchange rate and the exchange rate used when the transaction is actually settled. 
     Approval of the transaction by server  100  is preferably based upon predetermined criteria. These criteria may be established by any of the parties to the transaction or a third party. For example, in the preferred embodiment server  100  approves the transaction if the converted amount in the second currency equals or exceeds the product price in the second currency. 
     Alternatively, server  100  could approve the transaction if the converted amount in the second currency is less than the product price in the second currency. In this instance, server  100  may absorb differentials (as where the cost associated with disapproving the transaction and reprocessing it exceeds the differential). Acceptable differentials may be dependent upon the credit worthiness of customer user  203  or merchant user  303 , the acceptable deficit balance that customer user  203  or merchant user  303  are allowed to incur, or other market conditions such as, for example, fluctuations in exchange rates. These acceptable differentials are referred to with respect to each party of the transaction as a “risk range.” 
     Also, in the case where the converted amount in the second currency is less than the product price in the second currency, but within a predetermined range, server  100  could record the differentials as they occur and collect them from customer user  203  at a later time. This range is contemplated as being a small range and is referred to herein as the “payment range.” The payment range may be predetermined by customer user  203  or preferably, by server  100 . For the purpose of this application, the amount in the first currency is equal to the amount in the first currency plus or minus the payment range. The payment range thus defines the amount of conversion error permitted in the transaction. 
     Approval of the transaction may also be contingent upon customer user  203  having access to electronic funds in an amount equal to or exceeding the amount in the customer selected currency (ACSC). These funds maybe stored or represented in a customer account associated with customer user  203 . In this case, server  100  approves the transaction when the converted amount in the second currency meets the predetermined criteria described above and the customer account contains electronic funds in an amount at least equal to the amount in the first currency. Using any of the above methods for approval, alone or in combination, server  100  approves the transaction. 
     In order to avoid having to access the customer account of customer user  203  and for security reasons, it is preferred to limit the amount in the first set of data that a customer user  203  can transmit to server  100  by the session amount. The session amount is an amount known by server  100  to which the customer has access when customer user  203  is permitted to shop. The limited amount is reduced as customer user  203  purchases products over network  50 . Customer computer  200  temporarily prohibits customer user  203  from transmitting an amount exceeding the session amount to server  100  to be considered for sufficiency until more electronic funds are added to the session in which case the session amount has been increased. 
     In the preferred embodiment, under such circumstances, the existing session will automatically close and a new session will be opened with funds at least sufficient to complete the transaction. Once the subsequent session is opened, the transaction may be approved. Of course, if server  100  determines that customer user  203  does not have enough funds available to it to open a subsequent session of sufficient value, the transaction may be refused by server  100  altogether or server  100  may approve the transaction as described herein. 
     In the preferred embodiment, the funds that are available to customer user  203  during the session and the funds received by merchant user  303  during the session be maintained to two decimal positions to the right of the minor unit of a currency. For example, in the case of U.S. dollars, the present invention preferably would carry the value of session funds to one hundredth of a penny to assure that rounding errors are minimized during a session, thus decreasing rounding errors during currency conversion of small transactions. When a session closes, the balance in the session is adjusted to whole minor currency units (this adjustment may be rounding or truncation). 
     Once the transaction is approved, customer user  203  and merchant user  303  are committed to the terms of the transaction. Specifically, customer user  203  is committed to pay the amount in the first currency. Similarly, merchant user  303  is committed to accept the product price in the second currency for the product. The parties are committed as such through the contractual arrangement previously described. 
     By the contractual obligations described above, server  100  is committed to perform virtual settlement of the transaction. Therefore, according to this aspect of the present invention, a customer account may be maintained for customer user  203  and a merchant account may be maintained for merchant user  303 . The customer accounts and merchant accounts are preferably maintained by server  100 . However, one or both of the accounts may be maintained by a party other than server  100 . 
     The customer account and merchant account maybe debit or credit accounts. In the preferred embodiment, the customer account is a debit account and the merchant account is a credit account and each such account represent funds in the form of electronic funds. However, other types of accounts may be used as known by those skilled in the art. 
     In the case where a party other than server  100  maintains a merchant account and/or a customer account, server  100  may transmit data to the party to enable virtual settlement. For example, if the other party maintains the customer account and the merchant account, server  100  may transmit data identifying the customer account and the amount in the first currency to be debited, and the merchant account and the product price in the second currency to be credited. Then, the party would debit the customer account and credit the merchant account accordingly. 
     In this process, upon approval of the transaction, the customer account is debited by the amount in the first currency. The merchant account is credited with the agreed price in the second currency. This amount and price were known by and agreed to by customer user  203  and merchant user  303 . Thus, there is no uncertainty 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 . 
     Several variations on the above described embodiment provides that the currency used in the first currency may be selected by customer user  203  (or server  100 ) from a plurality of currencies, referred to herein as “customer currencies.” Also, the currency used in the merchant accepted currency may be selected by customer user  203  from a plurality of currencies, referred to herein as “merchant currencies.” A description of these variations is now provided. 
     A customer user  203  may have access to amounts in a plurality of customer currencies. For example, a customer user  203  may have accounts containing amounts in U.S. dollars, French francs, and Japanese yen. Customer user  203  can purchase products using amounts from any of these accounts. To effect this option, customer computer  200  presents an amount in each of the plurality of customer currencies to customer user  203 . This is done using exchange rate data for each customer currency to convert the merchant accepted currency into amounts in each of the customer currencies. In the preferred embodiment, the exchange rate data is provided to customer computer  200  by server  100  at various times. Other mechanisms for obtaining such data include the use of brokers. Customer user  203  selects an amount in one of the plurality of customer currencies in which the customer user  203  will spend for the product. This selected amount represents the amount in the first currency described previously and is referred herein as the “selected currency.” 
     In the above description, the method by which customer computer  200  determines the amount of customer currency to pay for a purchase in the merchant computer  300 &#39;s currency is omitted. While there are a number of ways to enable this conversion, in the preferred embodiment, prior to the inception of the customer computer  200 &#39;s session, customer computer  200  requests exchange rate data. This data will contain at least conversion rates from the session currency to other convertible currencies, it may also contain additional data such as anticipated expiration of the exchange rates. These rates are used by customer computer  200  to estimate the amount of customer currency to pay for a purchase in merchant currency. As conversion rates may change rapidly, in the preferred embodiment, this data is advisory only. Server  100  can send updated data to customer computer  200  during any communication between them. The implication of this decision is that if customer computer  200  pays insufficient funds to convert, it is viewed as a natural error due to obsolete data, not an attempt to defraud. 
     This aspect of the present invention can further include an optimization feature. The optimization feature is preferably executed by customer computer  200  to determine whether it is advantageous for customer user  203  to pay in one customer currency over another. 
     More specifically, customer computer  200  determines the agreed price in the merchant accepted currency corresponding to the amount in each of the plurality of customer currencies. For example, assume merchant user  303  will receive a price in currency C for the product and customer user  203  has two customer currencies A and B available to pay merchant user  303 . Customer computer  200  determines amounts in currencies A and B which equate to the product price in currency C. These amounts may be compared by converting them to a reference currency of the customer computer  200 &#39;s choice. Customer user  203  can choose (or customer computer  200  can be programmed to choose) to pay the agreed price in the currency (A or B) which corresponds to the lesser amount in the reference currency. The amount in the chosen currency represents the amount in the first currency and is referred herein as the “selected currency.” 
     According to another variation to this optimization feature, customer computer  200  can also determine whether it is less expensive to first convert currency A into currency B, and then to convert currency B into currency C. In any case, customer user  203  pays using the optimal payment currency. This preferred mode reduces complexity of currency exchange to customer user  203  without reducing the options available to customer user  203 . 
     In another embodiment, server  100  can execute an optimization feature. In this case, server  100  may include the plurality of customer currencies available to customer user  203 . For example, data indicating the plurality of customer currencies may be transmitted in the first set of data from customer computer  200  to server  100  in lieu of the amount in the first currency. In a manner similar to that described above, server  100  determines the agreed amount in the second currency for each of the plurality of customer currencies. Server  100  then chooses an amount in one of the customer currencies corresponding to the amount in the merchant accepted currency which is the least when converted to the reference currency. The amount in the chosen currency represents the amount in the first currency. 
     In another embodiment of the present invention, it is expected that a merchant user  303  may desire to transact business in more than one currency. Therefore, merchant user  303  will accept a price for the product in one of a plurality of merchant currencies. Merchant computer  300  communicates the agreed price for the product in each of the merchant currencies to customer computer  200 . Customer computer  200  presents the agreed price in each of the merchant currencies to customer user  203 . Customer user  203  selects the agreed price in one of the merchant currencies that merchant user 303  will accept. This selected currency maybe recommended by the optimization procedure described above. This selected price represents the product price in the merchant accepted currency (PMAC), although it is actually selected by customer user  203 . 
     According to a variation to this optimization feature, customer computer  200  may also determine which customer currency - merchant currency pair represents the best value to customer user  203 . This is accomplished by customer computer  200  using exchange rate data to convert the price of the product in each merchant accepted currency into each of the customer currencies and selecting the lowest value among the results. For example, if customer user  203  has access to currencies A, B, C and merchant user  203  is willing to accept currencies y and z, customer 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. Whichever of these conversions yields the lowest cost to customer user  203  is the optimal customer currency merchant currency pair for customer currency A. This process is repeated until an optimal currency pair is computed for each customer currency. For example, this process may yield the following results: A to y, B to y, and C to z. 
     The next step is to decide which of these currency pairs represents the best value to customer user  203 . In the preferred embodiment, this is accomplished by converting each customer currency to a single reference currency. The conversion that yields the smaller number is identified as the “best” choice and is displayed to customer user  203 . Clearly, other approaches to determining the optimum currency can be devised by those skilled in the art. 
     Another embodiment of the present invention, as shown in  FIG. 2 , again uses server  100  to approve the transaction between customer user  203  and merchant user  303 . However, the merchant computer need not be connected to network  50  according to this aspect of the invention. 
     More particularly, in this embodiment, customer user  203  has knowledge about the product that merchant user  303  is providing and the price in the merchant selected currency for the product before submitting the first set of data to server  100 . This knowledge need not be gained while customer user  203  shops over network  50 . For example, merchant user  303  can have distributed catalogs to customer user  203  (via regular mail, email, etc.) illustrating products, prices, and currencies therefor. Server  100  would receive the same information, that is, data representing the same products, prices and currencies from merchant user  303 . This data may be received by server  100  electronically over network  50  or by some other means. For example, merchant user  303  might provide the data representing the products, prices and currencies therefor via a network to which customer computer  200  is not connected or by mail on a diskette. However received, this data would be accessible by server  100 . 
     After viewing the catalog, customer user  203  may purchase a product over network  50 . In this case, customer computer  200  transmits to server  100  a description of a desired product (e.g., model number) and an amount in the first currency for the desired product. 
     Server  100  thus has access to data indicating the amount in the first currency which customer user  203  is willing to pay for a product and the product price in the second currency which merchant user  303  is willing to accept for the product. With this data, server  100  approves the transaction as indicated above. 
     In any of the foregoing embodiments, notice of approval of the transaction may be provided by server  100  to customer user  203  and merchant user  303  For example, server  100  may transmit data indicating approval to the merchant computer  300 . After merchant computer  300  receives the data indicating approval, merchant computer  300  may transmit at least a portion of the data indicating approval to customer computer  200 . In a similar manner, data indicating approval may be communicated from server  100  to customer computer  200 , which, in turn, would forward this data to merchant computer  300 . In this manner, customer user  203  and merchant user  303  may be informed that the transaction was approved. 
     Alternatively, server  100  may separately transmit data indicating approval to customer computer  200  and merchant computer  300 . In yet another embodiment, the absence of notice from server  100  maybe deemed as affirmative notice that the transaction was approved. According to any of these procedures, or other preestablished procedures, notice may be provided to the participants in the transaction. Further, once notice of approval is provided, the product which is the subject of the transaction may be provided to customer user  203  and the payment of the funds corresponding to the agreed price will be received by merchant user  303  in the merchant accepted currency. 
     Actual settlement may occur contemporaneously with the approval of the transaction or it may be deferred. As is described below, it is the entity charged with performing the actual settlement who bears the risk. 
     In the preferred embodiment, server  100  performs actual settlement of the transaction. Therefore, according to this aspect of the present invention, server  100  also has its own server accounts. Server accounts are in currencies corresponding to the currencies of the customer and merchant accounts. Server accounts represent real cash, credit, and the like, corresponding to the electronic funds stored in the customer and merchant accounts. 
     To perform actual settlement, server  100  may transmit data to a currency broker, bank or financial institution to enable actual settlement. For example, server  100  may transmit data identifying server account and the amount in the first currency so that the entity can convert real funds in an amount equal to the amount in the customer selected currency into real funds in the second currency. 
     In the preferred embodiment, server  100  aggregates the amounts in each currency before settling. This may decrease the number of actual conversions that must be made from possibly hundreds per second to a few times per hour (or day). The frequency may vary depending on the volatility of the currency exchange market and on the relative currency balances in server  100 &#39;s various currency accounts. 
     Note that server  100  is bound even if the later currency exchange rates are or become unfavorable to server  100  as compared to the current exchange rates used during the virtual settlement. By eliminating the risk to customer user  203  and merchant user  303 , such risk is passed to server  100 . 
     In the preferred embodiment, measures are taken to manage the risk associated with the currency exchange to server  100 . For example, server  100  can have a preestablished agreement with the bank or financial institution. The terms of such an agreement might include a commitment on the part of server  100  to settle transactions within a predetermined amount, time, and/or within a predetermined currency rate deviation. The predetermined amount of time may be on the order of several seconds or minutes. 
     In the preferred embodiment, during this predetermined amount of time, server  100  aggregates transactions and submits them in batch for exchange. In return for server  100 &#39;s commitment, the entity may offer server  100  a favorable currency exchange rate. 
     It is seen from the above detailed description that customer and merchant obligations relating to multi-currency transactions can be fixed at the time of the transaction. In this manner, risks to these parties heretofore associated with currency exchange is minimized. To this end, the parties to a multi-currency transaction authorize an approving entity to settle the transaction. Authorization is granted by virtue of customer user  203  and merchant user  303  setting up their respective accounts, knowing that transactions will be submitted and processed. The parties transmit data representing the transaction to the approving authority. This data includes an amount in a first currency that a customer user  203  is willing to pay for a product and a product price in a different second currency which a merchant user  303  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 actually settle the transaction at its discretion thereby bearing the risk associated with currency exchange. The parties, however, incur no risk. Customer user  203  will pay the amount in the first currency and merchant user  303  will receive the product price in the second currency. These are values known and agreed to by the parties at the time of the transaction. 
     An alternate method of managing risk for extremely volatile currencies, server  100  may choose to withdraw a currency or currencies from the list of convertible currencies. 
     Although the particular embodiments shown and described above will prove to be useful in many applications relating to the arts to which the present invention pertains, further modifications of the present invention herein disclosed will occur to persons skilled in the art. All such modifications are deemed to be within the scope of the present invention as defined by the appended claims.