CA2276243A1 - System and method for generating and executing insurance policies for foreign exchange losses - Google Patents
System and method for generating and executing insurance policies for foreign exchange losses Download PDFInfo
- Publication number
- CA2276243A1 CA2276243A1 CA002276243A CA2276243A CA2276243A1 CA 2276243 A1 CA2276243 A1 CA 2276243A1 CA 002276243 A CA002276243 A CA 002276243A CA 2276243 A CA2276243 A CA 2276243A CA 2276243 A1 CA2276243 A1 CA 2276243A1
- Authority
- CA
- Canada
- Prior art keywords
- receiving
- user
- transaction
- policy
- foreign exchange
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
Abstract
A system (200, 300, 400, 410, 420, 430, 440, 450, 460) and method for providing foreign exchange insurance policy (60) that automatically considers factors such as the type of currency (630), exchange rate (640), amount of coverage (660), and period of coverage (650), to determine a premium (730).
Users can access the system (200, 300, 400, 410, 420, 430, 440, 450, 460) using credit cards, ATMs (440), banks (460) or other media.
Users can access the system (200, 300, 400, 410, 420, 430, 440, 450, 460) using credit cards, ATMs (440), banks (460) or other media.
Description
o _ SYSTEM AND METHOD FOR GENERATING AND EXECUTING INSURANCE
POLICIES FOR FOREIGN EXCHANGE LOSSES
BACKGROUND OF THE INVENTION
The present invention relates generally to foreign currency exchange, and more particularly to generating and executing insurance policies for foreign exchange losses.
Rapidly expanding global commerce and international travel have dramatically increased the need for foreign currency exchange. Foreign exchange rates are highly variable, and numerous factors influence the exchange rates, such as economic strength of countries, political stability, countries' transnational policies and relationships, and demand for foreign currency. Due to high variability and numerous factors influencing the exchange rates, it is extremely difficult to predict future exchange rates even for a short period.
Due to the unpredictable nature of the exchange rates, individual travelers may wish to lock in a favorable exchange rate before they travel to foreign countries, thus eliminating the need to purchase foreign currencies in advance. One way to protect against unpredictable fluctuation of exchange rates are forward currency contracts. These contracts give the buyer a right to purchase a certain amount of foreign currency at a specific price at a specific future time. Essentially, the buyer of the contract pays a premium for the right to purchase a large block of foreign currency at a fixed exchange rate.
Unfortunately, forward currency contracts involve large sums of money, and thus, are practical only for large institutions and international companies seeking to minimize currency exchange risks, or commercial currency traders. The size of forward currency contracts generally does not vary, nor can they be shared by a group
POLICIES FOR FOREIGN EXCHANGE LOSSES
BACKGROUND OF THE INVENTION
The present invention relates generally to foreign currency exchange, and more particularly to generating and executing insurance policies for foreign exchange losses.
Rapidly expanding global commerce and international travel have dramatically increased the need for foreign currency exchange. Foreign exchange rates are highly variable, and numerous factors influence the exchange rates, such as economic strength of countries, political stability, countries' transnational policies and relationships, and demand for foreign currency. Due to high variability and numerous factors influencing the exchange rates, it is extremely difficult to predict future exchange rates even for a short period.
Due to the unpredictable nature of the exchange rates, individual travelers may wish to lock in a favorable exchange rate before they travel to foreign countries, thus eliminating the need to purchase foreign currencies in advance. One way to protect against unpredictable fluctuation of exchange rates are forward currency contracts. These contracts give the buyer a right to purchase a certain amount of foreign currency at a specific price at a specific future time. Essentially, the buyer of the contract pays a premium for the right to purchase a large block of foreign currency at a fixed exchange rate.
Unfortunately, forward currency contracts involve large sums of money, and thus, are practical only for large institutions and international companies seeking to minimize currency exchange risks, or commercial currency traders. The size of forward currency contracts generally does not vary, nor can they be shared by a group
- 2 -o -of individuals. Additionally, there is little or no flexibility in specifying a range of coverage because forward currency contracts must designate a specific date.
Accordingly, not only are these options restrictive, they do not offer avenues for individual consumers to hedge their personal currency risk. Instead, if individuals want to "lock in" a prevailing exchange rate, they must either purchase the foreign currency or an instrument denominated in the foreign currency, such as traveler's checks. The actual purchase, however, poses any disadvantages such as tying up funds, paying a commission, and foregoing the possibility of enjoying any favorable future fluctuations.
Therefore, it is desirable to provide a method of protecting individual consumers against unpredictable fluctuations of foreign exchange rates.
It is also desirable to offer a more flexible method for large entities to ensure against currency fluctuations.
It is further desirable to provide a method of foreign currency exchange rate protection through commonly accessible means such as credit cards or ATMs.
SUN~1ARY OF THE INVENTION
Accordingly, the present invention involves generating and executing insurance policies for foreign exchange losses that substantially obviate one or more of these limitations by automatically determining an appropriate premium, and processing transactions under the foreign exchange insurance policies.
Specifically, a method of providing a foreign exchange insurance policy consistent with this invention comprises a central controller receiving policy requirements from a user for the foreign exchange insurance policy; storing the policy requirements and the corresponding user id; accessing data corresponding to the specified currency and current market conditions;
WO 9$/21680 PCT/US97/20754
Accordingly, not only are these options restrictive, they do not offer avenues for individual consumers to hedge their personal currency risk. Instead, if individuals want to "lock in" a prevailing exchange rate, they must either purchase the foreign currency or an instrument denominated in the foreign currency, such as traveler's checks. The actual purchase, however, poses any disadvantages such as tying up funds, paying a commission, and foregoing the possibility of enjoying any favorable future fluctuations.
Therefore, it is desirable to provide a method of protecting individual consumers against unpredictable fluctuations of foreign exchange rates.
It is also desirable to offer a more flexible method for large entities to ensure against currency fluctuations.
It is further desirable to provide a method of foreign currency exchange rate protection through commonly accessible means such as credit cards or ATMs.
SUN~1ARY OF THE INVENTION
Accordingly, the present invention involves generating and executing insurance policies for foreign exchange losses that substantially obviate one or more of these limitations by automatically determining an appropriate premium, and processing transactions under the foreign exchange insurance policies.
Specifically, a method of providing a foreign exchange insurance policy consistent with this invention comprises a central controller receiving policy requirements from a user for the foreign exchange insurance policy; storing the policy requirements and the corresponding user id; accessing data corresponding to the specified currency and current market conditions;
WO 9$/21680 PCT/US97/20754
- 3 -o w estimating currency volatility from the accessed data; and computing a premium cost based on the currency volatility.
The received policy requirements further include the specified currency, exchange rate, amount of coverage, and a period of coverage.
According to another aspect of the present invention, a system for providing a foreign exchange insurance policy consistent with this invention comprises receiving means) a database, accessing means, estimating means, and computing means. The receiving means receives policy requirements from a user for the foreign exchange insurance policy, including a user id, a specified currency, exchange rate, amount of coverage, and a period of coverage. The database stores the policy requirements and the corresponding user id. The accessing means access data including historic exchange rates corresponding to the specified currency and current market conditions. The estimating means estimates currency volatility from the accessed data. Finally, the computing means computes a premium cost based on the currency volatility.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate the invention and together with the description, serve to explain the principles of the invention.
Fig. 1 is a block diagram of a system consistent with the present invention;
Fig. 2 is a detailed block diagram of the central controller in Fig. 1;
' 30 Fig. 2A-2C are tables illustrating the data structure of the databases;
' Fig. 3 is a block diagram of another system consistent with the present invention using credit cards;
Fig. 4 is a block diagram of yet another system consistent with the present invention using automatic
The received policy requirements further include the specified currency, exchange rate, amount of coverage, and a period of coverage.
According to another aspect of the present invention, a system for providing a foreign exchange insurance policy consistent with this invention comprises receiving means) a database, accessing means, estimating means, and computing means. The receiving means receives policy requirements from a user for the foreign exchange insurance policy, including a user id, a specified currency, exchange rate, amount of coverage, and a period of coverage. The database stores the policy requirements and the corresponding user id. The accessing means access data including historic exchange rates corresponding to the specified currency and current market conditions. The estimating means estimates currency volatility from the accessed data. Finally, the computing means computes a premium cost based on the currency volatility.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate the invention and together with the description, serve to explain the principles of the invention.
Fig. 1 is a block diagram of a system consistent with the present invention;
Fig. 2 is a detailed block diagram of the central controller in Fig. 1;
' 30 Fig. 2A-2C are tables illustrating the data structure of the databases;
' Fig. 3 is a block diagram of another system consistent with the present invention using credit cards;
Fig. 4 is a block diagram of yet another system consistent with the present invention using automatic
- 4 -o -teller machines (ATMs);
Fig. 5 is a block diagram of still another system consistent with the present invention using banks;
Fig. 6 is a flowchart illustrating a preferred process for selecting policy requirements;
Fig. 7 is a flowchart illustrating a preferred process for calculating an insurance premium;
Fig. 8 is a flowchart illustrating a preferred process for creating the insurance premium for the user;
Fig. 9 is a flowchart illustrating a preferred process for system maintenance of active insurance policies;
Fig. 10 is a flowchart illustrating a preferred process for transmitting transaction data using credit cards;
15 Fig. 11 is a flowchart illustrating a preferred process for determining whether an insurance adjustment is necessary for the process of Fig. 10;
Fig. 12 is a flowchart illustrating a preferred process for calculating the amount of the insurance 20 adj us tment ;
Fig. 13 is a flowchart illustrating a preferred process for transmitting transaction data using ATMs;
Fig. 14 is a flowchart illustrating a preferred process for determining whether an insurance adjustment is 25 necessary for the process of Fig. 13;
Fig. 15 is a flowchart illustrating a preferred process for calculating the amount of the insurance adjustment for the process of Fig. 13;
Fig. 16 is a flowchart illustrating a preferred 30 process for transmitting transaction data using banks;
Fig. 17 is a flowchart illustrating a preferred process for determining whether an insurance adjustment is necessary for the process of Fig. 16;
Fig. 18 is a flowchart illustrating an 35 authentication procedure using symmetric key protocols;
_ 5 _ o -and Fig. 19 is a flowchart illustrating an authentication procedure using public key protocols.
DETAILED DESCRIPTION
Reference will now be made in detail to the present preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings.
System Architecture As shown in Fig. 1, a system consistent with the present invention includes a central controller 200, an end-user interface 300, and a transaction interface 400.
The elements preferably connect to each other via a public switched telephone network. Alternatively, the system elements may be connected by dedicated data lines, cellular, Personal Communication Systems ("PCS~~), 15 microwave, satellite networks, Internet, or any other suitable form of data communications. Policy requirements 50, insurance policy 60, and transaction data 70 travel through these connections.
Fig. 2 shows a detailed block diagram of central 20 controller 200 shown in Fig. 1. Central controller 200 preferably includes a central processor unit (CPU) 205, a cryptographic processor 210, a random access memory (RAM) 215, a read-only memory (ROM) 220, an Interactive Voice Response Unit (IVRU) 225, a payment processor 230, a clock 25 235, an operating system 240, a network interface 245, and a data storage device 250. All of these elements are connected to CPU 205 to facilitate communication between them.
Central controller 200 operates as a primary 30 server, both receiving and transmitting communications with end-user interface 300 and transaction interface 400.
Central controller 200 is preferably capable of high volume processing, performing a significant number of mathematical calculations in processing communications and 35 database searches. Central controller 200 may be a o -conventional personal computer or a computer workstation with sufficient memory and processing capability. For example, a Pentium microprocessor such as the 100 MHZ
P54C, commonly manufactured by Intel, Inc., may be used for CPU 205. This processor employs a 32-bit architecture. Equivalent processors include the Motorola 120 MHZ PowerPC 604 or Sun Microsystems 166 MHZ
UltraSPARC-I.
Cryptographic processor 210 supports the encoding and decoding of communications as well as the authentication of transactions. A MC68HC16 microcontroller, commonly manufactured by Motorola, Inc., may be used for cryptographic processor 210. This microcontroller uses a 16-bit multiply-and-accumulate instruction in a 16 MHZ configuration and requires less than one second to perform a 512-bit RSA private key operation. One skilled in the art may easily substitute other commercially available, specialized cryptographic processors such as VLSI Technology's 33MHZ 6868 or Semaphore Communications' 40 MHZ Roadrunner284.
Alternatively, cryptographic processor 210 may be configured as part of CPU 205.
Operating system 240 comprises a conventional operating system such as DOS, Windows, or OS2.
Payment processor 230 supports the transfer and exchange of payments, charges, or debits. Exemplary services operable on payment processor 320 include on-line credit authorizations, credit card settlement, payments to transaction networks, and payment aggregation.
Commercially available software, such as the Secure Webserver manufactured by Open Market, Inc., may support credit card transaction processing of payment processor 230. This server software transmits credit card numbers electronically over the Internet to servers located at the Open Market headquarters, which handles card verification and processing. The Open Market's Integrated Commerce _ 7 _ o -Service provides back-office services necessary to run Web-based businesses. Payment processor 230 preferably comprises a microprocessor (such as the Intel Pentium), but alternatively may be configured as part of CPU 205.
Operating system 240 comprises a conventional operating system such as DOS, Windows, or OS2.
Data storage device 250 may include a hard magnetic disk, optical storage units, CD-ROM drives, or flash memory. Data storage device 250 contains databases used in processing transactions in the present invention, including an end-user database 255, a policy requirements database 260, an insurance policy database 265, a transaction data database 270, an exchange rate database 275, an exchange rate volatility database 280, a payment database 285, an end-user account database 290, and cryptographic key database 295. In a preferred embodiment, database software such as Oracle7, manufactured by Oracle Corporation, creates and manages these databases.
End-user database 255 maintains data about end users and, in one embodiment, includes fields such as name, address, credit card number, phone number, ID
number, social security number, electronic mail address, and public/private key information. This information is preferably obtained when the end user first generates insurance policy 60 on the system. End-user database 255 also contains the tracking number of each insurance policy 60 generated by the end user.
As shown in Fig. 2A, policy requirements database 260 maintains data on policy requirements generated by the end user, and preferably includes fields such as end-user ID, credit card number, currency selected, exchange rate, start date of coverage, end date of coverage, and amount of coverage, and policy requirements tracking number.
As shown in Fig. 2B, insurance policy database _ g _ o _ 265 tracks each insurance policy 60 generated by end users, and preferably includes fields such as end-user ID
number, insurance policy 60, tracking number, date generated, policy requirements tracking number, and status of premium payment. Each insurance policy 60 may have an associated status of insurance policy 60 such as "active,"
"pending," or "expired."
As shown in Fig. 2C, transaction data database 270 stores all transaction data relating to insurance policy 60. This database is indexed by the tracking number of insurance policy 60, and preferably contains fields such as end-user ID number, amount of transaction, date of transaction, prevailing exchange rate, and bank ID
number.
Exchange rate database 275 facilitates the 15 processing of transaction data 70 by storing current and historic exchange rates for every country. The current exchange rate may be updated hourly or continuously, but preferably automatically via financial networks transacting interbank foreign exchanges.
20 Exchange rate volatility database 280 stores historical volatility data corresponding to each currency.
This data may include past exchange rates, as well as the standard deviation of the rates over a given period of time.
25 Payment database 285 tracks premium payments by end users, payments to merchants or banks, and payment of claims for insurance policy 60, which contains fields such as end-user name, end-user ID number, credit card number, amount of payment, and date of payment. This database may 30 also store the user's bank account information.
End-user account database 290 allows central controller 200 to track amounts owed to the end user under claims against insurance policy 60.
Finally, cryptographic key database 295 contains 35 algorithms and keys for encrypting, decrypting, and _ g _ o _ authenticating communications.
Network interface 245 provides the gateway to communication with transaction networks and financial data providers supplying current exchange rate information.
Conventional internal or external modems may serve as network interface 245. Network interface 245 preferably supports modems at a range of baud rates from 1200bps upward, but may combine such inputs into a T1 or T3 line if more bandwidth is required. In a preferred embodiment, network interface 245 is connected with the Internet or private data network.
IVRU 225 allows end users to communicate with central controller 200 via telephone. The user can therefore enter policy requirements 50 via touch-tone keys of the end user's telephone.
In another embodiment, central controller 200 is configured in a distributed architecture, wherein the databases and processors are housed in separate units or locations. Some controllers perform primary processing functions and contain at a minimum, a RAM, a ROM, and a general processor. Each of these controllers is attached to a wide-area network (WAN) hub that serves as a primary communication link with the other controllers and terminals. The WAN hub may have minimal processing capability itself, serving primarily as a communications router.
In an exemplary embodiment, end-user interface 300 is a conventional telephone, capable of communicating with central controller 200 via a public switched telephone network. Conventional cellular phones or PCS
devices would work equally well.
Alternatively, end-user interface 300 includes a conventional personal computer having an input device, such as a keyboard, a mouse, or a conventional voice recognition software package; a display device, such as a video monitor; a processing device, such as a CPU; and a o -network interface, such as a modem. This configuration allows the end user to communicate with central controller 200 using any one of commercial on-line services such as America Online, CompuServe, or Prodigy, allowing end user access to central controller 200 from a wide range of electronic connections.
Communications from end-user interface 300 are preferably software driven. Many commercial software applications, whose primary functions are message creation and transmission, can facilitate communications of end-user interface 300. Eudora Pro manufactured by Qualcomm Incorporated, for example, provides editing tools to create messages as well as communications tools to route messages to the appropriate electronic address. If central controller 200 is configured as a Web server, conventional communications software, such as Navigator from Netscape Corporation may also be used. The end user may use Netscape's Navigator browser to transmit policy requirements 50. Transaction interface 400 transmits transaction data 70 from the end user to central controller 200 for processing. The structure of transaction interface 400 depends on the type of transactions.
Figs. 3-5 illustrate three different ways of further implementing the system in Fig. 1. Fig. 3 illustrates a credit card implementation of the present invention. Transaction data 70 flows from a credit card reader 410, to a credit card processing network 420, then to a credit card clearinghouse 430, and finally to central controller 200. These transactions are described in more detail below in connection with Figs. 6-12.
Fig. 4 illustrates an automated teller machine (ATM) implementation of the present invention in which the end user withdraws money from an ATM. In this embodiment, the end user enters transaction data 70 into an ATM 440, which then transmits the data to an ATM network 450, and finally to central controller 200. This embodiment is described in mare detail in connection with Figs. 13-15.
Fig. 5 illustrates a bank implementation of the present invention in which the end user seeks to exchange currency at a bank or other financial institution. After providing transaction data 70 to a bank 460, bank 460 relays the information to central controller 200 using a conventional telephone or electronic network. This embodiment is described in more detail in connection with Figs. 16 and 17.
Credit Card Implementation In the credit card embodiment of the present invention shown in Fig. 3, policy requirements 50 and insurance policy 60 are transmitted over a phone line, while insured transactions occur through the use of a conventional credit card.
Fig. 6 illustrates a preferred process for the end user to select policy requirements 50 (Fig. 1).
Policy requirements 50 describe parameters for insurance policy 60, and reflect the insurance needs of the end user. Initially, the end user calls central controller 200 using a conventional telephone, establishing a communication link through a public switched telephone network (step 600}. The end user may speak to an operator or enter the information into IVRU 225.
Central controller 200 processes information provided in steps 610 through 660 described below, as policy requirements 50. First, the end user provides his or her name or a unique ID number (step 610). Central controller 200 either receives this ID number from the end user, or assigns a number to the end user. Central controller 200 maintains a database of end user ID numbers in end-user database 255, and assigns (or allows} only unique numbers. If minimal security is required, the user's telephone number may serve as the ID number since it is unique and easy to remember. If additional security is required, authentication procedures, described hereinafter in the cryptographic authentication section may be implemented.
The end user provides a credit card number designated under insurance policy 60 (step 620), and then selects the foreign currency for insurance coverage, such as the French Franc or German Deutchmark (step 630). For alternative implementations, the credit card number of step 620 may be replaced with any other financial account numbers of the end user. For some currencies, additional information is necessary to indicate which of several exchange rates apply. In some countries, for example, the exchange rate is more favorable for local residents than for tourists.
The end user then selects the "locked-in"
IS exchange rate (step 640). For example, if the current market rate for French Francs is five per dollar, the end user may select five to one as his insured exchange rate.
The end user may lock in at any rate and the premium cost is computed accordingly. Insurance policy 60 will later compensate the end user for any transaction executed during a coverage period if the prevailing exchange rate at the time of transaction is less favorable than the locked-in exchange rate of five French Francs per dollar.
This protects the end user against an unfavorable fluctuation of currency exchange rate.
Next, the end user selects start and end dates of coverage (step 650). These dates may correspond with personal or business travel dates of the end user.
Transactions occurring either before the start date or after the end date are not covered by insurance policy.
For example, policy requirement 50 of a business traveler on a two week trip may require a start date of July 5, 1996 and an end date of July 19, 1996. The end user also selects the desired amount of coverage, preferably in domestic currency.
o -In the above example, the end user selects two thousand dollars of coverage, ensuring protection for two thousand dollars' worth of transactions at the locked-in rate. Transactions may, for example, include credit card payments for hotels and restaurants. After spending Francs equivalent of two thousand dollars at the locked-in rate, the end user is subject to the prevailing exchange rate and no longer enjoys the locked-in rate for future transactions.
Fig. 7 is a flowchart illustrating a preferred process for calculating a premium cost. First, central controller 200 stores policy requirements 50 received from the end user, along with the end-user ID number, in policy requirements database 260 (step 700). CPU 205 accesses exchange rate database 275 for the current exchange rate of the currency designated in policy requirements 50 (step 710). This exchange rate is preferably the current interbank rate, which serves as the basis of most global foreign exchange transactions. CPU 205 then accesses exchange rate volatility database 280 for exchange rate volatility data (step 720). Currencies with large volatilities, expressed in terms of standard deviations over a fixed period of time, require a large premium cost due to a greater risk of exchange rate fluctuation.
A premium cost is calculated based on policy requirements 50, the current exchange rate, and exchange rate volatility data (step 730). Therefore, insurance for more volatile currencies requires higher premiums. Also, a coverage period having a start date far from the current date will also necessitate a higher premium as the effect of volatility is magnified over long periods of time. For example, policy requirements 50, indicating two days of coverage beginning five days from today, has a lower premium than the same policy beginning sixty days from now. Additionally, a longer coverage period requires a higher premium. The premium is also directly related to o -the amount of coverage. Policy requirements 50 specifying a locked-in rate that is below current spot exchange rates, however, lowers premium cost because a greater amount of fluctuation may occur before the coverage begins to take effect, thus, reducing the risk to the policy provider. Therefore, the premium cost is a function of policy requirements 50, current exchange rate, and exchange rate volatility. Once calculated, the premium cost is transmitted to the end user (step 740).
Fig. 8 is a flowchart illustrating a preferred process for creating insurance policy 60. The end user evaluates the premium cost transmitted by central controller 200 to decide whether the premium is acceptable (step 800). If the premium is not acceptable to the end user, the end user may develop new policy requirements 50 (step 820). For example, if the premium is too high, the user may lower the amount of coverage or change the period of coverage. Central controller 200 then calculates a new premium based on the modified policy requirements 50 (step 825), as described in connection with Fig. 7.
If the premium is acceptable to the end user (step 810), the user transmits an acceptance to central controller 200, providing confirmation over the phone or other communication channels such as electronic mail, postal mail, or pager (step 830). To bill the user for the premium, central controller 200 may directly debit the user's credit card account or send a separate bill to the user. Next, central controller 200 generates a tracking number and appends it to insurance policy 60 (step 840), and transmits this tracking number to the end user as a confirmation of insurance policy 60 (step 850). If the user desires, central controller 200 also transmits the details of insurance .policy 60 to the end user.
At this point, central controller 200 assigns a "pending" status to the newly created insurance policy 60 (step 855). Central controller 200 stores insurance o w policy 60 in insurance policy database 265 along with its corresponding status (step 860). Later, if the end user satisfies a credit approval process or pays the premium, central controller 200 changes the "pending" status of insurance policy 60 to an "active" status.
Central controller 200 also performs maintenance checks to ensure that only active insurance policy 60 is stored in insurance policy database 265. Fig. 9 is a flowchart illustrating a preferred process for maintaining active insurance policy 60 (Fig. 1). First, central controller 200 makes periodic searches through insurance policy database 265, retrieving the end date of each insurance policy 60 as well as the credit card number (step 900). CPU 205 compares the end date of policy 60 with the current date (step 910).
If the current date is later then the end date of insurance policy 60, central controller 200 changes the status of insurance policy 60 to "expired" (step 920).
Database records for "expired" insurance policies 60 may be deleted from insurance policy database 265 once all claims have been settled with the end user or stored in an audit database for subsequent reference. Additionally, payment processor 230 checks to see whether the credit card number is still valid by contacting a credit card clearinghouse (step 930). If the card number is no longer valid, the status of insurance policy 60 is changed to "expired" (step 940). Otherwise, insurance policy 60 maintenance process is complete (step 950).
Once an active insurance policy 60 is stored in insurance policy database 265, the end-user may execute transactions under insurance policy 60. Fig. 10 is a flowchart illustrating a preferred process for generating transaction data 70 (Fig. 3). As the end user executes foreign currency transactions with the credit card, the data is transmitted to central controller 200 for processing. First, the end user makes a credit card o purchase with the credit card designated in insurance policy 60 (step 1000). For example, the end user buys a bottle of wine in France, providing the merchant the credit card data. The merchant sends transaction data 70, which is the credit card data and the purchase amount, to credit card processing network 420 (step 1010).
The merchant may swipe the credit card through credit card reader 410 to extract credit card information from the magnetic strip on the back of the card, or use some equivalent resource. The merchant then enters the amount of the transaction into a numeric keypad of credit card reader 410. Credit card reader 410, connected to credit card processing network 420 over a dedicated communication line, electronically transmits transaction data 70, and sends transaction data 70 to credit card clearinghouse 430 (step 1020). Credit card clearinghouse 430, operated by the member~banks, functions as a consolidator of credit card transactions, and sends transaction data 70 to central controller 200 in real time or in a batch process (step 1030).
After central controller 200 receives transaction data 70, it processes transaction data 70 under insurance policy 60. Fig. 11 is a flowchart illustrating a preferred process for determining whether an insurance adjustment 80 (Fig. 3) is necessary. First, central controller 200 searches insurance policy database 265 for the credit card number associated with each transaction data 70 received from credit card clearinghouse 430 (step 1100). If the credit card number is not found in insurance policy database 265 (step 1110), no insurance adjustment 80 is necessary because the end user does not have an active policy (step 1120).
If the credit card number is found in insurance policy database 265, the exchange rate associated with transaction data 70 is compared with the locked-in rate specified in insurance policy 60 (step 1130). The exchange rate associated with transaction data 70 is the prevailing spot exchange rate at the time of the transaction. This prevailing exchange rate is retrieved from exchange rate database 270. CPU 205 calculates whether the locked-in rate is more favorable than the prevailing rate on the day of transaction (step 1140).
For example, if the locked-in rate is five Francs per dollar and the prevailing spot rate on the day of the transaction is six Francs per dollar, then the prevailing rate is more favorable. If the prevailing rate is more favorable than the locked-in rate, insurance adjustment 80 is not necessary (step 1150).
If the rate received by the end user is less favorable than the locked-in rate, CPU 205 checks insurance policy database 265 to determine whether the coverage amount has already been used up (step 1160). If the coverage has been used up, insurance adjustment 80 is not necessary (step 1170). For example, insurance policy 60 with a two thousand dollar coverage does not cover insurance adjustment 80 for any transaction beyond the two thousand dollars. If the coverage is not exhausted, insurance adjustment 80 is necessary (step 1180).
Fig. 12 is a flowchart illustrating a preferred process for calculating the amount of insurance adjustment 80. First, central controller 200 calculates the amount of the transaction in domestic currency using the locked-in exchange rate (step 1200). For example, a traveler paying one thousand francs for a hotel room with a locked-in exchange rate of five francs per dollar would have a transaction amount of two hundred dollars.
Next, central controller 200 calculates the transaction amount in domestic currency using the prevailing exchange rate on the day transaction data 70 is received by central controller 200. For example, if the prevailing exchange rate is four francs per dollar when the traveler pays for his hotel room, the cost in dollars o -would be two hundred and fifty. The differential between the two amounts is determined by subtracting the transaction amount at the prevailing rate from the transaction amount at the locked-in rate (step 1220). In the above example, the differential is fifty dollars.
This represents a loss to the traveler due to the drop in exchange rates from five francs to four francs per dollar.
Finally, insurance adjustment 80 is determined by computing the differential corresponding to the remaining amount of coverage under insurance policy 60.
For example, if the traveler has only one hundred dollars of coverage remaining, the differential of fifty dollars is halved to reflect that only half of the two hundred dollar purchase transaction is covered, and the end user is only entitled to insurance adjustment 80 of twenty five dollars. If the end user has a remaining coverage greater than the purchase amount at the locked-in rate, then insurance adjustment 80 is equal to the computed differential. Insurance adjustment 80 is transmitted to the issuing bank of the credit card (step 1230), or stored in end-user account database 290 for later processing until the coverage of insurance policy 60 expires or is used up. Insurance adjustment 80 appears as a credit on the monthly credit card statement of the end user (step 1240). Central controller 200 also updates the remaining amount of coverage in end-user account database 290 (step 1250}.
ATM Implementation The end user can also enjoy a locked-in exchange rate for cash withdrawals from ATMs abroad. The procedure establishing insurance policy 60 is identical to that described above in connection with Figs. 6-8.
Fig. 13 is a flowchart illustrating a preferred process for generating transaction data 70 when the end user withdraws money from an ATM. The end user requests foreign currency from ATM 440 (step 1300). Using the o -numeric keypad of ATM 440, the end user enters the amount of the transaction (step 1310). A traveler in France, for example, withdraws one thousand francs from ATM 440. If the user wants to use the locked-in rate of insurance policy 60, the traveler enters the tracking number of insurance policy 60 into ATM 440 (step 1320). In addition to the amount of withdrawal and tracking number, transaction data 70 includes, for example, the end user's PIN number, the current date, and an ATM identification number. ATM 440 sends transaction data 70 to ATM network 450 using the dedicated communication line of ATM 440.
ATM network 450 relays transaction data 70 to central controller 200 for processing, waiting for a transmission from central controller 200 to provide the appropriate exchange rate (step 1330).
To obtain the appropriate exchange rate, central controller 200 determines whether an insurance adjustment is necessary when the end user withdraws money from an ATM. Referring to Fig. 14, central controller 200 searches insurance policy database 265 for the tracking number received from ATM network 450 (step 1400). If central controller 200 does not find the tracking number in insurance policy database 265 (step 1410), central controller 200 transmits a message to ATM network 450, instructing ATM 440 to issue the cash at the prevailing rate (step 1420).
If the tracking number is found, central controller 200 compares the prevailing exchange rate to the locked-in exchange rate of insurance policy 60 (step 1430). If the exchange rate specified in insurance policy 60 is not more favorable than the prevailing rate (step 1440), ATM 440 is instructed (through ATM network 450) to pay the end user at the prevailing exchange rate (step 1450). This prevents the end user from invoking a claim under insurance policy 60 if the prevailing exchange rate is less favorable or equal to the prevailing rate.
o -If the locked-in exchange rate is more favorable than the prevailing rate, however, central controller 200 accesses end- user account database 290 to check the remaining coverage amount (step 1460). If the coverage has been exhausted, ATM 440 is once again instructed to pay the end user at the prevailing exchange rate (step 1470). If coverage remains, however, central controller 200 determines that insurance adjustment 80 is necessary (step 1480).
After central controller 200 determines that insurance adjustment 80 is necessary, it calculates the amount of insurance adjustment 80 as shown in Fig. 15.
First, central controller 200 determines the remaining amount of coverage (step 1500). Central controller 200 then calculates the foreign exchange differential. In 15 doing so, central controller 200 calculates the amount to be withdrawn in dollars at the locked-in rate (step 1510).
The amount of withdrawal is also calculated in dollars using the prevailing rate at the time of the withdrawal.
Central controller 200 obtains the amount of insurance 20 adjustment 80 as described above in connection with Fig.
14 (step 1520), and updates the remaining amount of coverage in end-user account database 290 (step 1530).
Central controller 200 instructs ATM 440 to present the end user with currencies at the locked-in 25 exchange rate of insurance policy 60 (step 1540). In order to compensate the bank operating ATM 440 for the exchange rate loss associated with the transaction, central controller 200 electronically transfers the amount of currency equal to insurance adjustment 80 to the bank 30 (step 1550).
In an alternative embodiment, the end user's bank transmits the electronic compensation to the bank operating ATM 440. Central controller 200 later reimburses the end user's bank for the amount of insurance 35 adjustment 80.
o _ Bank Implementation In another embodiment of the present invention, the end user enjoys a locked-in exchange rate for currency exchanges at a bank. The procedure establishing insurance policy 60 is described above in connection with Figs. 6-8.
Fig. 16 is a flowchart illustrating a preferred process for generating transaction data 70 by the end user exchanging money at a bank. The end user requests currency exchange at a foreign bank (step 1600), and specifies the amount of transaction (step 1610). For example, a tourist may exchange two hundred dollars into f rancs .
The end user then provides the tracking number of insurance policy 60 (step 1620), enabling bank 460 to verify the exchange rate that the end user demands. Next, bank 460 calls central controller 200 using a conventional telephone (step 1630), and provides transaction data 70 such as end user name, insurance policy 60 tracking number, amount of currency to be exchanged, current exchange rate, and a bank identification number. Bank 460 enters transaction data 70 using a touch-tone telephone or by speaking with an agent (step 1640).
Fig. 17 is a flowchart illustrating a preferred process for determining whether insurance adjustment 80 is necessary. Central controller 200 processes transaction data 70. Central controller 200 searches insurance policy database 265 for the tracking number transmitted by bank 460 (step 1700). If central controller 200 does not find the tracking number in insurance policy database 265 (step 1710), central controller 200 instructs bank 460 to exchange the end user's money at the prevailing exchange rate (step 1720). If the tracking number is found, then the exchange rate provided by bank 460 is compared to the locked-in exchange rate specified in insurance policy 60 (step 1730). If the locked-in rate is not more favorable (step 1740), then central controller 200 instructs bank o 460 to exchange the end user's money at the prevailing exchange rate (step 1750). If the locked-in rate is more favorable, central controller 200 checks the remaining amount of coverage (step 1760). If no coverage remains, central controller 200 instructs bank 460 to exchange the end user's money at the prevailing exchange rate (step 1770). If the coverage is not exhausted, however, insurance adjustment 80 is required (step 1780). Central controller 200 then calculates the amount of insurance adjustment 80 as described above in connection with Fig.
15, and updates the remaining coverage amount in end user account 240.
Offline Implementation All the implementations described above use transaction data 70 transmitted to central controller 200 over electronic networks. The present invention, however, may also employ off-line methods for submitting transaction data 70.
For example, a business traveler on a two week trip in Germany could collect receipts for all of his transactions. Upon returning from the trip, the traveler may mail these receipts to a person who enters the data into central controller 200, which then processes the transaction as described above. Any insurance adjustment 80 required may be mailed to the end user.
Internet Implementation Creation of insurance policy 60 and processing of transaction data 70 can also take place over an electronic network such as the Internet or a commercial online service provider like America Online or CompuServe.
The end user logs on to central controller 200 using a personal computer as end-user interface 300. The procedure establishing insurance policy 60 is similar to that described above in connection with Figs. 6-8. The end user is then able to provide the tracking number as proof of insurance for any electronic commerce conducted o -on the Internet.
For example, the end user accesses a Web site and purchases tickets (denominated in French francs) for an opera in France. The end user provides the credit card number and the tracking number, and the Web site verifies insurance policy 60 with central controller 200. Once verified, the Web site provides the tickets at the locked-in rate specified by insurance policy 60 and receives compensation from central controller 200 for the amount of insurance adjustment 80.
Insurance policy 60 tracking number can also be used in the conversion of digital cash from one currency to another. The end user provides a quantity of digital cash to be converted along with the tracking number of insurance policy 60 to an online bank offering foreign exchange. The bank verifies the validity of insurance policy 60 with central controller 200, and accesses the locked-in exchange rate of insurance policy 60. Assuming the locked-in rate is more favorable and sufficient amount of coverage remains, the bank completes the conversion of funds at the locked-in exchange rate, electronically transferring the new currency back to the end user for storage at end-user interface 300.
Alternatively, this digital money could be transferred to a stored value card, such as a smart card, so the end-user can use the money for transactions away from end-user interface 300. The practice of using digital cash protocols to affect payment is well known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Daniel C.
Lynch and Leslie Lundquist, Digital Money. John Wiley &
Sons (1996); or Seth Godin, Presenting Digital Cash (1995) .
Central controller 200 can also create a digital code incorporating all of the information in insurance policy 60. This digital code is encrypted with a private o -key of central controller 200 and transmitted to the end user. The end user presents this digital code to a bank along with a request for currency exchange. The bank decrypts the digital code with the public key of central controller 200 and extracts all of the details of insurance policy 60, allowing the bank access to the locked-in exchange rate without having to contact central controller 200. The bank is assured that the digital code is legitimate because only central controller 200 has access to the private key that originally encrypted the digital code.
This digital code may also be stored in a smart card. In that case, the end user need only swipe the card through a smart card reader to provide the digital code.
Cryptographic Authentication 15 The system can also provide additional security measures to ensure the integrity of data communications.
One protocol is authenticating authorship of end user communications, i.e., checking an attached ID or name and comparing it with those stored in end-user database 255.
20 Additionally, cryptographic protocols may be added to the authentication process. These protocols enhance the ability to authenticate the sender of a message and verify the integrity of the communication itself, proving that it has not been altered during transmission. Encryption can 25 also prevent eavesdroppers from learning the contents of the communication. Such techniques shall be referred generally as cryptographic assurance methods and will include the use of both symmetric and asymmetric keys as well as digital signatures and hash algorithms.
30 The practice of using cryptographic protocols to ensure the authenticity of senders as well as the integrity of communications is well known in the art and need not be described here in detail. Any conventional cryptographic protocols such as those described in Bruce 35 Schneier, Applied Cryptography) Protocols. Algorithms, and Source Code In C (2d ed. 1996), could be used in accordance with the present invention.
Fig. 18 is a flowchart illustrating an exemplary authentication procedure using symmetric key protocols in which the end user and central controller 200 share a key.
Thus, both encryption and decryption of end user communications are performed with the same key. This encryption may be implemented with an algorithm such as DES (U. S. Government standard, specified in FIPS PUB 46), or with any of several algorithms known in the art such as IDEA, Blowfish, RC4, RC2, and SAFER.
The end user encrypts communications with an assigned symmetric key (step 1800), using cryptographic processor 210 of end-user interface 300. The end user communication is then transmitted to cryptographic processor 210 of central controller 200 (step 1810).
Cryptographic processor 210 extracts the end-user ID from the end-user communication (step 1820), looks up the symmetric key of the end user in cryptographic key database 295 (step 1830), and decrypts end-user communications with this key (step 1840). Cryptographic key database 295 contains algorithms and keys for encrypting, decrypting and/or authenticating communications. If the resulting communication is intelligible, then it is determined to have been encrypted by the same key, thus authenticating the end user as the author of the message (step 1850).
This procedure makes it difficult for unauthorized end users to represent themselves as legitimate end users. Without cryptographic procedures, an unauthorized end user who obtained a sample communication from a legitimate end user may be able to extract the end-user ID and then attach this ID number to unauthorized communications. When end user communications are encrypted with a symmetric key, however, an unauthorized end user obtaining a sample end user WO 98/21680 PCT/US97l20754 o _ communication only discovers the end user's ID number) not the symmetric key. Without this key, the unauthorized end user cannot create an end-user communication that will fool central controller 200, since the unauthorized end user cannot encrypt the communication the same way as the authorized end user. The symmetric key protocol also ensures that the end-user communication has not been tampered with during transmission because alteration of the communication requires knowledge of the symmetric key.
An encrypted end-user communication provides the end user with greater anonymity.
Fig. 19 is a flowchart illustrating an exemplary asymmetric key protocol in which the end-user communication is encrypted with a private key and decrypted with a public key. Two such algorithms for 15 asymmetric key protocols are RSA and DSA. The end user encrypts the communication with a private key using the cryptographic processor of end-user interface 300 (step 1900), and transmits communication to central controller 200 (step 1910). Cryptographic processor 210 extracts the 20 end-user ID (step 1920), and looks up the end user's associated public key in cryptographic key database 295 (step 1930), and decrypts the communication with this public key (step 1940). As before, if the communication is intelligible then central controller 200 has 25 authenticated the end user (step 1950). Again, unauthorized end users obtaining the communication before it is received by central controller 200 are unable to alter it undetectably since the intruders do not know the private key of the end user. Unauthorized end users may, 30 however, be able to read the message if they obtain the public key of the end user. Communication secrecy is preserved if the end user encrypts the communication with the public key, requiring the intruder to know the end user's private key to view the communication.
The present invention provides foreign exchange insurance policies to individuals as well as large corporate entities and offers protection against unpredictable foreign exchange rate fluctuations.
Additionally, the present invention provides a way of automatically processing transactions covered by the foreign exchange insurance policies.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention and in construction of the invention without departing from the scope or spirit of the invention. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification and examples should be considered as exemplary only, with the true scope and spirit of the invention indicated by the following claims.
Fig. 5 is a block diagram of still another system consistent with the present invention using banks;
Fig. 6 is a flowchart illustrating a preferred process for selecting policy requirements;
Fig. 7 is a flowchart illustrating a preferred process for calculating an insurance premium;
Fig. 8 is a flowchart illustrating a preferred process for creating the insurance premium for the user;
Fig. 9 is a flowchart illustrating a preferred process for system maintenance of active insurance policies;
Fig. 10 is a flowchart illustrating a preferred process for transmitting transaction data using credit cards;
15 Fig. 11 is a flowchart illustrating a preferred process for determining whether an insurance adjustment is necessary for the process of Fig. 10;
Fig. 12 is a flowchart illustrating a preferred process for calculating the amount of the insurance 20 adj us tment ;
Fig. 13 is a flowchart illustrating a preferred process for transmitting transaction data using ATMs;
Fig. 14 is a flowchart illustrating a preferred process for determining whether an insurance adjustment is 25 necessary for the process of Fig. 13;
Fig. 15 is a flowchart illustrating a preferred process for calculating the amount of the insurance adjustment for the process of Fig. 13;
Fig. 16 is a flowchart illustrating a preferred 30 process for transmitting transaction data using banks;
Fig. 17 is a flowchart illustrating a preferred process for determining whether an insurance adjustment is necessary for the process of Fig. 16;
Fig. 18 is a flowchart illustrating an 35 authentication procedure using symmetric key protocols;
_ 5 _ o -and Fig. 19 is a flowchart illustrating an authentication procedure using public key protocols.
DETAILED DESCRIPTION
Reference will now be made in detail to the present preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings.
System Architecture As shown in Fig. 1, a system consistent with the present invention includes a central controller 200, an end-user interface 300, and a transaction interface 400.
The elements preferably connect to each other via a public switched telephone network. Alternatively, the system elements may be connected by dedicated data lines, cellular, Personal Communication Systems ("PCS~~), 15 microwave, satellite networks, Internet, or any other suitable form of data communications. Policy requirements 50, insurance policy 60, and transaction data 70 travel through these connections.
Fig. 2 shows a detailed block diagram of central 20 controller 200 shown in Fig. 1. Central controller 200 preferably includes a central processor unit (CPU) 205, a cryptographic processor 210, a random access memory (RAM) 215, a read-only memory (ROM) 220, an Interactive Voice Response Unit (IVRU) 225, a payment processor 230, a clock 25 235, an operating system 240, a network interface 245, and a data storage device 250. All of these elements are connected to CPU 205 to facilitate communication between them.
Central controller 200 operates as a primary 30 server, both receiving and transmitting communications with end-user interface 300 and transaction interface 400.
Central controller 200 is preferably capable of high volume processing, performing a significant number of mathematical calculations in processing communications and 35 database searches. Central controller 200 may be a o -conventional personal computer or a computer workstation with sufficient memory and processing capability. For example, a Pentium microprocessor such as the 100 MHZ
P54C, commonly manufactured by Intel, Inc., may be used for CPU 205. This processor employs a 32-bit architecture. Equivalent processors include the Motorola 120 MHZ PowerPC 604 or Sun Microsystems 166 MHZ
UltraSPARC-I.
Cryptographic processor 210 supports the encoding and decoding of communications as well as the authentication of transactions. A MC68HC16 microcontroller, commonly manufactured by Motorola, Inc., may be used for cryptographic processor 210. This microcontroller uses a 16-bit multiply-and-accumulate instruction in a 16 MHZ configuration and requires less than one second to perform a 512-bit RSA private key operation. One skilled in the art may easily substitute other commercially available, specialized cryptographic processors such as VLSI Technology's 33MHZ 6868 or Semaphore Communications' 40 MHZ Roadrunner284.
Alternatively, cryptographic processor 210 may be configured as part of CPU 205.
Operating system 240 comprises a conventional operating system such as DOS, Windows, or OS2.
Payment processor 230 supports the transfer and exchange of payments, charges, or debits. Exemplary services operable on payment processor 320 include on-line credit authorizations, credit card settlement, payments to transaction networks, and payment aggregation.
Commercially available software, such as the Secure Webserver manufactured by Open Market, Inc., may support credit card transaction processing of payment processor 230. This server software transmits credit card numbers electronically over the Internet to servers located at the Open Market headquarters, which handles card verification and processing. The Open Market's Integrated Commerce _ 7 _ o -Service provides back-office services necessary to run Web-based businesses. Payment processor 230 preferably comprises a microprocessor (such as the Intel Pentium), but alternatively may be configured as part of CPU 205.
Operating system 240 comprises a conventional operating system such as DOS, Windows, or OS2.
Data storage device 250 may include a hard magnetic disk, optical storage units, CD-ROM drives, or flash memory. Data storage device 250 contains databases used in processing transactions in the present invention, including an end-user database 255, a policy requirements database 260, an insurance policy database 265, a transaction data database 270, an exchange rate database 275, an exchange rate volatility database 280, a payment database 285, an end-user account database 290, and cryptographic key database 295. In a preferred embodiment, database software such as Oracle7, manufactured by Oracle Corporation, creates and manages these databases.
End-user database 255 maintains data about end users and, in one embodiment, includes fields such as name, address, credit card number, phone number, ID
number, social security number, electronic mail address, and public/private key information. This information is preferably obtained when the end user first generates insurance policy 60 on the system. End-user database 255 also contains the tracking number of each insurance policy 60 generated by the end user.
As shown in Fig. 2A, policy requirements database 260 maintains data on policy requirements generated by the end user, and preferably includes fields such as end-user ID, credit card number, currency selected, exchange rate, start date of coverage, end date of coverage, and amount of coverage, and policy requirements tracking number.
As shown in Fig. 2B, insurance policy database _ g _ o _ 265 tracks each insurance policy 60 generated by end users, and preferably includes fields such as end-user ID
number, insurance policy 60, tracking number, date generated, policy requirements tracking number, and status of premium payment. Each insurance policy 60 may have an associated status of insurance policy 60 such as "active,"
"pending," or "expired."
As shown in Fig. 2C, transaction data database 270 stores all transaction data relating to insurance policy 60. This database is indexed by the tracking number of insurance policy 60, and preferably contains fields such as end-user ID number, amount of transaction, date of transaction, prevailing exchange rate, and bank ID
number.
Exchange rate database 275 facilitates the 15 processing of transaction data 70 by storing current and historic exchange rates for every country. The current exchange rate may be updated hourly or continuously, but preferably automatically via financial networks transacting interbank foreign exchanges.
20 Exchange rate volatility database 280 stores historical volatility data corresponding to each currency.
This data may include past exchange rates, as well as the standard deviation of the rates over a given period of time.
25 Payment database 285 tracks premium payments by end users, payments to merchants or banks, and payment of claims for insurance policy 60, which contains fields such as end-user name, end-user ID number, credit card number, amount of payment, and date of payment. This database may 30 also store the user's bank account information.
End-user account database 290 allows central controller 200 to track amounts owed to the end user under claims against insurance policy 60.
Finally, cryptographic key database 295 contains 35 algorithms and keys for encrypting, decrypting, and _ g _ o _ authenticating communications.
Network interface 245 provides the gateway to communication with transaction networks and financial data providers supplying current exchange rate information.
Conventional internal or external modems may serve as network interface 245. Network interface 245 preferably supports modems at a range of baud rates from 1200bps upward, but may combine such inputs into a T1 or T3 line if more bandwidth is required. In a preferred embodiment, network interface 245 is connected with the Internet or private data network.
IVRU 225 allows end users to communicate with central controller 200 via telephone. The user can therefore enter policy requirements 50 via touch-tone keys of the end user's telephone.
In another embodiment, central controller 200 is configured in a distributed architecture, wherein the databases and processors are housed in separate units or locations. Some controllers perform primary processing functions and contain at a minimum, a RAM, a ROM, and a general processor. Each of these controllers is attached to a wide-area network (WAN) hub that serves as a primary communication link with the other controllers and terminals. The WAN hub may have minimal processing capability itself, serving primarily as a communications router.
In an exemplary embodiment, end-user interface 300 is a conventional telephone, capable of communicating with central controller 200 via a public switched telephone network. Conventional cellular phones or PCS
devices would work equally well.
Alternatively, end-user interface 300 includes a conventional personal computer having an input device, such as a keyboard, a mouse, or a conventional voice recognition software package; a display device, such as a video monitor; a processing device, such as a CPU; and a o -network interface, such as a modem. This configuration allows the end user to communicate with central controller 200 using any one of commercial on-line services such as America Online, CompuServe, or Prodigy, allowing end user access to central controller 200 from a wide range of electronic connections.
Communications from end-user interface 300 are preferably software driven. Many commercial software applications, whose primary functions are message creation and transmission, can facilitate communications of end-user interface 300. Eudora Pro manufactured by Qualcomm Incorporated, for example, provides editing tools to create messages as well as communications tools to route messages to the appropriate electronic address. If central controller 200 is configured as a Web server, conventional communications software, such as Navigator from Netscape Corporation may also be used. The end user may use Netscape's Navigator browser to transmit policy requirements 50. Transaction interface 400 transmits transaction data 70 from the end user to central controller 200 for processing. The structure of transaction interface 400 depends on the type of transactions.
Figs. 3-5 illustrate three different ways of further implementing the system in Fig. 1. Fig. 3 illustrates a credit card implementation of the present invention. Transaction data 70 flows from a credit card reader 410, to a credit card processing network 420, then to a credit card clearinghouse 430, and finally to central controller 200. These transactions are described in more detail below in connection with Figs. 6-12.
Fig. 4 illustrates an automated teller machine (ATM) implementation of the present invention in which the end user withdraws money from an ATM. In this embodiment, the end user enters transaction data 70 into an ATM 440, which then transmits the data to an ATM network 450, and finally to central controller 200. This embodiment is described in mare detail in connection with Figs. 13-15.
Fig. 5 illustrates a bank implementation of the present invention in which the end user seeks to exchange currency at a bank or other financial institution. After providing transaction data 70 to a bank 460, bank 460 relays the information to central controller 200 using a conventional telephone or electronic network. This embodiment is described in more detail in connection with Figs. 16 and 17.
Credit Card Implementation In the credit card embodiment of the present invention shown in Fig. 3, policy requirements 50 and insurance policy 60 are transmitted over a phone line, while insured transactions occur through the use of a conventional credit card.
Fig. 6 illustrates a preferred process for the end user to select policy requirements 50 (Fig. 1).
Policy requirements 50 describe parameters for insurance policy 60, and reflect the insurance needs of the end user. Initially, the end user calls central controller 200 using a conventional telephone, establishing a communication link through a public switched telephone network (step 600}. The end user may speak to an operator or enter the information into IVRU 225.
Central controller 200 processes information provided in steps 610 through 660 described below, as policy requirements 50. First, the end user provides his or her name or a unique ID number (step 610). Central controller 200 either receives this ID number from the end user, or assigns a number to the end user. Central controller 200 maintains a database of end user ID numbers in end-user database 255, and assigns (or allows} only unique numbers. If minimal security is required, the user's telephone number may serve as the ID number since it is unique and easy to remember. If additional security is required, authentication procedures, described hereinafter in the cryptographic authentication section may be implemented.
The end user provides a credit card number designated under insurance policy 60 (step 620), and then selects the foreign currency for insurance coverage, such as the French Franc or German Deutchmark (step 630). For alternative implementations, the credit card number of step 620 may be replaced with any other financial account numbers of the end user. For some currencies, additional information is necessary to indicate which of several exchange rates apply. In some countries, for example, the exchange rate is more favorable for local residents than for tourists.
The end user then selects the "locked-in"
IS exchange rate (step 640). For example, if the current market rate for French Francs is five per dollar, the end user may select five to one as his insured exchange rate.
The end user may lock in at any rate and the premium cost is computed accordingly. Insurance policy 60 will later compensate the end user for any transaction executed during a coverage period if the prevailing exchange rate at the time of transaction is less favorable than the locked-in exchange rate of five French Francs per dollar.
This protects the end user against an unfavorable fluctuation of currency exchange rate.
Next, the end user selects start and end dates of coverage (step 650). These dates may correspond with personal or business travel dates of the end user.
Transactions occurring either before the start date or after the end date are not covered by insurance policy.
For example, policy requirement 50 of a business traveler on a two week trip may require a start date of July 5, 1996 and an end date of July 19, 1996. The end user also selects the desired amount of coverage, preferably in domestic currency.
o -In the above example, the end user selects two thousand dollars of coverage, ensuring protection for two thousand dollars' worth of transactions at the locked-in rate. Transactions may, for example, include credit card payments for hotels and restaurants. After spending Francs equivalent of two thousand dollars at the locked-in rate, the end user is subject to the prevailing exchange rate and no longer enjoys the locked-in rate for future transactions.
Fig. 7 is a flowchart illustrating a preferred process for calculating a premium cost. First, central controller 200 stores policy requirements 50 received from the end user, along with the end-user ID number, in policy requirements database 260 (step 700). CPU 205 accesses exchange rate database 275 for the current exchange rate of the currency designated in policy requirements 50 (step 710). This exchange rate is preferably the current interbank rate, which serves as the basis of most global foreign exchange transactions. CPU 205 then accesses exchange rate volatility database 280 for exchange rate volatility data (step 720). Currencies with large volatilities, expressed in terms of standard deviations over a fixed period of time, require a large premium cost due to a greater risk of exchange rate fluctuation.
A premium cost is calculated based on policy requirements 50, the current exchange rate, and exchange rate volatility data (step 730). Therefore, insurance for more volatile currencies requires higher premiums. Also, a coverage period having a start date far from the current date will also necessitate a higher premium as the effect of volatility is magnified over long periods of time. For example, policy requirements 50, indicating two days of coverage beginning five days from today, has a lower premium than the same policy beginning sixty days from now. Additionally, a longer coverage period requires a higher premium. The premium is also directly related to o -the amount of coverage. Policy requirements 50 specifying a locked-in rate that is below current spot exchange rates, however, lowers premium cost because a greater amount of fluctuation may occur before the coverage begins to take effect, thus, reducing the risk to the policy provider. Therefore, the premium cost is a function of policy requirements 50, current exchange rate, and exchange rate volatility. Once calculated, the premium cost is transmitted to the end user (step 740).
Fig. 8 is a flowchart illustrating a preferred process for creating insurance policy 60. The end user evaluates the premium cost transmitted by central controller 200 to decide whether the premium is acceptable (step 800). If the premium is not acceptable to the end user, the end user may develop new policy requirements 50 (step 820). For example, if the premium is too high, the user may lower the amount of coverage or change the period of coverage. Central controller 200 then calculates a new premium based on the modified policy requirements 50 (step 825), as described in connection with Fig. 7.
If the premium is acceptable to the end user (step 810), the user transmits an acceptance to central controller 200, providing confirmation over the phone or other communication channels such as electronic mail, postal mail, or pager (step 830). To bill the user for the premium, central controller 200 may directly debit the user's credit card account or send a separate bill to the user. Next, central controller 200 generates a tracking number and appends it to insurance policy 60 (step 840), and transmits this tracking number to the end user as a confirmation of insurance policy 60 (step 850). If the user desires, central controller 200 also transmits the details of insurance .policy 60 to the end user.
At this point, central controller 200 assigns a "pending" status to the newly created insurance policy 60 (step 855). Central controller 200 stores insurance o w policy 60 in insurance policy database 265 along with its corresponding status (step 860). Later, if the end user satisfies a credit approval process or pays the premium, central controller 200 changes the "pending" status of insurance policy 60 to an "active" status.
Central controller 200 also performs maintenance checks to ensure that only active insurance policy 60 is stored in insurance policy database 265. Fig. 9 is a flowchart illustrating a preferred process for maintaining active insurance policy 60 (Fig. 1). First, central controller 200 makes periodic searches through insurance policy database 265, retrieving the end date of each insurance policy 60 as well as the credit card number (step 900). CPU 205 compares the end date of policy 60 with the current date (step 910).
If the current date is later then the end date of insurance policy 60, central controller 200 changes the status of insurance policy 60 to "expired" (step 920).
Database records for "expired" insurance policies 60 may be deleted from insurance policy database 265 once all claims have been settled with the end user or stored in an audit database for subsequent reference. Additionally, payment processor 230 checks to see whether the credit card number is still valid by contacting a credit card clearinghouse (step 930). If the card number is no longer valid, the status of insurance policy 60 is changed to "expired" (step 940). Otherwise, insurance policy 60 maintenance process is complete (step 950).
Once an active insurance policy 60 is stored in insurance policy database 265, the end-user may execute transactions under insurance policy 60. Fig. 10 is a flowchart illustrating a preferred process for generating transaction data 70 (Fig. 3). As the end user executes foreign currency transactions with the credit card, the data is transmitted to central controller 200 for processing. First, the end user makes a credit card o purchase with the credit card designated in insurance policy 60 (step 1000). For example, the end user buys a bottle of wine in France, providing the merchant the credit card data. The merchant sends transaction data 70, which is the credit card data and the purchase amount, to credit card processing network 420 (step 1010).
The merchant may swipe the credit card through credit card reader 410 to extract credit card information from the magnetic strip on the back of the card, or use some equivalent resource. The merchant then enters the amount of the transaction into a numeric keypad of credit card reader 410. Credit card reader 410, connected to credit card processing network 420 over a dedicated communication line, electronically transmits transaction data 70, and sends transaction data 70 to credit card clearinghouse 430 (step 1020). Credit card clearinghouse 430, operated by the member~banks, functions as a consolidator of credit card transactions, and sends transaction data 70 to central controller 200 in real time or in a batch process (step 1030).
After central controller 200 receives transaction data 70, it processes transaction data 70 under insurance policy 60. Fig. 11 is a flowchart illustrating a preferred process for determining whether an insurance adjustment 80 (Fig. 3) is necessary. First, central controller 200 searches insurance policy database 265 for the credit card number associated with each transaction data 70 received from credit card clearinghouse 430 (step 1100). If the credit card number is not found in insurance policy database 265 (step 1110), no insurance adjustment 80 is necessary because the end user does not have an active policy (step 1120).
If the credit card number is found in insurance policy database 265, the exchange rate associated with transaction data 70 is compared with the locked-in rate specified in insurance policy 60 (step 1130). The exchange rate associated with transaction data 70 is the prevailing spot exchange rate at the time of the transaction. This prevailing exchange rate is retrieved from exchange rate database 270. CPU 205 calculates whether the locked-in rate is more favorable than the prevailing rate on the day of transaction (step 1140).
For example, if the locked-in rate is five Francs per dollar and the prevailing spot rate on the day of the transaction is six Francs per dollar, then the prevailing rate is more favorable. If the prevailing rate is more favorable than the locked-in rate, insurance adjustment 80 is not necessary (step 1150).
If the rate received by the end user is less favorable than the locked-in rate, CPU 205 checks insurance policy database 265 to determine whether the coverage amount has already been used up (step 1160). If the coverage has been used up, insurance adjustment 80 is not necessary (step 1170). For example, insurance policy 60 with a two thousand dollar coverage does not cover insurance adjustment 80 for any transaction beyond the two thousand dollars. If the coverage is not exhausted, insurance adjustment 80 is necessary (step 1180).
Fig. 12 is a flowchart illustrating a preferred process for calculating the amount of insurance adjustment 80. First, central controller 200 calculates the amount of the transaction in domestic currency using the locked-in exchange rate (step 1200). For example, a traveler paying one thousand francs for a hotel room with a locked-in exchange rate of five francs per dollar would have a transaction amount of two hundred dollars.
Next, central controller 200 calculates the transaction amount in domestic currency using the prevailing exchange rate on the day transaction data 70 is received by central controller 200. For example, if the prevailing exchange rate is four francs per dollar when the traveler pays for his hotel room, the cost in dollars o -would be two hundred and fifty. The differential between the two amounts is determined by subtracting the transaction amount at the prevailing rate from the transaction amount at the locked-in rate (step 1220). In the above example, the differential is fifty dollars.
This represents a loss to the traveler due to the drop in exchange rates from five francs to four francs per dollar.
Finally, insurance adjustment 80 is determined by computing the differential corresponding to the remaining amount of coverage under insurance policy 60.
For example, if the traveler has only one hundred dollars of coverage remaining, the differential of fifty dollars is halved to reflect that only half of the two hundred dollar purchase transaction is covered, and the end user is only entitled to insurance adjustment 80 of twenty five dollars. If the end user has a remaining coverage greater than the purchase amount at the locked-in rate, then insurance adjustment 80 is equal to the computed differential. Insurance adjustment 80 is transmitted to the issuing bank of the credit card (step 1230), or stored in end-user account database 290 for later processing until the coverage of insurance policy 60 expires or is used up. Insurance adjustment 80 appears as a credit on the monthly credit card statement of the end user (step 1240). Central controller 200 also updates the remaining amount of coverage in end-user account database 290 (step 1250}.
ATM Implementation The end user can also enjoy a locked-in exchange rate for cash withdrawals from ATMs abroad. The procedure establishing insurance policy 60 is identical to that described above in connection with Figs. 6-8.
Fig. 13 is a flowchart illustrating a preferred process for generating transaction data 70 when the end user withdraws money from an ATM. The end user requests foreign currency from ATM 440 (step 1300). Using the o -numeric keypad of ATM 440, the end user enters the amount of the transaction (step 1310). A traveler in France, for example, withdraws one thousand francs from ATM 440. If the user wants to use the locked-in rate of insurance policy 60, the traveler enters the tracking number of insurance policy 60 into ATM 440 (step 1320). In addition to the amount of withdrawal and tracking number, transaction data 70 includes, for example, the end user's PIN number, the current date, and an ATM identification number. ATM 440 sends transaction data 70 to ATM network 450 using the dedicated communication line of ATM 440.
ATM network 450 relays transaction data 70 to central controller 200 for processing, waiting for a transmission from central controller 200 to provide the appropriate exchange rate (step 1330).
To obtain the appropriate exchange rate, central controller 200 determines whether an insurance adjustment is necessary when the end user withdraws money from an ATM. Referring to Fig. 14, central controller 200 searches insurance policy database 265 for the tracking number received from ATM network 450 (step 1400). If central controller 200 does not find the tracking number in insurance policy database 265 (step 1410), central controller 200 transmits a message to ATM network 450, instructing ATM 440 to issue the cash at the prevailing rate (step 1420).
If the tracking number is found, central controller 200 compares the prevailing exchange rate to the locked-in exchange rate of insurance policy 60 (step 1430). If the exchange rate specified in insurance policy 60 is not more favorable than the prevailing rate (step 1440), ATM 440 is instructed (through ATM network 450) to pay the end user at the prevailing exchange rate (step 1450). This prevents the end user from invoking a claim under insurance policy 60 if the prevailing exchange rate is less favorable or equal to the prevailing rate.
o -If the locked-in exchange rate is more favorable than the prevailing rate, however, central controller 200 accesses end- user account database 290 to check the remaining coverage amount (step 1460). If the coverage has been exhausted, ATM 440 is once again instructed to pay the end user at the prevailing exchange rate (step 1470). If coverage remains, however, central controller 200 determines that insurance adjustment 80 is necessary (step 1480).
After central controller 200 determines that insurance adjustment 80 is necessary, it calculates the amount of insurance adjustment 80 as shown in Fig. 15.
First, central controller 200 determines the remaining amount of coverage (step 1500). Central controller 200 then calculates the foreign exchange differential. In 15 doing so, central controller 200 calculates the amount to be withdrawn in dollars at the locked-in rate (step 1510).
The amount of withdrawal is also calculated in dollars using the prevailing rate at the time of the withdrawal.
Central controller 200 obtains the amount of insurance 20 adjustment 80 as described above in connection with Fig.
14 (step 1520), and updates the remaining amount of coverage in end-user account database 290 (step 1530).
Central controller 200 instructs ATM 440 to present the end user with currencies at the locked-in 25 exchange rate of insurance policy 60 (step 1540). In order to compensate the bank operating ATM 440 for the exchange rate loss associated with the transaction, central controller 200 electronically transfers the amount of currency equal to insurance adjustment 80 to the bank 30 (step 1550).
In an alternative embodiment, the end user's bank transmits the electronic compensation to the bank operating ATM 440. Central controller 200 later reimburses the end user's bank for the amount of insurance 35 adjustment 80.
o _ Bank Implementation In another embodiment of the present invention, the end user enjoys a locked-in exchange rate for currency exchanges at a bank. The procedure establishing insurance policy 60 is described above in connection with Figs. 6-8.
Fig. 16 is a flowchart illustrating a preferred process for generating transaction data 70 by the end user exchanging money at a bank. The end user requests currency exchange at a foreign bank (step 1600), and specifies the amount of transaction (step 1610). For example, a tourist may exchange two hundred dollars into f rancs .
The end user then provides the tracking number of insurance policy 60 (step 1620), enabling bank 460 to verify the exchange rate that the end user demands. Next, bank 460 calls central controller 200 using a conventional telephone (step 1630), and provides transaction data 70 such as end user name, insurance policy 60 tracking number, amount of currency to be exchanged, current exchange rate, and a bank identification number. Bank 460 enters transaction data 70 using a touch-tone telephone or by speaking with an agent (step 1640).
Fig. 17 is a flowchart illustrating a preferred process for determining whether insurance adjustment 80 is necessary. Central controller 200 processes transaction data 70. Central controller 200 searches insurance policy database 265 for the tracking number transmitted by bank 460 (step 1700). If central controller 200 does not find the tracking number in insurance policy database 265 (step 1710), central controller 200 instructs bank 460 to exchange the end user's money at the prevailing exchange rate (step 1720). If the tracking number is found, then the exchange rate provided by bank 460 is compared to the locked-in exchange rate specified in insurance policy 60 (step 1730). If the locked-in rate is not more favorable (step 1740), then central controller 200 instructs bank o 460 to exchange the end user's money at the prevailing exchange rate (step 1750). If the locked-in rate is more favorable, central controller 200 checks the remaining amount of coverage (step 1760). If no coverage remains, central controller 200 instructs bank 460 to exchange the end user's money at the prevailing exchange rate (step 1770). If the coverage is not exhausted, however, insurance adjustment 80 is required (step 1780). Central controller 200 then calculates the amount of insurance adjustment 80 as described above in connection with Fig.
15, and updates the remaining coverage amount in end user account 240.
Offline Implementation All the implementations described above use transaction data 70 transmitted to central controller 200 over electronic networks. The present invention, however, may also employ off-line methods for submitting transaction data 70.
For example, a business traveler on a two week trip in Germany could collect receipts for all of his transactions. Upon returning from the trip, the traveler may mail these receipts to a person who enters the data into central controller 200, which then processes the transaction as described above. Any insurance adjustment 80 required may be mailed to the end user.
Internet Implementation Creation of insurance policy 60 and processing of transaction data 70 can also take place over an electronic network such as the Internet or a commercial online service provider like America Online or CompuServe.
The end user logs on to central controller 200 using a personal computer as end-user interface 300. The procedure establishing insurance policy 60 is similar to that described above in connection with Figs. 6-8. The end user is then able to provide the tracking number as proof of insurance for any electronic commerce conducted o -on the Internet.
For example, the end user accesses a Web site and purchases tickets (denominated in French francs) for an opera in France. The end user provides the credit card number and the tracking number, and the Web site verifies insurance policy 60 with central controller 200. Once verified, the Web site provides the tickets at the locked-in rate specified by insurance policy 60 and receives compensation from central controller 200 for the amount of insurance adjustment 80.
Insurance policy 60 tracking number can also be used in the conversion of digital cash from one currency to another. The end user provides a quantity of digital cash to be converted along with the tracking number of insurance policy 60 to an online bank offering foreign exchange. The bank verifies the validity of insurance policy 60 with central controller 200, and accesses the locked-in exchange rate of insurance policy 60. Assuming the locked-in rate is more favorable and sufficient amount of coverage remains, the bank completes the conversion of funds at the locked-in exchange rate, electronically transferring the new currency back to the end user for storage at end-user interface 300.
Alternatively, this digital money could be transferred to a stored value card, such as a smart card, so the end-user can use the money for transactions away from end-user interface 300. The practice of using digital cash protocols to affect payment is well known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Daniel C.
Lynch and Leslie Lundquist, Digital Money. John Wiley &
Sons (1996); or Seth Godin, Presenting Digital Cash (1995) .
Central controller 200 can also create a digital code incorporating all of the information in insurance policy 60. This digital code is encrypted with a private o -key of central controller 200 and transmitted to the end user. The end user presents this digital code to a bank along with a request for currency exchange. The bank decrypts the digital code with the public key of central controller 200 and extracts all of the details of insurance policy 60, allowing the bank access to the locked-in exchange rate without having to contact central controller 200. The bank is assured that the digital code is legitimate because only central controller 200 has access to the private key that originally encrypted the digital code.
This digital code may also be stored in a smart card. In that case, the end user need only swipe the card through a smart card reader to provide the digital code.
Cryptographic Authentication 15 The system can also provide additional security measures to ensure the integrity of data communications.
One protocol is authenticating authorship of end user communications, i.e., checking an attached ID or name and comparing it with those stored in end-user database 255.
20 Additionally, cryptographic protocols may be added to the authentication process. These protocols enhance the ability to authenticate the sender of a message and verify the integrity of the communication itself, proving that it has not been altered during transmission. Encryption can 25 also prevent eavesdroppers from learning the contents of the communication. Such techniques shall be referred generally as cryptographic assurance methods and will include the use of both symmetric and asymmetric keys as well as digital signatures and hash algorithms.
30 The practice of using cryptographic protocols to ensure the authenticity of senders as well as the integrity of communications is well known in the art and need not be described here in detail. Any conventional cryptographic protocols such as those described in Bruce 35 Schneier, Applied Cryptography) Protocols. Algorithms, and Source Code In C (2d ed. 1996), could be used in accordance with the present invention.
Fig. 18 is a flowchart illustrating an exemplary authentication procedure using symmetric key protocols in which the end user and central controller 200 share a key.
Thus, both encryption and decryption of end user communications are performed with the same key. This encryption may be implemented with an algorithm such as DES (U. S. Government standard, specified in FIPS PUB 46), or with any of several algorithms known in the art such as IDEA, Blowfish, RC4, RC2, and SAFER.
The end user encrypts communications with an assigned symmetric key (step 1800), using cryptographic processor 210 of end-user interface 300. The end user communication is then transmitted to cryptographic processor 210 of central controller 200 (step 1810).
Cryptographic processor 210 extracts the end-user ID from the end-user communication (step 1820), looks up the symmetric key of the end user in cryptographic key database 295 (step 1830), and decrypts end-user communications with this key (step 1840). Cryptographic key database 295 contains algorithms and keys for encrypting, decrypting and/or authenticating communications. If the resulting communication is intelligible, then it is determined to have been encrypted by the same key, thus authenticating the end user as the author of the message (step 1850).
This procedure makes it difficult for unauthorized end users to represent themselves as legitimate end users. Without cryptographic procedures, an unauthorized end user who obtained a sample communication from a legitimate end user may be able to extract the end-user ID and then attach this ID number to unauthorized communications. When end user communications are encrypted with a symmetric key, however, an unauthorized end user obtaining a sample end user WO 98/21680 PCT/US97l20754 o _ communication only discovers the end user's ID number) not the symmetric key. Without this key, the unauthorized end user cannot create an end-user communication that will fool central controller 200, since the unauthorized end user cannot encrypt the communication the same way as the authorized end user. The symmetric key protocol also ensures that the end-user communication has not been tampered with during transmission because alteration of the communication requires knowledge of the symmetric key.
An encrypted end-user communication provides the end user with greater anonymity.
Fig. 19 is a flowchart illustrating an exemplary asymmetric key protocol in which the end-user communication is encrypted with a private key and decrypted with a public key. Two such algorithms for 15 asymmetric key protocols are RSA and DSA. The end user encrypts the communication with a private key using the cryptographic processor of end-user interface 300 (step 1900), and transmits communication to central controller 200 (step 1910). Cryptographic processor 210 extracts the 20 end-user ID (step 1920), and looks up the end user's associated public key in cryptographic key database 295 (step 1930), and decrypts the communication with this public key (step 1940). As before, if the communication is intelligible then central controller 200 has 25 authenticated the end user (step 1950). Again, unauthorized end users obtaining the communication before it is received by central controller 200 are unable to alter it undetectably since the intruders do not know the private key of the end user. Unauthorized end users may, 30 however, be able to read the message if they obtain the public key of the end user. Communication secrecy is preserved if the end user encrypts the communication with the public key, requiring the intruder to know the end user's private key to view the communication.
The present invention provides foreign exchange insurance policies to individuals as well as large corporate entities and offers protection against unpredictable foreign exchange rate fluctuations.
Additionally, the present invention provides a way of automatically processing transactions covered by the foreign exchange insurance policies.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention and in construction of the invention without departing from the scope or spirit of the invention. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification and examples should be considered as exemplary only, with the true scope and spirit of the invention indicated by the following claims.
Claims (64)
1. A method of providing a foreign exchange insurance policy comprising the steps, performed by a data processor, of:
receiving from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
storing the policy requirements and the corresponding user ID;
accessing data corresponding to the specified currency and current market conditions;
estimating currency volatility from the accessed data; and determining a premium cost based on the currency volatility.
receiving from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
storing the policy requirements and the corresponding user ID;
accessing data corresponding to the specified currency and current market conditions;
estimating currency volatility from the accessed data; and determining a premium cost based on the currency volatility.
2. The method of claim 1 further including the step of issuing a tracking code for the foreign exchange insurance policy.
3. The method of claim 2 further including the step of storing the tracking code corresponding to the user ID.
4. The method of claim 2 wherein the step of issuing a tracking code includes the substep of issuing the tracking code with the policy requirements.
5. The method of claim 4 wherein the step of issuing the tracking code includes the step of encrypting the tracking code.
6. The method of claim 1 including the step of transmitting the premium cost to the user.
7. The method of claim 6 including the step of receiving from the user a confirmation to purchase the foreign exchange insurance policy.
8. The method of claim 1 wherein the policy requirements further include a specified currency, an exchange rate, an amount of coverage, and a period of coverage, and wherein the determining step further includes the substep of determining the premium cost based on the policy requirements and the currency volatility.
9. The method of claim 1 wherein the step of accessing the data includes the substep of accessing historic exchange rates.
10. The method of claim 1 further including the steps of accessing a period of coverage of the foreign exchange insurance policies, and determining whether the period of coverage has expired.
11. The method of claim 8 further including the step of updating the status of the foreign exchange insurance policies having an expired coverage period.
12. The method of claim 1 wherein the step of receiving the policy requirement includes the substep of receiving a credit card number as the user ID.
13. The method of claim 1 wherein the receiving step includes the substep of authenticating the identity of the user.
14. The method of claim 1 wherein the receiving step includes the substeps of receiving encrypted user policy requirements, and decrypting the encrypted user policy requirements.
15. A method of processing a foreign currency transaction under a foreign exchange insurance policy comprising the steps, performed by a data processor, of:
receiving transaction data including a user ID, a transaction amount, and a transaction date;
accessing a foreign exchange rate corresponding to the transaction date;
accessing a policy exchange rate corresponding to the user ID;
comparing the foreign exchange rate of the transaction date with the policy exchange rate; and determining the amount of insurance adjustment using the transaction data and the compared exchange rates.
receiving transaction data including a user ID, a transaction amount, and a transaction date;
accessing a foreign exchange rate corresponding to the transaction date;
accessing a policy exchange rate corresponding to the user ID;
comparing the foreign exchange rate of the transaction date with the policy exchange rate; and determining the amount of insurance adjustment using the transaction data and the compared exchange rates.
16. The method of claim 15 including the step of verifying the validity of the user ID.
17. The method of claim 15 including the step of crediting a user's account by the amount of the determined insurance adjustment.
18. The method of claim 17 wherein the crediting step includes the substeps of accessing a remaining amount of coverage, and determining whether the remaining amount of coverage exceeds the transaction amount.
19. The method of claim 15 wherein the receiving step includes the substep of receiving the transaction data from an automatic teller machine.
20. The method of claim 15 wherein the receiving step includes the substep of receiving the transaction data from a bank terminal.
21. The method of claim 15 wherein the receiving step includes the substep of receiving the transaction data from a server on a computer network.
22. A method of processing a foreign currency credit card transaction under a foreign exchange insurance policy comprising the steps, performed by a data processor, of:
receiving transaction data including a user ID, a credit card number, transaction amount, and a transaction date;
verifying the validity of the credit card number;
accessing a foreign exchange rate corresponding to the transaction date;
accessing a policy exchange rate corresponding to the user ID;
comparing the foreign exchange rate of the transaction date with the policy exchange rate; and determining the amount of insurance adjustment using the transaction data and the compared exchange rates.
receiving transaction data including a user ID, a credit card number, transaction amount, and a transaction date;
verifying the validity of the credit card number;
accessing a foreign exchange rate corresponding to the transaction date;
accessing a policy exchange rate corresponding to the user ID;
comparing the foreign exchange rate of the transaction date with the policy exchange rate; and determining the amount of insurance adjustment using the transaction data and the compared exchange rates.
23. The method of claim 22 including the step of crediting a user's credit card account corresponding to the verified credit card number by the amount of insurance adjustment.
24. The method of claim 23 wherein the crediting step includes the substeps of accessing a remaining amount of coverage, and determining whether the remaining amount of coverage exceeds the transaction amount.
25. The method of claim 22 wherein the accessing step further includes the substep of accessing the foreign exchange rate from an external source separate from the data processor.
26. A method of controlling information transfer between a data processor and a central controller for a foreign exchange insurance policy comprising the steps, performed by the data processor, of:
receiving from a user a transaction request;
receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
transmitting the transaction data to the central controller;
receiving from the central controller instructions for processing the transaction request; and processing the transaction request according to the received instructions.
receiving from a user a transaction request;
receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
transmitting the transaction data to the central controller;
receiving from the central controller instructions for processing the transaction request; and processing the transaction request according to the received instructions.
27. The method of claim 26 wherein the step of receiving transaction data includes the substep of receiving a user ID, a transaction amount, and a transaction date.
28. The method of claim 26 wherein the step of receiving instructions includes the substep of receiving an appropriate currency exchange rate under the foreign exchange insurance policy.
29. A method of controlling information transfer between an automatic teller machine (ATM) and a central controller for a foreign exchange insurance policy comprising the steps, performed by the ATM, of:
receiving from a user a transaction request;
receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
transmitting the transaction data to the central controller;
receiving from the central controller instructions for processing the transaction request; and processing the transaction request according to the received instructions.
receiving from a user a transaction request;
receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
transmitting the transaction data to the central controller;
receiving from the central controller instructions for processing the transaction request; and processing the transaction request according to the received instructions.
30. The method of claim 29 wherein the step of receiving transaction data includes the substep of receiving a user ID, a transaction amount, and a transaction date.
31. The method of claim 29 wherein the step of receiving instructions includes the substep of receiving an appropriate currency exchange rate under the foreign exchange insurance policy.
32. A system for providing a foreign exchange insurance policy comprising:
means for receiving from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
a database storing the policy requirements and the corresponding user ID;
means for accessing data corresponding to the specified currency and current market conditions;
means for estimating currency volatility from the accessed data; and means for determining a premium cost based on the currency volatility.
means for receiving from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
a database storing the policy requirements and the corresponding user ID;
means for accessing data corresponding to the specified currency and current market conditions;
means for estimating currency volatility from the accessed data; and means for determining a premium cost based on the currency volatility.
33. The system of claim 32 further including first issuing means for issuing a tracking code for the foreign exchange insurance policy.
34. The system of claim 33 wherein the database further stores the tracking code corresponding to the user id.
35. The system of claim 33 wherein the first issuing means includes second issuing means for issuing a tracking code with policy requirements.
36. The system of claim 35 wherein the first issuing means includes means for encrypting the tracking code.
37. The system of claim 32 further including means for transmitting the computed premium cost to the user.
3s. The system of claim 37 further including means for receiving from the user a confirmation to purchase the foreign exchange insurance policy.
39. The system of claim 32 wherein the policy requirements further include a specified currency, exchange rate, amount of coverage, and a period of coverage, and wherein the determining means further includes means for determining the premium cost based on the policy requirements and the currency volatility.
40. The system of claim 32 wherein the accessing means further include means for accessing historic exchange rates.
41. The system of claim 32 further including means for accessing from the database the period of coverage of the foreign exchange insurance policies, and means for determining whether the period of coverage has expired.
42. The system of claim 41 further including means for updating the status of the foreign exchange insurance policies having an expired coverage period.
43. The system of claim 32 wherein the receiving means includes means for receiving a credit card number as the user ID.
44. The system of claim 32 wherein the receiving means includes means for authenticating the identity of the user.
45. The system of claim 32 wherein the receiving means includes means for receiving encrypted user policy requirements, and means for decrypting the encrypted user policy requirements.
46. A system for processing a foreign currency transaction under a foreign exchange insurance policy comprising:
means for receiving transaction data including a user id, a transaction amount, and a transaction date;
first accessing means for accessing a foreign exchange rate corresponding to the transaction date;
second accessing means for accessing a policy exchange rate corresponding to the user ID;
means for comparing the foreign exchange rate of the transaction date with the policy exchange rate; and means for determining the amount of appropriate insurance adjustment using the transaction data and the compared exchange rates.
means for receiving transaction data including a user id, a transaction amount, and a transaction date;
first accessing means for accessing a foreign exchange rate corresponding to the transaction date;
second accessing means for accessing a policy exchange rate corresponding to the user ID;
means for comparing the foreign exchange rate of the transaction date with the policy exchange rate; and means for determining the amount of appropriate insurance adjustment using the transaction data and the compared exchange rates.
47. The system of claim 46 including means for verifying the validity of the user ID.
48. The system of claim 46 including means for crediting the user's account by the amount of insurance adjustment.
49. The system of claim 48 wherein the crediting means includes third accessing means for accessing a remaining amount of coverage, and means for determining whether the remaining amount of coverage exceeds the transaction amount.
50. The system of claim 46 wherein the receiving means receives the transaction data from an automatic teller machine.
51. The system of claim 46 wherein the receiving means receives the transaction data from a bank terminal.
52. The system of claim 46 wherein the receiving means receives the transaction data from a server on a computer network.
53. A system of processing a foreign currency credit card transaction under a foreign exchange insurance policy comprising:
means for receiving transaction data including a user ID, a credit card number, a transaction amount, and a transaction date;
means for verifying the validity of the credit card number;
fixst accessing means for accessing a foreign exchange rate corresponding to the transaction date;
second accessing means for accessing a policy exchange rate corresponding to the user ID;
means for comparing the foreign exchange rate of the transaction date with the policy exchange rate; and means for determining the amount of insurance adjustment using the transaction data and the compared exchange rates.
means for receiving transaction data including a user ID, a credit card number, a transaction amount, and a transaction date;
means for verifying the validity of the credit card number;
fixst accessing means for accessing a foreign exchange rate corresponding to the transaction date;
second accessing means for accessing a policy exchange rate corresponding to the user ID;
means for comparing the foreign exchange rate of the transaction date with the policy exchange rate; and means for determining the amount of insurance adjustment using the transaction data and the compared exchange rates.
54. The system of claim 53 including means for crediting the user's credit card account corresponding to the verified credit card number by the amount of insurance adjustment.
55. The system of claim 54 wherein the crediting means includes third accessing means for accessing a remaining amount of coverage, and means for determining whether the remaining amount of coverage exceeds the transaction amount.
56. The system of claim 53 wherein the first accessing means includes fourth accessing means for accessing the foreign exchange rate from an external source separate from the data processor.
57. A system for controlling information transfer between the system and a central controller for a foreign exchange insurance policy comprising:
first receiving means for receiving from a user a transaction request;
second receiving means for receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
means for transmitting the transaction data to the central controller;
third receiving means for receiving from the central controller instructions for processing the transaction request; and means for processing the transaction request according to the received instructions.
first receiving means for receiving from a user a transaction request;
second receiving means for receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
means for transmitting the transaction data to the central controller;
third receiving means for receiving from the central controller instructions for processing the transaction request; and means for processing the transaction request according to the received instructions.
58. The system of claim 57 wherein the second receiving means includes fourth receiving means for receiving a user ID, a transaction amount, and a transaction date.
59. The system of claim 57 wherein the third receiving means includes fifth receiving means for receiving an appropriate currency exchange rate under the foreign exchange insurance policy.
60. An automatic teller machine (ATM) for controlling information transfer between the ATM and a central controller for a foreign exchange insurance policy comprising:
first receiving means for receiving from a user a transaction request;
second receiving means for receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
means for transmitting the transaction data to the central controller;
third receiving means for receiving from the central controller instructions for processing the transaction request; and means for processing the transaction request according to the received instructions.
first receiving means for receiving from a user a transaction request;
second receiving means for receiving from the user transaction data including a tracking number of the foreign exchange insurance policy;
means for transmitting the transaction data to the central controller;
third receiving means for receiving from the central controller instructions for processing the transaction request; and means for processing the transaction request according to the received instructions.
61. The system of claim 60 wherein the second receiving means includes fourth receiving means for receiving a user ID, a transaction amount, and a transaction date.
62. The system of claim 60 wherein the third receiving means includes fifth receiving means for receiving an appropriate currency exchange rate under the foreign exchange insurance policy.
63. A computer-readable medium for providing a foreign exchange insurance policy comprising:
means for causing a data processor to receive from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
means for causing a database to store the policy requirements and the corresponding user ID;
means for causing a data processor to access data corresponding to the specified currency and current market conditions;
means for causing a data processor to estimate currency volatility from the accessed data; and means for causing a data processor to determine a premium cost based on the currency volatility.
means for causing a data processor to receive from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
means for causing a database to store the policy requirements and the corresponding user ID;
means for causing a data processor to access data corresponding to the specified currency and current market conditions;
means for causing a data processor to estimate currency volatility from the accessed data; and means for causing a data processor to determine a premium cost based on the currency volatility.
64. An article of manufacture capable of configuring a data processor to perform a method of providing a foreign exchange insurance policy comprising the steps of:
receiving from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
storing the policy requirements and the corresponding user ID;
accessing data corresponding to the specified currency and current market conditions;
estimating currency volatility from the accessed data; and determining a premium cost based on the currency volatility.
receiving from a user policy requirements for the foreign exchange insurance policy, the policy requirements including a user ID;
storing the policy requirements and the corresponding user ID;
accessing data corresponding to the specified currency and current market conditions;
estimating currency volatility from the accessed data; and determining a premium cost based on the currency volatility.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/749,241 | 1996-11-15 | ||
US08/749,241 US5884274A (en) | 1996-11-15 | 1996-11-15 | System and method for generating and executing insurance policies for foreign exchange losses |
PCT/US1997/020754 WO1998021680A1 (en) | 1996-11-15 | 1997-11-13 | System and method for generating and executing insurance policies for foreign exchange losses |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2276243A1 true CA2276243A1 (en) | 1998-05-22 |
Family
ID=25012889
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002276243A Abandoned CA2276243A1 (en) | 1996-11-15 | 1997-11-13 | System and method for generating and executing insurance policies for foreign exchange losses |
Country Status (6)
Country | Link |
---|---|
US (2) | US5884274A (en) |
EP (1) | EP1016011A4 (en) |
JP (1) | JP2000509859A (en) |
AU (1) | AU5256898A (en) |
CA (1) | CA2276243A1 (en) |
WO (1) | WO1998021680A1 (en) |
Families Citing this family (247)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5794221A (en) | 1995-07-07 | 1998-08-11 | Egendorf; Andrew | Internet billing method |
US5884274A (en) * | 1996-11-15 | 1999-03-16 | Walker Asset Management Limited Partnership | System and method for generating and executing insurance policies for foreign exchange losses |
US8914410B2 (en) * | 1999-02-16 | 2014-12-16 | Sonicwall, Inc. | Query interface to policy server |
US7580919B1 (en) | 1997-03-10 | 2009-08-25 | Sonicwall, Inc. | Query interface to policy server |
US6408336B1 (en) | 1997-03-10 | 2002-06-18 | David S. Schneider | Distributed administration of access to information |
US7272625B1 (en) * | 1997-03-10 | 2007-09-18 | Sonicwall, Inc. | Generalized policy server |
US7821926B2 (en) | 1997-03-10 | 2010-10-26 | Sonicwall, Inc. | Generalized policy server |
US7912856B2 (en) * | 1998-06-29 | 2011-03-22 | Sonicwall, Inc. | Adaptive encryption |
JP3060996B2 (en) * | 1997-05-30 | 2000-07-10 | 日本電気株式会社 | Wireless data communication device |
JPH1166193A (en) * | 1997-08-14 | 1999-03-09 | Hitachi Ltd | Method and device for managing electronic money and storage medium where electronic money managing program is stored |
JP3634131B2 (en) * | 1997-12-25 | 2005-03-30 | 富士通株式会社 | Method for obtaining management reference date in production management system, production management system, and recording medium |
US6721715B2 (en) * | 1998-03-30 | 2004-04-13 | Martin A. Nemzow | Method and apparatus for localizing currency valuation independent of the original and objective currencies |
US6615189B1 (en) | 1998-06-22 | 2003-09-02 | Bank One, Delaware, National Association | Debit purchasing of stored value card for use by and/or delivery to others |
US7809642B1 (en) | 1998-06-22 | 2010-10-05 | Jpmorgan Chase Bank, N.A. | Debit purchasing of stored value card for use by and/or delivery to others |
US6138102A (en) * | 1998-07-31 | 2000-10-24 | Ace Limited | System for preventing cash flow losses |
AU5547799A (en) * | 1998-08-03 | 2000-02-28 | Trustees Of Columbia University In The City Of New York, The | Instrumentalities for insuring and hedging against risk |
US6163770A (en) * | 1998-08-25 | 2000-12-19 | Financial Growth Resources, Inc. | Computer apparatus and method for generating documentation using a computed value for a claims cost affected by at least one concurrent, different insurance policy for the same insured |
US7660763B1 (en) | 1998-11-17 | 2010-02-09 | Jpmorgan Chase Bank, N.A. | Customer activated multi-value (CAM) card |
US6032136A (en) | 1998-11-17 | 2000-02-29 | First Usa Bank, N.A. | Customer activated multi-value (CAM) card |
US6182048B1 (en) * | 1998-11-23 | 2001-01-30 | General Electric Company | System and method for automated risk-based pricing of a vehicle warranty insurance policy |
US6944595B1 (en) * | 1999-03-25 | 2005-09-13 | International Business Machines Corporation | Apparatus and method for performing conversion between different units of currency using an encapsulated conversion path of exchange rates |
US7979382B2 (en) | 1999-05-04 | 2011-07-12 | Accenture Global Services Limited | Component based information linking during claim processing |
US6227447B1 (en) * | 1999-05-10 | 2001-05-08 | First Usa Bank, Na | Cardless payment system |
US6882984B1 (en) | 1999-06-04 | 2005-04-19 | Bank One, Delaware, National Association | Credit instrument and system with automated payment of club, merchant, and service provider fees |
US8862507B2 (en) * | 1999-06-14 | 2014-10-14 | Integral Development Corporation | System and method for conducting web-based financial transactions in capital markets |
US7882011B2 (en) * | 2000-10-31 | 2011-02-01 | Integral Development Corp. | Systems and methods of conducting financial transactions |
AU5496100A (en) * | 1999-06-18 | 2001-01-09 | Thomson Financial Inc. | System, method and computer readable medium containing instructions for evaluating and disseminating investor performance information |
US7016872B1 (en) | 1999-06-18 | 2006-03-21 | Thomson Financial Inc. | System, method and computer readable medium containing instructions for evaluating and disseminating investor performance information |
US7058817B1 (en) * | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
IES990584A2 (en) * | 1999-07-12 | 2000-07-12 | Mainline Corporate Holdings | Dynamic currency conversion for card payment systems |
US7124088B2 (en) | 1999-07-30 | 2006-10-17 | Progressive Casualty Insurance Company | Apparatus for internet on-line insurance policy service |
US20080243721A1 (en) * | 1999-08-24 | 2008-10-02 | Raymond Anthony Joao | Apparatus and method for providing financial information and/or investment information |
US7711646B2 (en) | 1999-09-10 | 2010-05-04 | Transurety, Llc | Methods and apparatus for providing coverage for receiver of transmission data |
US7693731B1 (en) | 1999-09-30 | 2010-04-06 | Computer Sciences Corporation | Business process framework for reinsurance |
US7359863B1 (en) | 1999-09-30 | 2008-04-15 | Computer Sciences Corporation | Condition component framework for reinsurance |
US7047219B1 (en) | 1999-10-04 | 2006-05-16 | Trade Finance Systems, Inc. | Trade finance automation system |
EP1093066A1 (en) * | 1999-10-12 | 2001-04-18 | Impact Business & Technology Consulting GmbH | Method for hedging the risks of e-commerce businesses |
EP1093071A1 (en) * | 1999-10-12 | 2001-04-18 | Impact Business & Technology Consulting GmbH | Method for hedging the risks of e-commerce businesses |
US7337142B1 (en) * | 1999-10-27 | 2008-02-26 | Sun Microsystems, Inc. | Multiple exchange rate tracking in a financial transaction manager |
WO2001033477A2 (en) | 1999-11-04 | 2001-05-10 | Jpmorgan Chase Bank | System and method for automated financial project management |
US7370004B1 (en) | 1999-11-15 | 2008-05-06 | The Chase Manhattan Bank | Personalized interactive network architecture |
US10275780B1 (en) | 1999-11-24 | 2019-04-30 | Jpmorgan Chase Bank, N.A. | Method and apparatus for sending a rebate via electronic mail over the internet |
US8571975B1 (en) | 1999-11-24 | 2013-10-29 | Jpmorgan Chase Bank, N.A. | System and method for sending money via E-mail over the internet |
US7383233B1 (en) * | 1999-12-03 | 2008-06-03 | General Electric Company | Method of designing an electronic transaction system |
US8793160B2 (en) | 1999-12-07 | 2014-07-29 | Steve Sorem | System and method for processing transactions |
US7565311B2 (en) * | 1999-12-16 | 2009-07-21 | Sumitomo Mitsui Banking Corporation | Conversion engine and financial reporting system using the conversion engine |
US6571236B1 (en) | 2000-01-10 | 2003-05-27 | General Electric Company | Method and apparatus for problem diagnosis and solution |
US7246087B1 (en) | 2000-01-10 | 2007-07-17 | General Electric Company | Method and apparatus for product selection assistance |
US7024383B1 (en) | 2000-01-31 | 2006-04-04 | Goldman, Sachs & Co. | Online sales risk management system |
US6941279B1 (en) | 2000-02-23 | 2005-09-06 | Banke One Corporation | Mutual fund card method and system |
US7979347B1 (en) * | 2000-03-16 | 2011-07-12 | Goldman Sachs & Co. | Automated online sales risk management |
MXPA01012506A (en) * | 2000-04-05 | 2002-07-30 | American Express Travel Relate | Interactive demand management. |
GB2379064A (en) * | 2000-04-14 | 2003-02-26 | Vantage Internat Inc E | Method and system for delivering foreign exchange risk management advisory solutions to a designated market |
US20010032094A1 (en) * | 2000-04-21 | 2001-10-18 | Swarupanda Ghosh | System and method for managing licensing information |
AU2001259391A1 (en) * | 2000-05-03 | 2001-11-12 | Shelton E. Harrison Jr. | Electronic bond and guaranty process and business method |
KR20010106015A (en) * | 2000-05-20 | 2001-11-29 | 정훈 | Apparatus for automatic exchanging money and method for exchange the same |
US7143051B1 (en) | 2000-05-24 | 2006-11-28 | Jefferson Pilot Financial Insurance Company | Method and system for quoting, issuing, and administering insurance policies including determining whether insurance policies are self bill or list bill |
IL152975A0 (en) * | 2000-05-31 | 2003-06-24 | American Int Group Inc | Method and system for foreign exchange price procurement and automated hedging |
US7426530B1 (en) | 2000-06-12 | 2008-09-16 | Jpmorgan Chase Bank, N.A. | System and method for providing customers with seamless entry to a remote server |
US20020046065A1 (en) * | 2000-06-15 | 2002-04-18 | Nighan Robert J. | Method and system for insuring against loss in connection with an online financial transaction |
US20070038523A1 (en) * | 2000-06-19 | 2007-02-15 | E4X Inc. | System and method for transactional hedging |
US6892184B1 (en) | 2000-06-19 | 2005-05-10 | E4X Inc. | System and method for multiple currency transactions |
US10185936B2 (en) | 2000-06-22 | 2019-01-22 | Jpmorgan Chase Bank, N.A. | Method and system for processing internet payments |
CA2312275C (en) * | 2000-06-23 | 2009-09-15 | Namsys Inc. | Currency receiving device and method |
US7095426B1 (en) | 2000-06-23 | 2006-08-22 | Computer Sciences Corporation | Graphical user interface with a hide/show feature for a reference system in an insurance claims processing system |
US7398219B1 (en) | 2000-06-23 | 2008-07-08 | Computer Sciences Corporation | System and method for displaying messages using a messages table |
US7343307B1 (en) | 2000-06-23 | 2008-03-11 | Computer Sciences Corporation | Dynamic help method and system for an insurance claims processing system |
US7418400B1 (en) | 2000-06-23 | 2008-08-26 | Computer Sciences Corporation | Internet-enabled system and method for assessing damages |
US7430514B1 (en) | 2000-06-23 | 2008-09-30 | Computer Sciences Corporation | System and method for processing insurance claims using a table of contents |
US7571107B1 (en) | 2000-06-23 | 2009-08-04 | Computer Sciences Corporation | System and method for externalization of rules for assessing damages |
US7430515B1 (en) | 2000-06-23 | 2008-09-30 | Computer Sciences Corporation | System and method for externalization of formulas for assessing damages |
US20020091550A1 (en) * | 2000-06-29 | 2002-07-11 | White Mitchell Franklin | System and method for real-time rating, underwriting and policy issuance |
US7925566B1 (en) | 2000-07-17 | 2011-04-12 | Ubs Financial Services, Inc. | System and method for trading fixed income financial instruments |
WO2002011019A1 (en) | 2000-08-01 | 2002-02-07 | First Usa Bank, N.A. | System and method for transponder-enabled account transactions |
US20020072936A1 (en) * | 2000-08-08 | 2002-06-13 | Newman Jeffrey Marc | Children's income protection and benefit health insurance policy and method of underwriting the same |
US7925523B1 (en) | 2000-09-11 | 2011-04-12 | Safeco Corporation | Method and system for providing insurance policies via a distributed computing network |
US8335855B2 (en) | 2001-09-19 | 2012-12-18 | Jpmorgan Chase Bank, N.A. | System and method for portal infrastructure tracking |
US7246263B2 (en) * | 2000-09-20 | 2007-07-17 | Jpmorgan Chase Bank | System and method for portal infrastructure tracking |
US6952683B1 (en) * | 2000-10-11 | 2005-10-04 | Ubs Ag | System and method for hedging against foreign exchange risk associated with securities transactions |
EP1197887A1 (en) * | 2000-10-11 | 2002-04-17 | Ubs Ag | Computer system and method for hedging a currency exchange rate risk |
US7672893B1 (en) | 2000-10-16 | 2010-03-02 | Ubs Financial Services, Inc. | System and method for trading taxable and non-taxable securities |
US20020082871A1 (en) * | 2000-10-30 | 2002-06-27 | Ted Younger | System and method for providing online insurance information |
US11526940B2 (en) | 2000-10-31 | 2022-12-13 | Integral Development Corporation | System and method for conducting web-based financial transactions in capital markets |
AU2001296667A1 (en) * | 2000-11-09 | 2002-05-21 | Macrovision Corporation | Method and apparatus for determining digital a/v content distribution terms based on detected piracy levels |
US20020082874A1 (en) * | 2000-11-22 | 2002-06-27 | Re2Re.Com Limited, Incorporated | Electronic procurement system and method for trading and exchange by insurers, reinsurers and brokers of risks and capacities |
US7047227B2 (en) * | 2000-12-22 | 2006-05-16 | Voxage, Ltd. | Interface between vendors and customers that uses intelligent agents |
US20020082912A1 (en) * | 2000-12-22 | 2002-06-27 | Leon Batachia | Transactions between vendors and customers using push/pull model |
US6985873B2 (en) | 2001-01-18 | 2006-01-10 | First Usa Bank, N.A. | System and method for administering a brokerage rebate card program |
US8121871B2 (en) | 2001-01-26 | 2012-02-21 | Genworth Financial, Inc. | System, method and software application for accessing and processing information |
US7953636B2 (en) | 2001-02-21 | 2011-05-31 | Genworth Financial, Inc. | System and method for providing customized sales-related data over a network |
US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
US7720736B2 (en) * | 2001-05-04 | 2010-05-18 | B.G. Yolles & Co. | Method and system for insuring against investment loss |
US8306897B2 (en) | 2001-05-04 | 2012-11-06 | Stockshield, Inc. | Method and system for insuring against investment loss |
US8229827B2 (en) * | 2001-05-04 | 2012-07-24 | Stockshield, Inc. | Method and system for insuring against investment loss |
US7739177B2 (en) * | 2002-02-12 | 2010-06-15 | Stockshield, Inc. | Method and system for insuring against investment loss |
US20050060207A1 (en) * | 2001-05-08 | 2005-03-17 | Weidner James L. | Claims paid insurance |
AU2002305408A1 (en) * | 2001-05-08 | 2002-11-18 | Cooperative Of American Physicians, Inc | Property/casual insurance and techniques |
US20020169727A1 (en) * | 2001-05-11 | 2002-11-14 | Express Scripts, Inc | System and method for benefit cost plan estimation |
US7313546B2 (en) | 2001-05-23 | 2007-12-25 | Jp Morgan Chase Bank, N.A. | System and method for currency selectable stored value instrument |
US7401049B2 (en) * | 2001-05-29 | 2008-07-15 | American Express Travel Related Services Company, Inc. | System and method for a prepaid card issued by a foreign financial institution |
US7899742B2 (en) * | 2001-05-29 | 2011-03-01 | American Express Travel Related Services Company, Inc. | System and method for facilitating a subsidiary card account |
AU2002312381A1 (en) | 2001-06-07 | 2002-12-16 | First Usa Bank, N.A. | System and method for rapid updating of credit information |
US20020198779A1 (en) * | 2001-06-22 | 2002-12-26 | Michael Rowen | System and method for awarding participants in a marketing plan |
US20020198814A1 (en) * | 2001-06-22 | 2002-12-26 | International Business Machines Corporation | Online e-commerce transactions incorporating determination of end-to-end costs |
US20030018576A1 (en) * | 2001-06-25 | 2003-01-23 | Bomazu, Llc | Risk evaluation system and method |
US7483857B2 (en) * | 2001-07-09 | 2009-01-27 | International Business Machines Corporation | Online e-commerce transactions incorporating effects of uncertainty and risk factors |
US7266839B2 (en) * | 2001-07-12 | 2007-09-04 | J P Morgan Chase Bank | System and method for providing discriminated content to network users |
WO2003010701A1 (en) | 2001-07-24 | 2003-02-06 | First Usa Bank, N.A. | Multiple account card and transaction routing |
US7809641B2 (en) | 2001-07-26 | 2010-10-05 | Jpmorgan Chase Bank, National Association | System and method for funding a collective account |
WO2003012598A2 (en) * | 2001-08-02 | 2003-02-13 | American Express Travel Related Services Company, Inc. | System and method for the interactive trading of derivatives |
US8020754B2 (en) | 2001-08-13 | 2011-09-20 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
US7311244B1 (en) | 2001-08-13 | 2007-12-25 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
US8800857B1 (en) | 2001-08-13 | 2014-08-12 | Jpmorgan Chase Bank, N.A. | System and method for crediting loyalty program points and providing loyalty rewards by use of an electronic tag |
JP4378064B2 (en) * | 2001-08-29 | 2009-12-02 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Transaction monitoring method, transaction monitoring system, and recording medium |
JP2003168002A (en) * | 2001-09-18 | 2003-06-13 | Nec Corp | Method and system for contracting insurance, portable terminal and insurance contract program |
US7103576B2 (en) | 2001-09-21 | 2006-09-05 | First Usa Bank, Na | System for providing cardless payment |
JP2003111889A (en) * | 2001-10-02 | 2003-04-15 | Aruze Corp | Game server, game machine and game managing method |
JP2003111888A (en) * | 2001-10-02 | 2003-04-15 | Aruze Corp | Game server, game machine and game managing method |
US8025563B2 (en) * | 2001-10-02 | 2011-09-27 | Universal Entertainment Corporation | Gaming machine |
US20080318657A2 (en) * | 2001-10-02 | 2008-12-25 | Aruze Corporation | Gaming machine |
US7887410B2 (en) * | 2001-10-02 | 2011-02-15 | Universal Entertainment Corporation | Gaming machine |
US8021225B2 (en) * | 2001-10-02 | 2011-09-20 | Universal Entertainment Corporation | Gaming machine |
JP2003117053A (en) * | 2001-10-12 | 2003-04-22 | Aruze Corp | Game server, game managing method and game machine |
JP2003111890A (en) * | 2001-10-05 | 2003-04-15 | Aruze Corp | Game server, game managing method and game machine |
JP2003111897A (en) * | 2001-10-09 | 2003-04-15 | Aruze Corp | Game server, game machine, game managing server and game managing method |
US20050262013A1 (en) * | 2001-10-16 | 2005-11-24 | Guthner Mark W | System and method for analyzing risk and profitability of non-recourse loans |
JP2003126343A (en) * | 2001-10-22 | 2003-05-07 | Aruze Corp | Game server, game machine and game managing method |
US7047565B2 (en) * | 2001-10-31 | 2006-05-16 | International Business Machines Corporation | Method and system for capturing in-service date information |
CA2466071C (en) | 2001-11-01 | 2016-04-12 | Bank One, Delaware, N.A. | System and method for establishing or modifying an account with user selectable terms |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US7895062B2 (en) | 2001-12-31 | 2011-02-22 | Genworth Financial, Inc. | System for optimization of insurance underwriting suitable for use by an automated system |
US7630910B2 (en) * | 2001-12-31 | 2009-12-08 | Genworth Financial, Inc. | System for case-based insurance underwriting suitable for use by an automated system |
US7844477B2 (en) * | 2001-12-31 | 2010-11-30 | Genworth Financial, Inc. | Process for rule-based insurance underwriting suitable for use by an automated system |
US7818186B2 (en) * | 2001-12-31 | 2010-10-19 | Genworth Financial, Inc. | System for determining a confidence factor for insurance underwriting suitable for use by an automated system |
US20030182159A1 (en) * | 2001-12-31 | 2003-09-25 | Bonissone Piero Patrone | Process for summarizing information for insurance underwriting suitable for use by an automated system |
US8793146B2 (en) | 2001-12-31 | 2014-07-29 | Genworth Holdings, Inc. | System for rule-based insurance underwriting suitable for use by an automated system |
US7844476B2 (en) * | 2001-12-31 | 2010-11-30 | Genworth Financial, Inc. | Process for case-based insurance underwriting suitable for use by an automated system |
US20030177032A1 (en) * | 2001-12-31 | 2003-09-18 | Bonissone Piero Patrone | System for summerizing information for insurance underwriting suitable for use by an automated system |
US8005693B2 (en) * | 2001-12-31 | 2011-08-23 | Genworth Financial, Inc. | Process for determining a confidence factor for insurance underwriting suitable for use by an automated system |
US7899688B2 (en) | 2001-12-31 | 2011-03-01 | Genworth Financial, Inc. | Process for optimization of insurance underwriting suitable for use by an automated system |
US6811078B2 (en) * | 2002-01-17 | 2004-11-02 | Monica L. Workens | Point-of-transaction machine with improved versatility and related method |
US7941533B2 (en) * | 2002-02-19 | 2011-05-10 | Jpmorgan Chase Bank, N.A. | System and method for single sign-on session management without central server |
US20030167231A1 (en) * | 2002-03-04 | 2003-09-04 | First Data Corporation | Method and system for processing credit card payments |
US7756896B1 (en) | 2002-03-11 | 2010-07-13 | Jp Morgan Chase Bank | System and method for multi-dimensional risk analysis |
WO2003083753A1 (en) * | 2002-03-22 | 2003-10-09 | Bloomberg Lp | Variable pricing for and conditional availability of proposals for trading of financial interests |
US7899753B1 (en) | 2002-03-25 | 2011-03-01 | Jpmorgan Chase Bank, N.A | Systems and methods for time variable financial authentication |
US20180165441A1 (en) | 2002-03-25 | 2018-06-14 | Glenn Cobourn Everhart | Systems and methods for multifactor authentication |
US20040210498A1 (en) | 2002-03-29 | 2004-10-21 | Bank One, National Association | Method and system for performing purchase and other transactions using tokens with multiple chips |
US8751391B2 (en) | 2002-03-29 | 2014-06-10 | Jpmorgan Chase Bank, N.A. | System and process for performing purchase transactions using tokens |
US7143174B2 (en) * | 2002-06-12 | 2006-11-28 | The Jpmorgan Chase Bank, N.A. | Method and system for delayed cookie transmission in a client-server architecture |
JP2004046541A (en) * | 2002-07-11 | 2004-02-12 | Sumitomo Mitsui Banking Corp | Transaction support system, network system, transaction support method, computer program and computer-readable storage medium |
US7121460B1 (en) | 2002-07-16 | 2006-10-17 | Diebold Self-Service Systems Division Of Diebold, Incorporated | Automated banking machine component authentication system and method |
US8239304B1 (en) | 2002-07-29 | 2012-08-07 | Jpmorgan Chase Bank, N.A. | Method and system for providing pre-approved targeted products |
US20040193530A1 (en) * | 2002-08-19 | 2004-09-30 | Andrew Hausman | Complementary trading of interests |
US7809595B2 (en) | 2002-09-17 | 2010-10-05 | Jpmorgan Chase Bank, Na | System and method for managing risks associated with outside service providers |
US7058660B2 (en) | 2002-10-02 | 2006-06-06 | Bank One Corporation | System and method for network-based project management |
US20040122736A1 (en) | 2002-10-11 | 2004-06-24 | Bank One, Delaware, N.A. | System and method for granting promotional rewards to credit account holders |
US20040073497A1 (en) * | 2002-10-15 | 2004-04-15 | Hayes Mark R. | Method and system for automated linkable promotions |
US20040085357A1 (en) * | 2002-10-31 | 2004-05-06 | Childress Allen B. | Method of generating a graphical display of a business rule and associated business rule elements |
US7451148B2 (en) * | 2002-10-31 | 2008-11-11 | Computer Sciences Corporation | Method of modifying a business rule while tracking the modifications |
US7689442B2 (en) | 2002-10-31 | 2010-03-30 | Computer Science Corporation | Method of generating a graphical display of a business rule with a translation |
US7676387B2 (en) | 2002-10-31 | 2010-03-09 | Computer Sciences Corporation | Graphical display of business rules |
US8301493B2 (en) | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
US8036982B2 (en) * | 2003-02-12 | 2011-10-11 | Mann Conroy Eisenberg & Associates, Llc | Computer system for controlling a system of managing fluctuating cash flows |
US7558757B2 (en) * | 2003-02-12 | 2009-07-07 | Mann Conroy Eisenberg & Associates | Computer system for managing fluctuating cash flows |
US7567914B2 (en) * | 2003-04-30 | 2009-07-28 | Genworth Financial, Inc. | System and process for dominance classification for insurance underwriting suitable for use by an automated system |
US7383239B2 (en) | 2003-04-30 | 2008-06-03 | Genworth Financial, Inc. | System and process for a fusion classification for insurance underwriting suitable for use by an automated system |
US7801748B2 (en) * | 2003-04-30 | 2010-09-21 | Genworth Financial, Inc. | System and process for detecting outliers for insurance underwriting suitable for use by an automated system |
US20040236611A1 (en) * | 2003-04-30 | 2004-11-25 | Ge Financial Assurance Holdings, Inc. | System and process for a neural network classification for insurance underwriting suitable for use by an automated system |
US7813945B2 (en) * | 2003-04-30 | 2010-10-12 | Genworth Financial, Inc. | System and process for multivariate adaptive regression splines classification for insurance underwriting suitable for use by an automated system |
US8126742B2 (en) | 2003-05-09 | 2012-02-28 | Accenture Global Services Limited | Automated assignment of insurable events |
US8306907B2 (en) | 2003-05-30 | 2012-11-06 | Jpmorgan Chase Bank N.A. | System and method for offering risk-based interest rates in a credit instrument |
US7606727B1 (en) | 2003-06-16 | 2009-10-20 | Jpmorgan Chase Bank, N.A. | System and method for identifying optimal marketing offers |
US20050033672A1 (en) * | 2003-07-22 | 2005-02-10 | Credit-Agricole Indosuez | System, method, and computer program product for managing financial risk when issuing tender options |
US7895064B2 (en) | 2003-09-02 | 2011-02-22 | Computer Sciences Corporation | Graphical input display in an insurance processing system |
US7953663B1 (en) | 2003-09-04 | 2011-05-31 | Jpmorgan Chase Bank, N.A. | System and method for financial instrument pre-qualification and offering |
US8239323B2 (en) | 2003-09-23 | 2012-08-07 | Jpmorgan Chase Bank, N.A. | Method and system for distribution of unactivated bank account cards |
WO2005076778A2 (en) * | 2003-10-10 | 2005-08-25 | Bloomberg Lp | Relative pricing for proposals for trading of financial interests |
US7765115B1 (en) | 2003-10-14 | 2010-07-27 | Symetra Life Insurance Company | Online system and method for processing life insurance applications |
US8190893B2 (en) | 2003-10-27 | 2012-05-29 | Jp Morgan Chase Bank | Portable security transaction protocol |
US20050171885A1 (en) * | 2003-11-03 | 2005-08-04 | Christman David T. | Object oriented demographically predictive insurance agency asset evaluation system and method |
US20050125253A1 (en) * | 2003-12-04 | 2005-06-09 | Ge Financial Assurance Holdings, Inc. | System and method for using medication and medical condition information in automated insurance underwriting |
US7698159B2 (en) * | 2004-02-13 | 2010-04-13 | Genworth Financial Inc. | Systems and methods for performing data collection |
US7467106B1 (en) | 2004-06-18 | 2008-12-16 | Jpmorgan Chase Bank, N.A. | System and method for offer management |
US8429006B1 (en) | 2004-06-18 | 2013-04-23 | Jpmorgan Chase Bank, N.A. | System and method for offer targeting |
US20070027728A1 (en) * | 2004-06-24 | 2007-02-01 | Schuver Steven S | System and method for protecting a security |
US20050289049A1 (en) * | 2004-06-24 | 2005-12-29 | Schuver Steven S | Insurance for a security |
US8160903B2 (en) * | 2004-06-24 | 2012-04-17 | Sbh, Inc. | System and method for determining a premium for insurance for a security |
US20050288969A1 (en) * | 2004-06-24 | 2005-12-29 | Schuver Steven S | Warranty for a security |
US7392222B1 (en) | 2004-08-03 | 2008-06-24 | Jpmorgan Chase Bank, N.A. | System and method for providing promotional pricing |
US20060074798A1 (en) * | 2004-09-27 | 2006-04-06 | Din Khaja M | Financial instrument, system, and method for electronic commerce transactions |
US20060080593A1 (en) * | 2004-10-08 | 2006-04-13 | Alexander Hudspith | System and method for generating computer-readable documents |
US8630898B1 (en) | 2005-02-22 | 2014-01-14 | Jpmorgan Chase Bank, N.A. | Stored value card provided with merchandise as rebate |
US20060224420A1 (en) * | 2005-04-05 | 2006-10-05 | Apsrfid, Llc | Healthcare insurance security system |
US7401731B1 (en) | 2005-05-27 | 2008-07-22 | Jpmorgan Chase Bank, Na | Method and system for implementing a card product with multiple customized relationships |
US8185877B1 (en) | 2005-06-22 | 2012-05-22 | Jpmorgan Chase Bank, N.A. | System and method for testing applications |
US8583926B1 (en) | 2005-09-19 | 2013-11-12 | Jpmorgan Chase Bank, N.A. | System and method for anti-phishing authentication |
US7818238B1 (en) * | 2005-10-11 | 2010-10-19 | Jpmorgan Chase Bank, N.A. | Upside forward with early funding provision |
US7933786B2 (en) | 2005-11-01 | 2011-04-26 | Accenture Global Services Limited | Collaborative intelligent task processor for insurance claims |
US7788296B2 (en) * | 2005-12-29 | 2010-08-31 | Guidewire Software, Inc. | Method and apparatus for managing a computer-based address book for incident-related work |
US20070156462A1 (en) * | 2005-12-30 | 2007-07-05 | Armen Kazanchian | Security insurance |
US7784682B2 (en) | 2006-02-08 | 2010-08-31 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
US8408455B1 (en) | 2006-02-08 | 2013-04-02 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
US20070205275A1 (en) * | 2006-03-06 | 2007-09-06 | First Data Corporation | Portable point of sale systems and methods |
US8036966B2 (en) * | 2006-04-07 | 2011-10-11 | Bloomberg Finance L.P. | System and method for facilitating foreign currency management |
US7753259B1 (en) | 2006-04-13 | 2010-07-13 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
US8676703B2 (en) * | 2006-04-27 | 2014-03-18 | Guidewire Software, Inc. | Insurance policy revisioning method and apparatus |
US7540408B2 (en) * | 2006-06-22 | 2009-06-02 | Hip Consult Inc. | Apparatus and method for facilitating money or value transfer |
US8793490B1 (en) | 2006-07-14 | 2014-07-29 | Jpmorgan Chase Bank, N.A. | Systems and methods for multifactor authentication |
US20090030822A1 (en) * | 2007-03-12 | 2009-01-29 | Jpmorgan Chase Bank, N.A. | System and Method for Contingent Equity Return Forward to Hedge Foreign Exchange Risk in Investments Having Varying Exit Parameters |
US8473735B1 (en) | 2007-05-17 | 2013-06-25 | Jpmorgan Chase | Systems and methods for managing digital certificates |
US8010390B2 (en) | 2007-06-04 | 2011-08-30 | Computer Sciences Corporation | Claims processing of information requirements |
US8000986B2 (en) * | 2007-06-04 | 2011-08-16 | Computer Sciences Corporation | Claims processing hierarchy for designee |
US8010391B2 (en) * | 2007-06-29 | 2011-08-30 | Computer Sciences Corporation | Claims processing hierarchy for insured |
US8010389B2 (en) * | 2007-06-04 | 2011-08-30 | Computer Sciences Corporation | Multiple policy claims processing |
US8676642B1 (en) | 2007-07-05 | 2014-03-18 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to financial account holders |
US7640212B2 (en) * | 2007-08-28 | 2009-12-29 | The Western Union Company | Methods and systems for executing a plurality of money transfers having a fluctuating parameter |
US8738518B2 (en) * | 2007-08-28 | 2014-05-27 | The Western Union Company | Methods and systems for executing a plurality of money transfers having a fluctuating parameter |
US8417601B1 (en) | 2007-10-18 | 2013-04-09 | Jpmorgan Chase Bank, N.A. | Variable rate payment card |
US8219424B2 (en) | 2008-01-18 | 2012-07-10 | Computer Sciences Corporation | Determining amounts for claims settlement using likelihood values |
US8321682B1 (en) | 2008-01-24 | 2012-11-27 | Jpmorgan Chase Bank, N.A. | System and method for generating and managing administrator passwords |
US8078528B1 (en) | 2008-02-21 | 2011-12-13 | Jpmorgan Chase Bank, N.A. | System and method for providing borrowing schemes |
US8478769B2 (en) | 2008-02-22 | 2013-07-02 | Accenture Global Services Limited | Conversational question generation system adapted for an insurance claim processing system |
US8515786B2 (en) | 2008-02-22 | 2013-08-20 | Accenture Global Services Gmbh | Rule generation system adapted for an insurance claim processing system |
US8301469B1 (en) | 2008-06-24 | 2012-10-30 | Mark Veldhuizen | Mortgage insurance system |
JP4748206B2 (en) * | 2008-11-11 | 2011-08-17 | ソニー株式会社 | Information processing apparatus, information processing method, and program |
US20100131300A1 (en) | 2008-11-26 | 2010-05-27 | Fred Collopy | Visible insurance |
US20100174563A1 (en) * | 2009-01-05 | 2010-07-08 | Russel Lazenga | System and Method for Purchasing Insurance |
US9608826B2 (en) | 2009-06-29 | 2017-03-28 | Jpmorgan Chase Bank, N.A. | System and method for partner key management |
US11080790B2 (en) | 2009-09-24 | 2021-08-03 | Guidewire Software, Inc. | Method and apparatus for managing revisions and tracking of insurance policy elements |
US20120005274A1 (en) * | 2010-07-02 | 2012-01-05 | Electronics And Telecommunications Research Institute | System and method for offering cloud computing service |
US8856040B2 (en) | 2011-11-11 | 2014-10-07 | Damon Magnuski | System providing commodity price-move protection for small risk holders |
US10789219B1 (en) | 2012-03-28 | 2020-09-29 | Guidewire Software, Inc. | Insurance policy processing using questions sets |
US10049402B1 (en) | 2012-06-13 | 2018-08-14 | Jpmorgan Chase Bank, N.A. | ATM privacy system and method |
US9419957B1 (en) | 2013-03-15 | 2016-08-16 | Jpmorgan Chase Bank, N.A. | Confidence-based authentication |
US10949923B1 (en) | 2013-09-16 | 2021-03-16 | Allstate Insurance Company | Home device sensing |
US9058626B1 (en) | 2013-11-13 | 2015-06-16 | Jpmorgan Chase Bank, N.A. | System and method for financial services device usage |
US10148726B1 (en) | 2014-01-24 | 2018-12-04 | Jpmorgan Chase Bank, N.A. | Initiating operating system commands based on browser cookies |
US10430887B1 (en) * | 2014-02-21 | 2019-10-01 | Allstate Insurance Company | Device sensing |
US10380692B1 (en) * | 2014-02-21 | 2019-08-13 | Allstate Insurance Company | Home device sensing |
WO2015142765A1 (en) | 2014-03-17 | 2015-09-24 | Coinbase, Inc | Bitcoin host computer system |
US9735958B2 (en) * | 2015-05-19 | 2017-08-15 | Coinbase, Inc. | Key ceremony of a security system forming part of a host computer for cryptographic transactions |
US11394543B2 (en) | 2018-12-13 | 2022-07-19 | Coinbase, Inc. | System and method for secure sensitive data storage and recovery |
US10903991B1 (en) | 2019-08-01 | 2021-01-26 | Coinbase, Inc. | Systems and methods for generating signatures |
WO2021076868A1 (en) * | 2019-10-16 | 2021-04-22 | Coinbase, Inc. | Systems and methods for re-using cold storage keys |
JP6768911B1 (en) | 2019-11-01 | 2020-10-14 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | Payment system and payment method |
JP7019751B2 (en) * | 2020-06-15 | 2022-02-15 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | Payment system and payment method |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4766539A (en) * | 1985-03-08 | 1988-08-23 | Fox Henry L | Method of determining the premium for and writing a policy insuring against specified weather conditions |
US5262942A (en) * | 1990-06-05 | 1993-11-16 | Bankers Trust Company | Financial transaction network |
US5319542A (en) * | 1990-09-27 | 1994-06-07 | International Business Machines Corporation | System for ordering items using an electronic catalogue |
EP0551433B1 (en) * | 1990-10-01 | 2001-05-09 | BUSH, Thomas A. | Transactional processing system |
US5446885A (en) * | 1992-05-15 | 1995-08-29 | International Business Machines Corporation | Event driven management information system with rule-based applications structure stored in a relational database |
US5465206B1 (en) * | 1993-11-01 | 1998-04-21 | Visa Int Service Ass | Electronic bill pay system |
US5704045A (en) * | 1995-01-09 | 1997-12-30 | King; Douglas L. | System and method of risk transfer and risk diversification including means to assure with assurance of timely payment and segregation of the interests of capital |
US5659165A (en) * | 1995-07-24 | 1997-08-19 | Citibank. N.A. | Customer-directed, automated process for transferring funds between accounts via a communications network |
US5644721A (en) * | 1995-08-30 | 1997-07-01 | System One Information Management, L.L.C. | Multiple currency travel reservation information management system and method |
US5884274A (en) * | 1996-11-15 | 1999-03-16 | Walker Asset Management Limited Partnership | System and method for generating and executing insurance policies for foreign exchange losses |
-
1996
- 1996-11-15 US US08/749,241 patent/US5884274A/en not_active Expired - Lifetime
-
1997
- 1997-11-13 AU AU52568/98A patent/AU5256898A/en not_active Abandoned
- 1997-11-13 JP JP10522826A patent/JP2000509859A/en active Pending
- 1997-11-13 CA CA002276243A patent/CA2276243A1/en not_active Abandoned
- 1997-11-13 WO PCT/US1997/020754 patent/WO1998021680A1/en active Application Filing
- 1997-11-13 EP EP97947505A patent/EP1016011A4/en not_active Withdrawn
-
1999
- 1999-03-05 US US09/262,810 patent/US6128598A/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP1016011A1 (en) | 2000-07-05 |
WO1998021680A1 (en) | 1998-05-22 |
EP1016011A4 (en) | 2006-09-20 |
US6128598A (en) | 2000-10-03 |
US5884274A (en) | 1999-03-16 |
JP2000509859A (en) | 2000-08-02 |
AU5256898A (en) | 1998-06-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5884274A (en) | System and method for generating and executing insurance policies for foreign exchange losses | |
US6236972B1 (en) | Method and apparatus for facilitating transactions on a commercial network system | |
US6594647B1 (en) | Real time bank-centric universal payment system | |
US7356505B2 (en) | System and method for transferring funds | |
US6749114B2 (en) | Universal authorization card system and method for using same | |
US6098053A (en) | System and method for performing an electronic financial transaction | |
US8630946B2 (en) | Systems and methods for providing individualized financial access | |
US6138107A (en) | Method and apparatus for providing electronic accounts over a public network | |
US6937990B1 (en) | System for syndication of insurance | |
US7143062B2 (en) | Electronic cash eliminating payment risk | |
US7716129B1 (en) | Electronic payment methods | |
US6947908B1 (en) | System and use for correspondent banking | |
US20020072942A1 (en) | System and method for push-model fund transfers | |
US20090150294A1 (en) | Systems and methods for authenticating financial transactions involving financial cards | |
US20030069792A1 (en) | System and method for effecting secure online payment using a client payment card | |
US20120246080A1 (en) | Method and system for real time online debit transactions | |
US20230169585A1 (en) | System for disclosing deposit account information that can be virtual currency address | |
EP1062560A1 (en) | Automatically invoked intermediation process for network purchases | |
EP1179206A1 (en) | Person-to-person, person-to-business, business-to-person, and business-to-business financial transaction system | |
US20060036530A1 (en) | Method and apparatus for facilitating micro energy derivatives transactions on a network system | |
US20040054624A1 (en) | Procedure for the completion of an electronic payment | |
US7251633B2 (en) | Method or system for executing deferred transactions | |
US20140019356A1 (en) | Online electronic transaction and funds transfer method and system | |
US8521643B2 (en) | System and method for on-line payment transactions | |
EP1297502B1 (en) | Process to carry out on-line purchasing transactions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Discontinued |