WO2010033081A2

WO2010033081A2 - Secure server system for online transactions

Info

Publication number: WO2010033081A2
Application number: PCT/SG2008/000361
Authority: WO
Inventors: Teck Kim Lim
Original assignee: Embeyond Pte Ltd
Priority date: 2008-09-22
Filing date: 2008-09-22
Publication date: 2010-03-25
Also published as: WO2010033081A3

Abstract

A secure server system for online transactions includes a data processing system for generating a digital signature for a message containing message data to be sent via a data network (4) a method for handling a purchasing transaction between a party (2) using a party processor and another party (3) using another party propcessor, a system for handling a purchasing transaction between a party using a party processor and another party using another party processor, a method for receiving and executing security orders from' a set of investors (1) and a method for receiving and executing sell orders from a set of investors.

Description

SECURE SERVER SYSTEM FOR ONLINE TRANSACTIONS

FIELD OF THE INVENTION

As more and more consumers gain access to the World Wide Web or Internet, the prospect of the sale of goods and or services over the Internet continues to urge businesses to set up a network presence to support their customer base and attract new customers. Many larger businesses are moving toward providing an on-line presence to supply additional information and services to their customers at their customers' convenience, to reduce costs, and to remain competitive in the marketplace. Smaller businesses are likewise attracted to the Internet to expand and attract a larger customer base and reduce operating costs.

General online transaction systems - background

The on-line presence established by such business merchants is typically a home page simulating a store front displaying the merchant's logos or other design features that set that particular merchant apart from others. Other information such as advertised items and contact information also adorn the page. Additional web pages are generally provided if necessary to convey additional information. Merchants also typically sell or rent unused space on their web page to other piggybacking advertisers to help with costs of maintaining both the web site and the business, hi accordance with preferred advertising practices, continued exposure of the consumer to such displays is of paramount importance.

Purchasing items over the Internet involves the selection of salable items on the merchant's web site after browsing or searching the contents of the related web pages until the desired item is found. The item is then selected and typically placed into an on-line shopping cart which holds the items while the purchaser continues to shop. Other items may be selected and placed into the cart in a similar manner. When the purchaser desires to buy the items previously selected, he or she selects an icon associated with a checkout process. This brings up a screen displaying the shopping cart items and requesting that the purchaser confirm the previous selections. Upon confirmation of the selected items, another screen is displayed which includes a form requesting information such as shipping and billing information including a method of payment. The medium of exchange relied upon by the merchants for Internet sales is almost exclusively limited to credit cards and debit cards. After completing the form including credit card selection and corresponding information, the consumer submits the information which causes one of two situations to occur. In one instance, the current display remains in view while the credit card information is being processed in the background. In such case, the merchant remains in communication with the validation agency awaiting confirmation of the transaction. On the other occasion, the display page is changed to reflect the creditor's site which removes the merchant's display and associated advertising from the view of the consumer.

Several drawbacks are apparent in the current transactional systems and processes. First of all, the almost exclusive use of credit based transactions removes a large pool of potential customers from purchasing over the Internet. Since many advertisers largely focus on today's youth due to their increased spending means, it would be useful to provide a medium of exchange independent of credit based transactions available to such patrons. Also, not everyone has the luxury of an established credit line or even desires to rely on credit. Another drawback occurs in the first situation wherein the merchant remains in communication with validation authority until the transaction is verified. If the transaction is not viable, then valuable time and resources are wasted by occupying the merchant's server during verification of an eventually invalid transaction. It would therefore be advantageous to provide a system and process that relieves the merchant from the verification process and only contacts the merchant if a transaction is viable due to sufficient funds.

A pre-paid account or pre-paid card would address the drawbacks of prior systems and would provide both benefits to the merchant by increasing the potential customer base and consumers as well. Consumers benefit by preventing credit card fraud, purchasing cards only as necessary, and living debt free. Purchases can remain relatively anonymous as in ordinary cash transactions and no interest accrues on the purchases keeping overall cost to the consumer down.

Additionally, the low cost of Internet access and obtaining information is primarily driven by advertising. Both the merchants and associated advertisers have a vested interest in presenting their ads in the customer's view as long as possible. Therefore, any time when advertising is not being viewed the value of the advertising effectively decreases. Thus, in the second instance when the consumer is sent to an alternate network location and the merchant's display is replaced with the creditor's display, valuable advertising time is lost. Yet another drawback is the requirement that the consumer provide shipping information every time the merchant site is visited and a purchase is desired. Typically, upon selection of the goods or services, a form with a shipping order is transmitted to the purchaser to fill out. This is performed using the merchant's computer resources which may increase the demand on the server. A system which removes the process of filling out shipping information to an alternate server unburdens the demands on the merchant's server freeing valuable resources.

What is needed, and heretofore unavailable, is a convenient system capable of verifying the viability of a purchasing transaction conducted over a computer network which reduces the merchant's resource requirements while maximizing the viewing time of the merchant's display and a method of using the same.

Financial transaction systems - background

In a typical retail securities trading operation, a broker holds the funds and securities of a number of account holders ("holders") and maintains data for each account that tracks the balances for the holder's account and the transactions made by the holder. Examples of such systems can be found at full-service brokerages, discount brokerages and online trading brokerages. These brokerages differ mostly in the manner in which a holder effects a transaction. With a full-service brokerage, a holder might make a trading transaction (a "trade") while on the telephone, and in consultation, with a broker. With a discount brokerage, the holder typically makes his or her own decisions as to trades and calls the discount brokerage with the trade information. With an online brokerage, the holder electronically connects to a computer operated by or for the broker and thus transfers the trade information.

Many existing brokers have several aspects of the above types of brokerage, such that one broker might be a full-service brokerage to some holders or for some trades but be a discount brokerage to other holders or for some trades. However, what is common among each of these brokerages is that they maintain separate accounts for holders. The cash, securities and other instruments owned by a holder at that brokerage are held by the brokerage, often in the name of the brokerage (i.e., "street name") and are represented in the data stored about that holder in account files that are part of the data storage of a computer system operated by or for the brokerage.

Another common feature of existing brokerages is that, when a holder enters an order for a transaction, the transaction is executed by the broker in response to the order, depending on the terms of the order. For example, a holder might submit a buy order, a type of trade wherein the holder receives securities in exchange for cash, and the brokerage would submit a buy order on behalf of the brokerage. After the trade is consummated, the brokerage identifies the cost of the security and debits the holder's cash account accordingly, then updates the holder's balances to show the purchased securities. This process is known as trade execution.

With the increasing availability of online trading, many holders are demanding faster and faster trade execution. Some online brokerages even offer to waive their commission on a trade if the trade cannot be done within 60 seconds. A growing number of day traders, who buy and sell securities by the hour or minute, rarely holding securities overnight, have been requiring even faster transaction speeds, so that they can take advantage of momentary fluctuations in securities prices.

For many investors, such trading systems are unnecessary, as most financial advisors advise nonprofessional investors to enter and exit the market slowly. Also, for small investors with small amounts to invest, the costs associated with each transaction (commission, etc.) make it difficult to invest using such brokerage systems.

hi response to the economics of trading and relative transaction costs, many unsophisticated and small investors place their investments in other vehicles, such as Direct Stock Purchase Plans

("DSPPs") or Dividend Reinvestment Plans ("DRIPs"). With a DSPP or DRIP, an investor directly contacts a security issuer (a publicly traded corporation) and makes arrangements with the security issuer to obtain shares in that security issuer, with little or no commission. This benefits the corporation because it results in a wider base of stockholders. In addition, the corporation provides the investor with additional company stock that is purchased with the cash dividends paid by the corporation. Shares are issued either through original issuance or through open market purchases.

Dividend Reinvestment Plans are company sponsored stock plans that enable individuals to purchase shares of stock and/or reinvest dividends in additional shares of company stock for either no fees, or very low fees. The initial purchase of shares must occur through a third party such as a brokerage firm. There are approximately 1 ,300 DRIP plans available today primarily with Fortune 500 companies. Direct Stock Purchase Plans are company sponsored stock plans that enable individuals to purchase shares of stock and reinvest dividends in additional company stock, but vary from DRIPs in that DSPPs allow investors to purchase the initial or additional shares directly through the company plan. There are approximately 400 companies that currently offer DSPPs today, primarily large or Fortune 500 companies. A DSPP is often considered a specific form of a DRIP. First introduced in the mid-1960's, DRIPs did not gain wide spread popularity until the 1980's when corporations recognized them as a cost-effective method to raise capital at lower costs while building closer ties with customers by transforming them into shareholders. Today over 7 million individuals in the United States (representing 40 million accounts) employ DRIPs as part of their long-term investment strategies at over 1,300 companies including many large and Fortune 500 corporations.

DRIPs/DSPPs have several advantages over other investment vehicles, but still have disadvantages. For example, the advantages include:

Reasonable Minimum Investment: Investors can enroll in a DRIP with a smaller initial investment relative to full service, discount and online brokerages. For example, many plans only require the purchase of one to 10 shares or a cash investment as low as $50 to $250. Many online and full service brokerage accounts require an initial deposit of $1,000 to $2,500 or more to open an account. Therefore DRIPs offer an advantage to these high initial deposit requirements.

Investments can be made in dollar amounts (or other currency): Many DRIP plans allow investors to purchase stock in dollar amounts rather than in whole shares, enabling investors to purchase or sell fractional shares and budget for regularly scheduled investments. The only way to currently purchase fractional shares through any brokerage (or broker-dealer) is through their dividend reinvestment service, if they offer one, which only permits investors to have their cash dividends reinvested into additional shares. Some brokerage dividend reinvestment services do not allow purchases of fractional shares.

Reasonable Fees: Although many DRIPs require investors to purchase their initial shares from a brokerage firm to enroll in the plan, after enrolled, investors can purchase shares directly through the DRIP, usually with low or no brokerage commissions. However, these costs are on the rise as corporations are charging more to continue to service their accounts. Long-Term Perspective: The nature of investing in DRIPs nearly "forces" individuals to purchase and hold stock, thereby adopting a long-term investment perspective through the regular purchase of shares over time to cumulate holdings in the designated corporation offering the plan.

Reinvestment of Dividends: DRIPs are a cost-effective method for investors to put cash dividends to better use by automatically reinvesting in additional shares rather than spending the money or holding it in a bank account. Reinvestment of dividends is also a non-taxable event under U.S. income tax rules with subsequent sale taxed at the corporate going rate while distribution of cost dividends creates a taxable incoming event.

Dollar Cost Averaging: DRIPs provide an excellent dollar-cost averaging investment strategy through regularly scheduled stock purchases over time. Rather than attempting to time purchases based on market conditions, often referred to as "trading". DRIPs allow investors to build wealth and accumulate investments with manageable and consistent stock purchases that can easily be debited from a bank account on a periodic basis. There are no brokerage firms that currently allow investors to set up automatic regular investing schedules to buy stock using a specific dollar amount on a specific time basis.

One disadvantage of the typical DRIP investment plan is that the DRIP enrollment process is slow, antiquated and often forces new investors to endure a six to seven week wait before initial trades are officially executed. Receiving DRIP enrollment and prospectus information through the mail can take up to three weeks and the completion and submittal of the information by investors can take another two weeks. Additional time is spent transferring initially purchased shares, typically through a transfer agent, from the investor's brokerage account into the DRIP program. Finally, another one to two week wait can be expected before receiving a statement confirming the opening of a DRIP account and the assignment of an account number. With the increasing use of the Internet, this step has become easier. Several information providers have Internet sites where an investor can go to providing mailing and other information that the operators of those

Internet sites will forward to multiple DRIP companies. While the investor would still have to deal with multiple sets of fees, rules and agreements, at least the investor can get all of that information online and even enroll online. They can even view their account statements online through some of these services.

Yet another disadvantage is that a majority of DRIPs require that investors purchase their initial shares of stock from a broker in order to gain eligibility to enroll in the plan. Initial shares in a DRIP must be registered in the individual investor's name rather than the "street" or brokerage name, an often-confusing point for the first time DRIP investor. Brokers typically charge fees to register stock in the investor's name and produce the stock certificate required as proof of ownership by the DRIPs.

Other disadvantages are:

Multiple Accounts: In the current DRIP environment, investors are required to maintain separate accounts for each DRIP in which they are enrolled, resulting in excessive paperwork and separate trade confirmations and account statements. Furthermore, each plan may have its own unique set of fees and commissions, resulting in a lack of price uniformity among multiple plans.

No Same Day Trades: Same day trades are currently not possible through DRIP plans. An investor cannot use a telephone or Internet-based service to place a buy order on the day they choose. In most plans, there is a specific day(s) per month when shares are purchased on behalf of investors, so investors may have to wait up to two weeks for the execution of DRIP purchases and sales leaving the investor to speculate regarding the actual trading price of the stock.

Cannot Maintain a Cash Balance: A DRIP is a direct ownership of stock. It is essentially a book- entry form of conventional certificate ownership. Therefore, there is nothing in place to provide for a DRIP to offer investors a place to maintain a money market or cash balance in their account. This disadvantage limits investors from making purchases of additional shares on the day or at the time they choose.

No Control over Buying Price: Although DRIP investors are focused on the long term, they naturally strive to achieve the best price. The sluggishness of the DRIP process severely limits the control with which investors can realistically purchase stocks. If, for instance, an investor wanted to purchase a few hundred dollars of a particular stock through a DRIP, they would have to mail in a check to the transfer agent, or plan administrator. The price on the day they mailed the check could be different than the price on the day the check was received and the new shares were purchased.

Cannot Determine Average Purchase Price: DRIP plans do not currently offer a feature to calculate the average purchase price of a stock after years of scheduled dollar cost averaging and dividend reinvestment cycles. Attempting to determine the average purchase price of scheduled trades and dividend reinvestments recorded in paper format can be extremely time consuming and frustrating, if not impossible due to misplaced records. DRIP investors currently have to purchase or use their own software to accomplish this task. This can be difficult, expensive and not necessarily accurate since it would require investors to manually enter their own transaction history into some type of a software program.

Must have a DRIP to Invest Directly: Another disadvantage is that a DRIP investor cannot invest in a DRIP plan in companies that do not offer DRIP plans. There are many companies that are good investment vehicles but do not pay dividends, choosing instead to use profits for research, expansion or acquisitions. Those non-dividend paying companies are not likely to set up DRIPS, so a DRIP investor would have to look elsewhere for investment. The ability to invest in a DRIP- like manner in companies that do not offer dividends and do not offer a DRIP is not available at this time. Yet another disadvantage of DRIPs is that is it difficult to hold those investments in tax- advantaged accounts, such as Individual Retirement Accounts (IRA's).

Mutual funds overcome some of those disadvantages and are readily available to small investors. With a mutual fund, a fund manager maintains an account for each holder and the fund manager pools the funds of the holders. The mutual fund manager makes trades from time to time on behalf of the mutual fund and each holder benefits from a proportionate share of those investments. In nearly all mutual funds, the holders do not have input into the make-up of the mutual fund. If the holder is unsatisfied with the investment strategy of the mutual fund manager, the only choice for the holder is to withdraw the funds and move the funds to another mutual fund with a more agreeable investment strategy. Of course, very large investors could sway the opinion of a mutual fund manager if they owned a large percentage of shares. Mutual funds typically still have sizable barriers to entry for the small investor due to the large minimum investment generally required by most mutual funds. These costs can often exceed $2,000.

A DSPP works essentially the same as a DRIP, except that the initial investment can be handled through the DSPP, whereas a DRIP requires the investor to own usually at least one share of the company's stock prior to enrollment. A DSPP or DRIP can also be set up by a closed-end fund. Such a DSPP/DRIP would work essentially the same way as a DSPP/DRIP of a publicly traded company. Accounting for trades in securities accounts and mutual fund accounts differ in several respects. For most securities transactions, the transaction is done in a whole number of shares or a whole number of lots, where a lot is 100 shares. For mutual funds, a transaction is typically performed in a dollar amount (or other currency if dollars are not the currency in use). For example, an order for a securities trade might be for 200 shares of the ABC Company and an order for a mutual fund might be for $2,000 of the mutual fund. In both cases, the order has an associated price per share and a number of shares. Because of market fluctuations, the price per share is not often a round number. For the typical securities order, the number of shares is a round number but the total cost of the transaction is not a round number, whereas for the typical mutual fund order, the total cost is a round number but the number of shares is not. Whether some quantity is a round number or not is important for many holders because of the limitations placed on the trades by the brokerage or other operator of the computer system maintaining the holder's account. Present invention

The present invention relates to a transaction system for use with data networks, like intranets, extranets, and Internet. Transactions to be performed may include e-commerce, such as shopping and business-to-business transactions, electronic banking, protected emailing, consulting and amending databases, brokerage, and the like. The invention also relates to the authentication of parties and the transactions exchanged. The invention further relates to the preparation of a confidential message. The invention still further relates to the generation of a digital signature as for use in the transmission of secure information.

When using data networks, like Internet, for transactions between parties, that want to exchange information, that want to buy goods, enjoy services or receive information and other parties offering those goods, services or information, one of the problems observed is the lack or secure and at the same time simple transaction methods. Secure systems, such as SET, SSL, etcetera exist, but are felt as being cumbersome to use, involving heavy message traffic, (complex) cryptographic procedures, and key management including key recovery.

The invention also relates generally to transactional systems and methods and more specifically to systems and methods for purchasing goods and or services over a global computer network. SUMMARY OF THE INVENTION

An object of the invention is to provide a secure data network transaction system without the need for cryptography, whilst fulfilling demands for security, particularly privacy, authentication and irrefutability of the messages that constitute a transaction.

The privacy requirements are that no information is disclosed to any party, unless needed to perform the basic objective, which within the scope of this invention comprises the execution of a transaction, with or without a payment that might result from the transaction.

The authentication requirements are to be able to verify the authenticity of transmitted data and the sender of those data. Within the scope of this invention these data, as well as an identification of the parties concerned, form part of transaction messages.

The basis of the invention is to use a secure and trusted computer environment, referred hereinafter as the transaction server. Parties wishing to use the services of the transaction server, are registered at the server with a so called profile. Such profile contains at least the data necessary to provide data integrity, data authentication, authentication of the parties, confidentiality or sensitive data (privacy) and irrefutability.

hi such an environment, there will be two types of parties: a party that demands a service, a product, or information, further referred to as a "customer"; and a party that offers such services, products, or information, further referred to as a "supplier".

hi case the transaction involves a payment, a third type of party may occur: one or more financial institutions that take care of the payment process, further referred to as a "financial institution". In the system according to the invention, the number of customers, suppliers and/or financial institutions may range from 1 to many. One or more of the objects of the invention are reached by a method for performing at least one transaction between at least one first party and at least one second party using at least one data network for interconnecting data input/output devices of the at least one first party and the at least one second party, the method comprising:

(a) providing a transaction server in the at least one data network;

(b) in the transaction server, registering a profile of the at least one first party and the at least one second party, each profile comprising a party identifier identifying the party, and authentication data for authenticating the party and data sent by the party, the authentication data comprising a table of random data for generating a digital signature;

(c) the first party issuing at least one transaction message to the second party;

(d) in response to the transaction message, the second party issuing a digitally signed transaction confirmation message to the first party;

(e) on the basis of the transaction confirmation message, the first party issuing a digitally signed transaction approval message to the transaction server;

(f) if required by the first or the second party, the transaction server verifying the authenticity of the first party and the second party, and the transaction data, in response to the transaction approval message;

(g) the transaction server issuing a verified transaction approval message to the second party, in case said authenticity verification is required only if the verification is positive, resulting in a verified transaction approval message; and

(h) fulfillment of the transaction.

An example of such a transaction is a customer to supplier transaction or a business to business transaction, where a customer or business demands a service, a product, or information.

The invention further discloses a method for performing at least one transaction between at least one first party and at least one second party using at least one data network for interconnecting data input/output devices of the at least one first party and the at least one second party, the method comprising:

(a) providing a transaction server in the at least one data network;

(b) in the transaction server, registering a profile of the at least one first party and the at least one second party, each profile comprising a party identifier indentifying the party, and authentication data for authenticating the party and data sent by the party, the authentication data comprising a table of random data for generating a digital signature;

(c) the first party issuing at least one transaction message to the transaction server;

(d) in response to the transaction message, the transaction server verifying the authenticity of the first party, and the transaction data;

(e) if the verification is positive, the transaction server issuing a verified transaction message to the second party; and

(f) the second party and the first party performing the at least one transaction through the transaction server by means of digitally signed messages, the validity of which is verified by the transaction server.

Examples of such a method are brokerage or telebanking, where the first party is a customer, and the second party is a supplier of services.

Use of the invention for sending and retrieving electronic mail is obtained by a method for performing at least one transaction between at least one first party and at least one second party using at least one data network for interconnecting data input/output devices of the at least one first party and the at least one second party, the method comprising:

(a) providing a transaction server in the at least one data network; (b) in the transaction server, registering a profile of the at least one first party and the at least one second party, each profile comprising a party identifier indentifying the party, and authentication data for authenticating the party and data sent by the party, the authentication data comprising a table of random data for generating a digital signature;

(c) the first party issuing at least one digitally signed transaction message to the transaction server;

(d) in response to the transaction message, the transaction server verifying the authenticity of the first party; (e) if the verification is positive, the transaction server linking the transaction message to the profile of a second party;

(f) if the second party connects to the transaction server, the transaction server verifying the authenticity of the second party; and

(g) if the verification is positive, the transaction server issuing the transaction message to the second party.

Here, the transaction message is an email.

(a) providing a transaction server in the at least one data network;

(b) in the transaction server, registering a profile of the at least one first party, the profile comprising a party identifier identifying the party, and authentication data for authenticating the party and data sent by the party, the profile further comprising operation identifiers each identifying an operation that is enabled for the party, and is meaningful only between the party and the transaction server;

(f) the second party and the first party performing the at least one transaction through the transaction server. Such a method is particularly suitable for a party desiring to gain access to a service provider anonymously. Yet the service provider can be sure that the party is entitled to the requested access.

Instead of using a table of random data for verifying a digital signature, the profile may comprise operation identifiers each identifying an operation which is enabled for the party, and is meaningful only between the party and the transaction server.

In the system according to the invention, the need for encryption is eliminated as there are no sensitive data to be exchanged between customer, supplier and transaction server. The sensitive data are replaced by covert coded data, which are significant only to the sender and receiver of the message, thus respecting the privacy.

The authentication problems are solved by non-cryptographic methods, hence avoiding the problems of key management and the computing power to perform cryptographic operations. Even, when cryptographic digital signatures are used, the authenticity can be more easily established, using the transaction server concept according to the invention.

Additionally, transaction irrefutability is achieved, since every step in the process can be monitored and verified.

If the transaction involves payments, the transaction server does not require any adaptations within the existing payment systems, as it uses transparently the network structures, which are in use today for the processing of electronic payment transactions. This is quite a cost saving factor, as changing anything in these systems is not a trivial operation. At the same time, the use of the transaction server opens new channels for making frequent payments of small amounts of money, as the costs of processing these payments is low. FURTHER ASPECTS OF THE INVENTION

Further, a transactional system is provided for handling a purchasing transaction between a first party and a second party having at least a part of the transaction handled by an administrative third party to relieve some of the resource burden placed on the second party, typically a merchant. Such system generally includes a medium of exchange between the parties in the form of pre-paid cards having unique card identifiers provided in an unactivated format at convenient distribution sites. The cards may be activated at an activation site enabling the first party to begin a purchasing transaction. A global computer network provides the primary communication medium between the parties which have a presence on the network in the form of their respective processors and network addresses. The first party may view the public contents of the second party processor and make a selection of the desired items. A purchasing option with an embedded link is provided in the second party's display and is programmed to, upon activation, transfer handling of the purchasing transaction to a third party processor which sends a substitute display substantially duplicating the second party's display and requests information from the first party. Such third party processor receives the first party information and processes it using a transactional computer program and associated transactional database to verify the viability of such transaction. Notification of the fund verification is provided depending upon the outcome of the verification step.

Further provided are methods for using such system. One method may be applied to credit and non-credit based transactions. Such method includes steps of accessing a second party display on the global computer network and selecting a salable item along with a purchasing option.

Selection of the purchasing option triggers an alternate server to send a preformatted display to a first party substantially duplicating the second party display and requesting information from a first party. Receipt of such first party response activates a computer program which accesses a transactional database to authorize the transaction. A successful transaction results in funds being transferred to a second party repository and portions of the first party response sent to the second party for completing the transaction.

Another method using the system of the present invention involves the steps of providing a pre- paid card distribution site capable of issuing pre-paid cards with unique card identifiers in exchange for currency. An accounting database is maintained for monitoring the balance associated with each card. A first network server provides a merchant site having a display page with a predetermined format advertising salable items and offering a pre-paid card purchasing option with a link. Activation of such link transfers administration of the transaction to a second network server which substitutes an alternate display substantially duplicating the merchant site display page and submits a form requesting purchaser information including the unique card identifier. The purchaser information is received and processed by the second network server which accesses the accounting database to verify an adequate account balance and to authorize the transaction. Funds are transferred from the pre-paid card account to the merchant account if the transaction is authorized. Additionally, the purchase information is forwarded from the second network server to the first (merchant) server.

Such system may also incorporate other features such as card to card balance transfers and recharging a pre-paid card.

DRIPS server - invention summary

hi specific embodiments, the transactions are preferably selected from buys and sells, but some embodiments may allow puts and calls as well. The orders, and possibly the trades, might be transmitted electronically over a dedicated data line or telephone line or might be transmitted over the Internet or wireless networks. The aggregated trade might only comprise one order, as might be the case for thinly traded securities, but preferably, many orders can be aggregated into a single trade. To make it more likely that multiple orders will be available for aggregation, the trading server can hold orders until many orders are received by the trading server before transmitting a trade for execution, even if orders are received in real-time.

hi some embodiments, trades are submitted during specified times of day, next trading day, or end of the week, independent of when an order is actually received. For example, one embodiment of the trading server might defer execution or transmission of a trade to the exchange, even if orders are outstanding, until a certain time after the exchange opens, to allow the market to stabilize from the initial opening minutes or hour. Such an embodiment might also hold orders received between a cut-off time and the close of market until the next trading day, to avoid any closing instability. Some embodiments might also provide for a cut-off, such as half an hour, between the time a trade is transmitted and the time an order is received, to allow for orderly order aggregation and to allow investors to react more slowly to market movements and new events, as is recommended by many financial advisors but not followed by many investors. Orders can be received either in specified share amounts (such as for a'sale) or in specified dollar (or other currency) amounts (such as for a buy).

The trading server can be one computer or a collection of computers, preferably an arrangement that is connected to the Internet and is scalable to allow many hundreds of thousands or millions of orders to be taken from investors. In one specific trading computer system, a plurality of investor terminals, such as personal computers connected to the Internet and running HTTP browsers, are coupled to a trading server and the trading server is coupled to an electronic trading system to which trades are submitted and subsequently executed. That trading server comprises logic for accepting orders from the plurality of investor terminals, a database for storing accepted orders, logic for accumulating accepted orders in the database, logic for triggering a trading transaction, a means for transmitting a trading transaction to the electronic trading system where the trading transaction represents an accumulation of accepted orders of similar securities and logic for updating an investor account in response to the acceptance of orders and for updating an investor account in response to receipt of a trade confirmation from the electronic trading system.

In one aspect of a trading server, orders are aggregated and/or processed to lower the transaction costs of a trade or trades to accommodate those orders, often at the expense of trading speed, i.e., the orders are filled less expensively, although the order might not be filled as fast as other trading methods. While with long-term investing, such quick turn-arounds are less significant than for trading in days or shorter periods, all investors prefer timely execution of orders, which can be achieved with the novel system described herein.

Another aspect of the same embodiments of the invention is that due to the improved efficiency of trading system, either both lower initial investments per order or lower initial amounts to open an account may be achieved while maintaining an economically viable system. Thereby, both the cost per trade, amount of each order or trade, and total amount of the initial account is substantially reduced.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a transaction system according to the present invention.

FIG. 2 illustrates how a party applies for participation in the transaction system.

FIG. 3 illustrates the relation between the various functional entities.

FIG. 4 illustrates the steps in a sample transaction.

FIG. 5 illustrates how a party can obtain a temporary profile where a party uses a device not personalised for him. FIG. 6 illustrates the generation of a digital signature used for verifying the authenticity of the data and the sender of those data.

FIG. 7 illustrates how a random structure can be used to generate a table of random numbers.

FIG. 8 illustrates steps in a sample transaction between parties.

FIG. 9 illustrates a transaction, involving a direct payment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 is a diagram of a transaction system in accordance with the invention. Centrally there is a secure and trusted data processing system, hereinafter to be referred to as a transaction server 1, to which participating parties 2, 3 are connected through a data network 4, e.g. Internet. If the transaction involves a payment, the transaction server 1 connects to one or more financial institutions 6, using the existing payment networks 5. The transaction server holds so-called profiles 7 and 8 for the participating parties, as explained below with reference to FIG. 2. "Users" of the transaction system are parties 2 ("Customer") that want to obtain goods, services and/or information from other parties 3 ("Supplier"), who are suppliers of these goods, services and/or information. The parties 2, 3 are selectively coupled to the data network 4.

Financial institutions 6 involved are Issuers (banks issuing payment cards to clients). Acquirers (banks serving the needs for suppliers or goods, services and/or information), and Schemes (financial institutions managing payment cards, like VISA, Mastercard and the like).

FIG. 2 illustrates how a party 12, 13 will be registered to be able to participate in the transaction system. In Step A the party 12, 13 fills in an application form, containing his request to participate in the transaction system, his identification and (if payment is included in his profile) a list of payment methods (which cards, debit or credit, etc.) he wants to use (if he is a payer/consumer 12) or a list of payment accepting methods (which accounts, etc.) he wants to use (if he is a supplier 13) and an authorisation to the transaction server 11 to verify his account/card data at the corresponding bank and receive additional information, required to create the party's profile. The application fort then is submitted to the institution, operating the transaction server 11, on paper, by E-mail, by courier, or otherwise.

Next, step B, the account/card information together with the identification of the applying party 12, 13 is sent to a Registration Authority 10 (R.A.), e.g. his bank relations) to verify the authenticity of the party 13, 13 and the information supplied with his application.

The request to participate in the transaction system may also directly be addressed to the

Registration Authority 10 (the dashed line in FIG. 2).

If the Registration Authority 10 of the party 12, 13 verifies the party positively, i.e. party's identity and other information match, it sends an approval message (Step C) to the organisation operating the transaction server 11. Using the approval message content of Step C in the transaction server 11 a profile for the party will be built, Step D.

Each profile contains at least the party's identification and those other data, which are required to process the transactions as being used.

The profile further may contain data, relevant to a personalized token, which has been or will be issued to the party.

Although cryptography is not required for the invention, still the profile may contain cryptographic keys, to enhance the security of the communication between the transaction server and the party.

The profile may contain a random data string, which acts as a pseudonym for the party identified. The profile further may contain a payment method list, indicating the various payment methods permitted for that party.

Each payment method in the profile may be identified by a random data string.

The profile may contain further data fields for other applications, e.g. electronic cash, loyalty programs, telebanking, stock brokerage, etc.

Finally, in step E, the organisation operating the transaction server 11, which may also be a supplier or a bank, ensures that the party receives a personalised package, required to interface with the transaction system offered, and to be used with the party's data processing system to be coupled to the data networks. The content of this package (data, program and token) mirrors the profile, as registered in the transaction server. Parts of the package may be distributed to the party, using other channels, including electronic means, like electronic mail, or using other suppliers, e.g. a shop, the Registration Authority, or the like.

In FIG. 3 various entities are indicated.

Parties 21, 23 that want to make use of the transaction system may use a token reader 22, 24. This token reader is used to read the token, required for generating a digital signature of (selected parts of) message(s) in the transaction. Parties communicate through a data network 26, e.g. Internet. A secure and trusted transaction server 20 is also connected to the same data network, in order to receive messages from parties 31, 23. The transaction server 20 processes the transactions, after thorough verification of the validity of the transactions, using the party's profiles, as stored in the transaction server 20. If the transaction involves a payment, the payment process (authorisation and settlement) is handled through the payment network 25, using the procedures that apply for such situations.

When the customer 2 in FIG. 1 wants to perform a transaction from another location than his base location (the location equipped with standard configured/personalized means for performing transactions according to the invention), or otherwise is requested to authenticate himself, this can be achieved by downloading a temporary set of data and program, as depicted in step E in FIG. 2 at the not at base location. A not at base location could be a workstation at the office, a Cybercafe, a PDA (Personal Digital Assistant) with mobile phone function attached, or otherwise, provided that such a system offers access to the data network and is equipped with a token read facility.

As soon as an authentication request is due and the not at base system detects an unknown token (i.e. a token, which is not registered with the token reader, data and program, as referred to in step E of FIG. 2), the user is prompted to enter data, containing the address of the transaction server, his remote ID and, if required, his password. It the token possesses a memory, these data may be obtained from that memory. A message is built, containing the user data entered and provided with a hash and (token based) is signature, similar to the payment order as in (c) of FIG. 9, to be discussed below. The message is now transferred to the transaction server which, after verification of the correctness of the message received and the existence of a profile for that user, will send a temporary set of data and program to the not at base system. Now the not at base system is able to prepare a transaction message, or to authenticate the user, and proceed as normal. Depending of the agreed conditions, the temporary set of data and program will be erased or maintained for a set period.

FIG. 4 depicts a sample flow for a typical transaction.

(a) A first party 30 and a second party 31 negotiate a transaction, hi an Internet environment the first party, e.g. a customer will through his browser visit a site of the second party (e.g. a supplier) and request for a transaction, e.g. purchase goods, buy and sell stock, obtain information, or the like.

(b) The second party may require some proof of identity of the first party. He therefore sends a "Who are You" message to the first party.

(c) The first party adds his identity, as registered in his profile 33 at the transaction server 32 to the "Who are You" message and completes the message with a unique transaction number, a Hash total calculated over the previous data items, and his digital signature. This message ("I am") is then transferred to the transaction server.

(d) The transaction server verifies the message, received from the first party. If the message and the first party are verified positively, the server sends a message to the second party, confirming the identity of the first party and requesting the second party to identify himself.

(e) The second party adds to the message, received from the server, his identity, as registered in his profile 34, a "form" (e.g. a HTML page in case of Internet) in which the first party can fill in the details of his transaction request, a unique transaction number, a Hash total calculated over the previous data items, and his digital signature.

(f) Similar to step (d), the transaction server verifies the message received from the second party and his identity. If verified positively, the form is transferred to the first party. (g) The first party now fills in the form with the transaction details, as requested, adds a unique transaction number, a Hash total and his digital signature, and sands it to the server.

(h) The server verifies the message and, if verified positively, transfers the filled in form to the second party.

(i) The second party replies to the transaction details, as filled in in the form with a message, completed with a unique transaction number, a Hash total calculated over the previous data items, and his digital signature. (j) The server verifies the message received, and if verified positively, transfers the reply to the first party.

Steps (g) to (j) may be repeated, if more transactions are to be performed in the same session.

The verification of the messages as in (d), (f), (h) and (j) may be executed on the basis of a risk profile. If the risk profile does not demand immediate verification, the verification may be postponed until a request of either party is received to verify the messages, e.g. in case of a dispute about a certain transaction.

The creation of the digital signature may be performed as described in FIG. 6 below.

FIG. 5 depicts a sample flow how a party 40 can obtain a temporary profile, if he uses another system than the one, which has been personalised according to step E in FIG. 2.

Where in FIG. 4 step (c) should start, the system detects a token, for which the system has not been personalised.

(a) It therefore sends a request to the server 42 to receive a temporary profile. The message contains at least the server address and a user identification. These data are either collected from the first party's token, using a token reader 41 or entered manually. To enhance the security the message may be provided with a digital signature, generated in the same way as at the payment order. For further security the first party may have to include a Personal Identification Number (PIN) or any other personal identifier, e.g. a password or biometric quality.

(b) After positive verification of the request for a temporary profile, using the party's profile 43, the server returns a message, containing a temporary personalised package, which is in essence the same as in step E of FIG. 2, but may contain certain usage restrictions, like validity period or services granted. The validity period may be one transaction, a limited number of transactions, or an agreed time period, whatever has been agreed at the time the profile has been set up (step D in FIG. 2).

As an additional service, the server may log the full transaction details, to be collected by the first party at a later time, when he connects to the server from the system, which has initially been personalised for using the transaction method described.

Pointer Method

With the pointer method, as depicted in FIG. 6, it is possible to generate an electronic signature over a given set of data.

Assume a table 46 of random numbers. The table 46 may be the read result of a token, e.g. a 3DAS.RTM. card. Assume the number of elements in the table 46 equals n. Further assume that each number has a value between 0 and 255.

Assume the defined length of the signature is m bytes, where m is smaller than n.

In the example, depicted in FIG. 6, n equals 35 and m equals 5. Then an electronic signature over a given set of data D can be calculated:

compress D, using a hashing technique and/or some other method resulting into d;

d has the property that it can be split into at least n digits, each representing a value between 1 and m; preferably m is replaced by m', where m' is the largest power of 2 smaller than m. hi the example d becomes the string: 1, 9, 20, 16, 30;

identify the elements in the table of random numbers with the values 1 to m. In the example the elements are numbered column by column, starting at the top;

the digital signature now is the string of values of the elements taken from the random table, identified by the values in d. In the example the digital signature becomes the string: 128, 27, 5, 99, 38.

FIG. 7 illustrates how a table of random numbers may be generated, using a material with a random structure.

Assume a token (e.g. a credit card), which is provided with a random two dimensional or three dimensional structure (e.g. a 3DAS.RTM. card).

The taken is inserted in a token reader 50. In the token reader 50 an image is taken from the random structure in the token, which is in the case of a 3DAS.RTM. card an image as the sample image 51. In the image empty spaces are visible between the mapping of the random structure as blank areas. The areas are measured, and the n largest areas are selected (52). For each of the selected areas its centre of Gravity (CoG) is calculated as a pair of coordinates (53). A table 54 now is filled with the sizes (first column of the table) and the corresponding coordinates of the CoG (second and third columns of the table). As the original material used is random, also the values in the table 54 are random.

Referring again to FIG. 1, the customer is indicated with 2 and the supplier with 3. The customer profile may contain, as earlier indicated, among others the account/card related data and data fields for other applications, e.g. electronic cash, loyalty programs, electronic banking, stock brokerage, etc. To enable 1—1 marketing a further data file is added. It should be noted, that all the information, stored in the customer profile is present with the customer's agreement, as he did sign up for the transaction solution described. Upon given criteria, any of the parties 2, 3 and 6 may leave a message in the data file, destined for one of the other parties. This message is stored in the format, applicable for the is network solution chosen, through which the customer communicates with the transaction server, hi case of Internet this will be an HTML page or the like.

As soon as the destination party connects to the transaction server and the party's authenticity has been established, he will be prompted by the transaction server that a message is present for him. The party may neglect the prompt or decide to read the message. The message itself may link to other messages, stored elsewhere in the data network (e.g. Internet). E.g., if an acquirer wants to make an offer to the customer, the message may contain links to the acquirer's website, containing further information. As an example, an acquirer may offer extra bonus miles if the customer selects Mastercard as payment method for paying an international flight, the message then could be an HTML page: "Dear customer, you may earn extra bonus miles if you pay your international flight, using your Mastercard. If you are interested, visit our website at www.Acquirer.com\ If the customer is interested, he just clicks the website's reference and can access all the relevant data on how to obtain the extra bonus miles and the conditions.

The criteria, used to add a message to the customer profile, may refer to general attributes, belonging to the profile, e.g. which payment methods are enabled for that customer, or refer to specific attributes, e.g. the current transaction, his collected bonus etc.

If a first party wishes to send a message to a second party based upon a given selection criterion, applicable to such second party, the first party sends the message together with the selection criterion to the transaction server. The transaction server now selects all second parties, that match the criterion and adds to their profiles a data file, containing the message concerned, or if such data file already exists, adds the message to that data file. The criterion may include a validity time, i.e. a time within which this criterion should be applied, hi that case the transaction is server will monitor changes in the second party's profile. If ouch a change might result in that the second party meets the criterion, the message is added to his profile as described above. As an example, an issuer may offer a special financing arrangement to any customer buying a car during a given month. The criterion is a customer buying a car. The validity time is the given month. As soon as the transaction server detects a transaction, in which a customer is buying a car (or might be expected to do so, based upon the supplier's profile, i.e. the supplier is a car seller), the transaction server adds the message to the customer's profile and prompts the customer that there is a message for him.

When applying this method the privacy of the customer is guaranteed, no information is disclosed to (in the example) the issuer, unless the customer decides to contact the issuer and apply for the special financing arrangement.

If no direct payment is involved between a first and a second party, FIG. 8 shows how the transaction will be protected, whereby the authentication of both parties, the transaction messages and the irrefutability of the transaction can be guaranteed, using the same mechanisms as described hereafter with reference to FIG. 9. The first party is the one, requesting a service. The first party may be a consumer, but also a professional (as in business to business electronic commerce, B2B). The second party is the supplier of the requested services. In step (50) the first party visits a site of the second party and indicates his desire to perform a certain kind of transaction. The second party sends a signed request for log-in to the first party (51), whereby his signature is generated similarly to the invoice message as in step (b) of FIG. 9 to be described hereafter.

The first party processes the log-in request (52) similar to preparing a payment order, as in step (c) of FIG. 9 and transmits the message to a secure transaction server.

The server verifies the message form step (52), using the profiles of both parties. If verification is positive, the server passes the log-in data to second party (53).

The second party checks the authorisation of the first party to perform the requested transaction and returns a signed application form (54) to the server. The application form is a data file (e.g. an HTML page) the first party can use to enter the transaction data. The server verifies the validity of the application form and transfers it to the first party ($5).

The first party fills in the application form and signs it similar to the payment order message as in step (c) of FIG. 9. The form is then transmitted (56) to the server.

After verification by the server (57) the application form is passed to the second party, to be further processed.

Steps (54) to (57) may be repeated, depending on the context of the transaction.

Authenticity of the parties, the transaction and its irrefutability are thus guaranteed by the secure transaction server.

FIG. 9 depicts a sample flow for a typical transaction involving a payment

(a) A first and a second party negotiate a purchase. In an Internet environment the first party, e.g. a consumer will through his browser visit a site of the second party (e.g. a merchant) and pursue a normal electronic shopping process by picking goods and storing them in a so-called shopping basket. When he has completed the shopping process, he sends a buying order to the second party.

(b) If the second party accepts the order, he will prepare an invoice message and transmit this to the first party.

The invoice message contains: an identification of the second party, a content of the sale, an amount due, a payment accepting method, a unique transaction number, a Hash total (HashM) calculated over the previous data items, and a digital signature of the second party, calculated over HashM, as exemplified below.

The identification of the second party may be replaced by his pseudonym, as registered at the transaction server, to enhance privacy as his true identity now is covert, without the need for cryptography. The payment accepting method may be replaced by the random selected key, pointing to the required payment accepting method, as registered in the transaction server, to enhance privacy as his payment accepting method data now are covert, without the need for cryptography.

The digital signature may be generated using a token.

The digital signature may be generated using the pointer method, as elucidated below. The token used in this case may be a 3DAS.RTM. object, such as a card, with an optically scannable three- dimensional pattern of randomly overlying fibres, as disclosed in U.S. Pat. Nos. 5,354,097 and 5,719,939, and Dutch Patent No. 1,000,330, which documents are incorporated herein by reference. The card can be read with an appropriate reading device. This eliminates the need for cryptography.

If a 3DAS.RTM. card is used as token, any jitter in the reading of the mark of the card may be used to make the transaction number unique and guarantees at the same time, that the token has been read and processed.

(c) After receiving the invoice, the first party prepares a payment message and transmits this to the transaction server. This message contains: an identification of the first party, a copy of the invoice message, a payment method, a unique transaction number, a Hash total (HashC) calculated over the previous data items, and a digital signature of the first party, calculated over HashC, as exemplified below.

The content of the sale may be deleted from the copy of the invoice message, enhancing privacy by not transmitting this information.

The HashC may be deleted from the payment message.

The identification of the first party may be replaced by his pseudonym, as registered at the transaction server, to enhance privacy as his true identity now is covert, without the need for cryptography.

The payment method may be replaced by a random selected key, pointing to the required payment method, as registered in the transaction server, to enhance privacy as his payment method data now are covert, without the need for cryptography.

The digital signature may be generated using a token.

The digital signature may be generated using the pointer method as elucidated below. The token used in this case may be a card like a 3DAS.RTM. card. This eliminates the need for cryptography.

If a 3DAS.RTM. card is used as token, the jitter in the reading of the card may be used to make the transaction number unique and guarantees at the same time, that the token has been read and processed.

The digital signature also may include a personal identification, such as a Personal Identification Number (PIN) as is generally used when one wants to withdraw money through an Automated Teller Machine (ATM), a personal identification code or character string, a biometric feature, or any other feature which is strictly personal.

(d) After receiving the payment message, the transaction server starts verifying the message received. Depending on first party's payment method and second party's payment accepting method the authenticity of both parties are verified by the transaction server itself or by a financial institution concerned.

If 3DAS.RTM. cards are used as token, the transaction numbers, generated by either party will prove that an actual read has been performed, reducing the chance for counterfeit attacks, such as replay.

(e) Using the information in the first and second party's profiles the transaction server now builds an authorisation request message and/or settlement messages as agreed with the financial institution concerned. In the example of FIG. 9 an authorisation request message is build and transmitted to an acquirer bank (a merchants bank as indicated by his payment accepting method).

(f) If the authorisation for the payment is granted, the financial institution concerned (in the example of FIG. 9 the acquirer bank) will prepare for settlement of the payment transaction.

(g) The financial institution concerned will inform the transaction server whether the payment is authorised.

(h) Finally the transaction server informs both parties about the result of the authorisation.

These messages may contain a random number, which then is used to modify the party's pseudonym and the keys, identifying the payment methods. This will reduce the possibilities for possible attackers to replay a transaction or to act as impostor.

Modifications within the spirit and scope of the invention may readily be effected by persons skilled in the art. It is to be understood, therefore, that this invention is not limited to the particular embodiments described by way of example hereinabove.

Claims

1. A method for sending an authenticatable message, containing message data, from a data input/output device of a first party via a data network to a data input/output device of a second party, comprising: providing a message having message data in the data input/output device of a first party; providing a table of n random numbers in the data input/output device of the first party, each number having a predetermined position in the table; splitting the message data into m digits by the input/ontput device of the first party, the splitting comprising subjecting the message data to a hashing operation to provide a hashing code, and splitting the hashing code into m digits, each digit representing a value between 1 and n, where m is smaller than n; assembling a digital signature in the input/output device of the first party, wherein the digital signature comprises a string of the random numbers of which the position in the table is indicated by the digits, and wherein the digital signature is validatable by comparison with a registered first party reference profile; adding the digital signature to the message to form an authenticatable message; and sending, via a data network, the digitally signed message to an input/output device of a second party.

2. The method of claim 1, wherein the table of random numbers is generated by reading a token.

3. The method of claim 1, wherein the table of random numbers is generated by optically scanning geometrical configurations of a randomly shaped two-dimensional or three-dimensional mark, and converting the geometrical configurations into the table of random numbers.

4. The method of claim 1, wherein the digital signature includes a personal identification.

5. A data processing system for generating a digital signature for a message containing message data to be sent via a data network, the system comprising: a input/output device having a storage device connected thereto for storing a message having message data; means, operative with the input/output device for providing a table of n random numbers, each having a predetermined position in the table; means, operative with the input/output device, for splitting dividing the message data into m digits, the splitting means comprising means for subjecting the message data to a hashing operation to provide a hashing code, and means for splitting the hashing code into m digits, each digit representing a value between 1 and n, where m is smaller than n; and means, operative with the input/output device, for assembling a digital signature comprising a string of the random numbers of which the position in the table is indicated by the digits, the signature suitable to be added to the message prior to sending the message over the network.

6. The system of claim 5, wherein the means for providing the table of random numbers comprises a token and a token reader.

7. The system of claim 6, wherein the token is an object provided with an optically scannable randomly shaped, two-dimensional or three-dimensional mark having geometrical configurations, and wherein the system comprises means for converting the geometrical configurations into the table of random numbers.

8. A method for handling a purchasing transaction between a first party using a first party processor and a second party using a second party processor communicating over a global computer network and comprising the steps of: generating a plurality of pre-paid cards in an unactivated state, each card having a unique card identifier; providing said cards at a distribution site; exchanging currency received from the first party at said distribution site for at least one pre- paid card; collecting the currency from said distribution site and depositing the currency in a first repository; activating said pre-paid card at an activation site by requesting and receiving a set of first party information; generating a user record based on said first party information and storing said record in a transactional database maintained by a third party administrator; accessing a merchant site having a merchant display generated by a display code capable of displaying a plurality of graphical features including salable items via the global computer network; selecting and confirming at least one salable item to be purchased; presenting the first party with a pre-paid card purchasing option having an associated link; selecting said pre-paid card purchasing option; accessing a third party administrative processor including a transactional computer program having a new page generating algorithm and a fund verification algorithm; initiating said new page generating algorithm to obtain said display code and reconfigure said code to generate a new display page in the form of an active server page including a query form requesting user response information and a selection of said graphical features; forwarding said new display page to the first party processor and terminating communication with the second party; receiving said requested user response information; accessing said fund verification algorithm and said transactional database to verify the viability of the transaction; if such transaction is viable, submitting a fund transfer request to said first repository to transfer funds to a second repository associated with the second party; sending a reference approval number to the first party; reestablishing communication with the second party and sending a notification of said fund transfer request; and forwarding said selected salable item from the second party to the first party.

9. A system for handling a purchasing transaction as set forth in claim 8 wherein: if such transaction is not viable, sending notification to the first party.

10. A method for handling a purchasing transaction between a first party having a first party processor and a second party having a second party processor communicating over a communications network and comprising the steps of: providing a plurality of pre-paid cards for exchange at a distribution site in an unactivated state, each said pre-paid card having a unique card identifier; activating said pre-paid card at an activation site upon requesting and receiving a set of first party information; generating a user record based on said first party information and storing said record in a transactional database; establishing communication with a second party processor and displaying on a first party display device a second party display generated by a display code capable of generating a plurality of media features including salable items via the communications network upon receiving a request from said first party for a second party display; upon receipt of a selection of at least one salable item to be purchased, transmitting a pre-paid card purchasing option having an associated link to said first party processor for display on said first party display device; upon receipt of the selection of said pre-paid card purchasing option, accessing an administrative processor including a transactional computer program having a new page generating algorithm and a fund verification algorithm and initiating said new page generating algorithm to obtain said display code and reconfigure said code to generate a new display page in the form of an active server page including a query form requesting user response information and a selection of said graphical features; forwarding said new display page to the first party processor for display on said first party display device and terminating communication with the second party processor; upon receipt of said requested user response information, accessing said fund verification algorithm and said transactional database to verify the viability of the transaction; if such transaction is viable, submitting a fund transfer request to a first repository associated with said first party to transfer funds to a second repository associated with the second party; reestablishing communication with the second party processor and sending a notification of said fund transfer request; and forwarding said selected salable item from the second party to the first party.

11. A system for handling a purchasing transaction as set forth in claim 10 wherein: if such transaction is not viable, sending notification to the first party.

12. A method of receiving and executing security orders from one or more investors comprising the steps of: a) receiving a plurality of security orders from the one or more investors over the Internet wherein the type of security orders includes at least a plurality of buy orders for the same security wherein the plurality of buy orders are specified by the one or more investors in dollar amounts and include an order to purchase at least a fractional share of the security; b) combining the plurality of security orders by same type and same issuer into one or more combined security orders; and c) executing the one or more combined security orders as a single trade or transaction per combined security order through the exchange.

13. The method of claim 12, wherein: d) the step of receiving is a step of receiving the plurality of security orders in real-time for the purchase or sale of common or preferred stock through an exchange; and e) the step of executing is performed at a predetermined time not in real-time relative to when the step of receiving occurs.

14. The method of claim 12, wherein the step of combining includes combining of the plurality of fractional buy orders of the same type of security and the same issuer into combined buy orders.

15. The method of claim 12, wherein the step of combining further comprises a step of combining a buy order from a clearing account such that each combined security order results in an order for a whole number of shares.

16. The method of claim 12, further comprising the steps of: d) receiving a plurality of sell orders from the one or more investors; e) combining the plurality of sell orders by same type and same issuer into one or more combined sell orders; and f) executing the one or more combined sell orders as a single trade or transaction per combined sell order through the exchange.

17. The method of claim 12, wherein the steps of receiving and executing security orders allows a reduced cost to each individual investor by sharing at least a portion of the cost of the combined security orders among the plurality of investors through the combination of buy orders or sell orders of the same type and same issuer.

18. The method of claim 12, wherein the plurality of buy orders are received in real-time and are for the purchase of common stock.

19. The method of claim 12, wherein the receiving, combining, and executing steps are repeated for all buy orders received in the receiving step and combined buy orders are executed for each issuer.

20. A method of receiving and executing sell orders from one or more investors comprising the steps of: a) receiving a plurality of sell orders for differing issuers from the one or more investors over the Internet, wherein the sell orders each include a sell quantity that is specified in whole shares, fractional shares, or whole and fractional shares; b) aggregating the plurality of sell order by issue to determine an aggregate sell amount for each issuer; c) for each issuer for which the aggregate sell amount is not a whole number of shares, adding a rounding sell order for that issuer to the plurality of sell orders to round the aggregate sell amount for that issuer to a whole number of shares, thereby forming a combined sell order for each issuer with the number of shares in the combined sell order being a whole number; d) executing each combined sell order on an exchange; and e) allocating funds obtained in the step of executing to each of the one or more investors according to the sell quantities specified in their sell orders and a share price obtained in the step of executing.

21. The method of claim 21, further comprising a step of allocating funds obtained in the step of executing to a clearing account according to the sell quantity of the rounding sell order if a rounding sell order was used to round a combined sell order.