(b) Description of the Related Art Since the London Metal Exchange (LME) was established in 1876, it remains unique amongst the terminal markets in that, among other things, transactions between brokers and customers (Client Contract) are on a principal-to-principal base. In the Ring, transactions among members (Exchange Contract) are made by an open outcry method like exchanges in other parts of the world, giving equal opportunities to buyers and sellers.

Customers (producers, traders and end-users) have to contact one or more members or brokers to get quotations for their needs for buying or selling certain tonnages of base metals. Theoretically, a customer can contact as many brokers as he wishes at the same time if he uses many

telephone lines and then compare the quotations to get the best result.

Practically, the customer contacts brokers one by one while prices change continuously. If he gets what he thinks is the best price, it may not be a result of comparing multiple quotations at the same time, but rather it might result from the fact that the price changed in his favor. Thus, it is difficult to say that he can get a better result by contacting multiple brokers in series, because the price moves against his favor as well as in his favor. On the other hand, a customer's identity is known to brokers even before the transaction is made, while the customer sometimes requires anonymity until the transaction is concluded, and even after the transaction is made.

Due to the unique system of the LME, each customer's position is in his account at the brokers, and there are many prompt dates for the contracts. Both factors make it difficult for customers to open a position with one broker and to close it with another. Those two opposite positions can be offset by several methods, but not automatically. And giving up a position from an account at one broker to another account at another broker is not always guaranteed.

Therefore, an auction system for the Client Contracts of the LME can be easily utilized if and when giving up positions is guaranteed by a prearranged give-up process that makes offsetting opposite positions smooth and easy.

SUMMARY OF THE INVENTION It is an object of the present invention to provide a method and apparatus for a customer to concurrently request quotations from a plurality of brokers.

It is another object of the present invention to provide a method and apparatus for implementing processes of giving up and transferring positions between brokers.

It is a further object of the present invention to provide a method and apparatus for brokers to execute transactions without checking margin requirements of unknown customers.

In one aspect of the present invention, in an apparatus for intermediating futures transactions between customers and brokers in futures exchanges, a futures transaction intermediating apparatus comprises: a central controller receiving a request for a quotation (RFQ) from the customer, checking the customer's margin, and transmitting the RFQ to a plurality of brokers in order for the brokers to use the RFQ; a broker interface communicating with the brokers coupled to the central controller ; and a customer interface communicating with the customers coupled to the central controller.

In another aspect of the present invention, a futures transaction intermediating method between customers and brokers comprises steps of: (a) a central controller receiving a request for a quotation (RFQ) generated by a customer; (b) the central controller checking the RFQ; (c) the central

controller transmitting the RFQ to a plurality of brokers; (d) the central controller receiving the quotations provided by the brokers without the brokers'checking the customers'margins; and (e) the central controller receiving an acceptance of the quotations from the customer and concluding the transactions.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate an embodiment of the invention, and, together with the description, serve to explain the principles of the invention: FIG. 1 shows a block diagram of an apparatus for intermediating futures transactions according to a preferred embodiment of the present invention; FIG. 2 shows a block diagram for requesting and processing quotations between the customers and the brokers according to the preferred embodiment of the present invention; FIG. 3 shows a block diagram for an offset process according to the preferred embodiment of the present invention; FIG. 4 shows a detailed block diagram of a central controller according to the preferred embodiment of the present invention; FIG. 5 shows a detailed block diagram of a broker interface according to the preferred embodiment of the present invention;

FIG. 6 shows a detailed block diagram of a customer interface according to the preferred embodiment of the present invention; FIG. 7 shows a flow chart for a customer's generation of a request for a quotation (RFQ) according to the preferred embodiment of the present invention; FIG. 8 (a) shows a flow chart of a process whereby a margin is confirmed before the quotation is requested according to the preferred embodiment of the present invention; FIG. 8 (b) shows a flow chart of a process whereby a central controller provides a customer with information on whether the customer has the margin and the customer is requested to pay the margin according to the preferred embodiment of the present invention; FIG. 9 shows a flow chart of a process of conducting an examination on the customer's RFQ according to the preferred embodiment of the present invention; FIG. 10 shows a flow chart of a process whereby the broker provides the quotation to the customer according to the preferred embodiment of the present invention; FIG. 11 shows a flow chart of a process of an execution of the transaction according to the preferred embodiment of the present invention; FIG. 12 shows a flow chart of a process of an offset of the positions according to the preferred embodiment of the present invention; FIG. 13 shows a flow chart of a process of changing positions from a first broker to a second broker according to the preferred embodiment of the present invention; and FIG. 14 shows a flow chart of a process of a prearrangement of a give-up agreement.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the following detailed description, only the preferred embodiment of the invention has been shown and described, simply by way of illustration of the best mode contemplated by the inventor (s) of carrying out the invention. As will be realized, the invention is capable of modification in various obvious respects, all without departing from the invention.

Accordingly, the drawings and description are to be regarded as illustrative in nature, and not restrictive.

FIG. 1 shows a block diagram of an apparatus for intermediating futures transactions according to a preferred embodiment of the present invention.

As shown, the futures transactions intermediating apparatus comprises a central controller 400, a plurality of broker interfaces 500 and a customer interface 600. Nodes are respectively connected via Internet connections using public switched phone networks, data lines, mobile networks (cellular phones and PCSs) or satellite networks. The broker interface 500 and the customer interface 600 are provided as input/output gateways for communications with the central controller 400.

By using the above-noted components, the central controller 400 receives RFQs from the customers, makes the RFQs available to a plurality of the brokers and allows binding transactions between the customers and the brokers.

FIG. 2 shows a block diagram for requesting and processing quotations between the customers and the brokers according to the preferred embodiment of the present invention.

As shown, a customer logs in to the central controller 400 by using the customer interface 600 to create an RFQ 100 and transmit the RFQ to the central controller 400. The central controller 400 checks the RFQ 100 provided by the customer and transmits the same to the brokers. After receiving the RFQ 100, the brokers transmit the quotation to the central controller 400. The central controller 300 then transmits the quotation 110 to the customer.

FIG. 3 shows a block diagram for an offset process according to the preferred embodiment of the present invention.

As shown, when a customer generates an offsetting order 300, the central controller 400 transmits the offsetting order 300 to the brokers. The brokers check the offsetting order 300 and transmit a message on the receipt confirmation of the offsetting order 300 to the central controller 400. The central controller 400 transmits the message to the customer. According to a prearranged give-up agreement, the brokers give up the customer's position to another broker in correspondence with the offsetting order provided by the

customer.

FIG. 4 shows a detailed block diagram of a central controller according to the preferred embodiment of the present invention.

As shown, the central controller comprises a central processing unit (CPU) 405, a position management processor 407, an account management processor 410, a margin requirement processor 415, an auction control processor 420, an RFQ generation processor 425, a transaction tracking processor 430, a transaction confirmation processor 435, an offsetting requirement processor 437, a synchronizing processor 439, a cryptographic processor 440, a network interface 445 and a data storage device 450.

The central controller 400 operates as a web server, both receiving and transmitting the RFQs 100 generated by the customers. A conventional computer workstation or server with sufficient memory and processing capabilities can be used as the central controller 400. A microprocessor such as 400MHz UltraSPARC-II, manufactured by Sun Microsystems Inc., may be used for the CPU 405.

The data storage device 450 stores the data used in processing the transactions of the present invention.

Magnetic storage devices such as hard disk drives or optical storage devices such as CD-ROM drives or flash memory can be used for the data storage device 450. The data storage device 450 comprises a broker database 455, a customer database 460, an account database 465, a

margin checking factor database 467, a customer position management database 470, an RFQ history database 475, a final confirmation history database 480, an audit database 485, a certificate database 490 and a bill information database 495. For example, database software such as Oracle 8, manufactured by Oracle Corporation, can be used to create and manage the above-mentioned databases.

The broker database 455 stores data on the brokers such as names, contract information, type of members, transaction and give-up agreements with the customers and public/private key information. The contact information comprises authorized transactors, phone numbers of the transactors, web page uniform resource locators (URLs), electronic mail addresses, facsimile numbers, or any other possible methods arranged for mutual communications between the customers and the brokers.

The customer database 460 stores data on the customers such as customer names, addresses, authorized transactors, phone numbers of the transactors, web page URLs, electronic mail addresses, facsimile numbers, past system usage and public/private key information.

The account database 465 stores data on the customer's accounts opened at the brokers such as credit lines extended, initial margin rates, transaction limits and transaction key information.

The margin checking factor database 467 stores data on the factors necessary to calculate margin requirements, such as credit lines, initial

margin rates, variation margins, account balances and net positions.

The customer position management database 470, managing the data on the customers'positions, stores contractual information such as contracts, quantities, prompt dates, and prices.

The RFQ history database 475, managing data on the RFQs, stores the tracking history of each RFQ 100 generated by the customer.

The audit database 485 stores transactional information relating to the auction to be retrieved for a later analysis.

The certificate database 490 stores certificates of both the brokers and customers for authentication and encryption, and it facilitates cryptographic functions, storing both symmetric and asymmetric keys. By using these keys, the cryptographic processor 440 encrypts and decrypts the data transmitted on the Internet.

The bill information database 495 stores contents of the bills of additional margins. Here, the brokers require the above-noted bills in order for the customers to pay additional margins in the case the positions of the customers have margin calls.

The network interface 445 is the gateway to communicate with the customers and the brokers through the broker Interface 500 and the customer interface 600. Conventional built-in or external modems or local area network (LAN) cards can be used for the network interface 445.

FIGs. 5 and 6 show the broker interface 500 and the customer

interface 600, respectively. These interfaces are connected with the central controller 400.

FIG. 5 shows a detailed block diagram of a broker interface according to the preferred embodiment of the present invention.

As shown, the broker interface 500 comprises a central processing unit (CPU) 505, an RFQ receiving processor 510, a synchronizing processor 520, a video driver 530, a video monitor 540 and a data storage device 550.

The synchronizing processor 520 tracks events of the customers' accounts and synchronizes the events with the customers'accounts at the central controller 400.

The data storage device 550 comprises a messaging database 570 and an audit database 580. A conventional magnetic-based hard disk storage unit such as those manufactured by Conner Peripherals can be used as the data storage device 550.

The messaging database 570, managing the messages of the customers and the brokers, can be used for archiving brokers'responses as well as customers'and/or brokers'special transaction conditions.

The audit database 580 stores payment records and accesses history to the central controller 400.

FIG. 6 shows a detailed block diagram of a customer interface according to the preferred embodiment of the present invention.

As shown, the customer interface 600 comprises a central processor

unit (CPU) 605, a transaction confirmation receiving processor 620, a video driver 630, a video monitor 640 and a data storage device 650. All of these components are identical to those described in FIG. 5, except for the transaction confirmation receiving processor 620. The trade confirmation receiving processor 620 receives a final confirmation from the central controller 400 and performs a cross check on the final confirmation with the RFQ 100.

The configuration components of the system according to the preferred embodiment of the present invention can be implemented on a single computer, and further, it can be implemented as additional software installed on a single computer or as a single software program having a plurality of different functions.

There are many software applications that enable the communications required by the broker interface 500 and the customer interface 600, the primary functionality being message creation and transmission. When the central controller 400 is configured as a web server, conventional communications software such as the Netscape web browser from Netscape Corporation may be used. The customers can use the Netscape Navigator browser to transmit the RFQ 100. No proprietary software is required.

Transactions between a customer and brokers at the London Metal Exchange will now be described as a preferred embodiment of the present

invention.

The customer logs in to the central controller 400, creates an RFQ 100, and waits for the brokers'quotations 110. The central controller 400 checks the margin checking factor database 467 so as to check the margin required by the brokers, and transmits the RFQ 100 to the brokers whose customers have sufficient margins satisfying the requirements of the brokers.

The brokers'quotations 110 are electronically transmitted to the central controller 400, which transmits the quotations 110 to the customers for the customer's decision.

FIG. 7 shows a flow chart for a customer's generation of a RFQ according to the preferred embodiment of the present invention.

The customer logs in to the central controller 400 using the customer interface 600 in step S700. The central controller 400 has a page on the World Wide Web, allowing the customer to provide information through the interface of the conventional web browser software such as MS Explorer, manufactured by Microsoft. Inc.

The customer selects a contract product from the contract list of the LME and LBMA in step S710. As shown in step S711, the contract products include Cu (Copper Grade'A'), Al (Aluminum Primary High Grade), AA (Aluminum Alloy), ZS (Zinc Special High Grade), Pb (Standard Lead), Sn (Tin), Ni (Primary Nickel) and Ag (Silver) from the London Metal Exchange and Au (Gold) and Ag (Silver) from the London Bullion Market Association

(LBMA).

Then the customer selects a desired type of order, such as auction- futures, auction-option, offsetting position, etc. in step S720. After the order type is selected, an order sheet is displayed on the video monitor 640 of the customer interface 600. This sheet is an electronic contract with terms and conditions to be selected or filled in by the customer who generated the RFQ 100. The customer selects a buy or a sell in step S721. The customer then inputs a desired quantity, a prompt date and currency in respective steps S722, S723 and S724. The customer determines whether a correction is needed in step S730, and inputs the correction in step S735. The customer provides his. password to the RFQ 100 in step S740, transmits the input items to the central controller 400 in step S745, and the central controller 400 receives the RFQ 100 from the customer in step S750.

FIG. 8 (a) shows a flow chart of a process whereby a margin is confirmed before the quotation is requested according to the preferred embodiment of the present invention.

The central controller 400 checks a net position from the contracts executed by the brokers in step S800. The central controller 400 then inputs the quantity of the RFQ 100 to the customer's net position by the brokers in step S810, and multiplies a current initial margin rate noted by the London Metal Exchange and the London Clearing House in order to obtain a full amount of the initial margin in step S811. The central controller 400 adds a variation margin to the initial margin in step S820, adds the credit lines

extended by the brokers in step S830, adds the customer's account balance to the above-added items in step S840, calculates the customer's margins with respect to the brokers in step S850, and determines whether the margin is sufficient in step S860. The central controller 400 moves to another broker so as to check the margins required by that broker, and repeats the above steps until the margins required by the broker are checked in step S870.

FIG. 8 (b) shows a flow chart of a process whereby a central controller provides a customer with information on whether the customer has the margin, and in which the customer is requested to pay the margin, according to the preferred embodiment of the present invention.

The central controller 400 checks the margins of all the customers every day after the market is closed, and provides the customer with information on whether the customer presently has the margin, and he is requested to pay the margin.

In detail, every day after the market is closed, the central controller 400 checks a net position from the contracts executed by the brokers in step S880. The central controller 400 multiplies a current initial margin rate noted by the London Metal Exchange and the London Clearing House in order to calculate the margin in step S881. The central controller 400 adds a variation margin to the initial margin in step S882, and adds the credit lines extended by the brokers in step S884.

The central controller 400 calculates the customer's margins with respect to the brokers in step S885, moves to another broker so as to check

the margins required by the broker, and repeats the above steps with respect to all the brokers in step S890.

The central controller 400 provides the customer with information on whether the customer presently has the margin, and he is requested to pay the margin in step S895.

FIG. 9 shows a flow chart of a process of conducting an examination on the customer's RFQ 100 according to the preferred embodiment of the present invention.

In this process, the central controller 400 checks whether a sufficient margin to cover the transactions is provided before the brokers use the RFQ 100.

In detail, the central controller 400 extracts contract products and quantities from the RFQ 100 in step S900, checks the customer's net position of the contract by broker in step S910, inputs the quantity of the RFQ 100 to the net position of the contract so as to calculate the addition and reduction of the initial margin in step 911, and checks whether a sufficient margin is provided in step S920. This process for checking the margin requirements is repeated for all the brokers in step 930.

If the provided margin is not sufficient, the broker's window is blocked in step 921, but if a sufficient margin is provided, the broker's window is then opened in step 922. At the same time, the broker's window is displayed on the customer's video monitor 640 so as to receive the broker's quotation 110 in step 923.

The central controller 400 provides specific RFQ numbers to the customer's RFQ in step 924, enters a time stamp in step 925, and transmits the RFQ 100 to the brokers in step 926.

FIG. 10 shows a flow chart of a process whereby the broker provides the quotation to the customer according to the preferred embodiment of the present invention.

The broker provides the quotation 110 upon receiving the RFQ 100 to the customers so as to compete against other brokers.

In detail, the broker receives the RFQ 100 in step S1000, provides the quotation 110 in step S1010, and then transmits the quotation to the central controller 400 in step S1011.

The central controller 400 transmits the quotations 110 in order of receipt in step S1020, and displays the quotations 110 of the brokers on the corresponding cell of the customer's monitor 640 in step S1030.

FIG. 11 shows a flow chart of a process of an execution of the transaction according to the preferred embodiment of the present invention.

The customer selects the best quotation and performs a transaction with the broker who provides the desired quotation.

In detail, the customer selects the best one from the quotations 110 displayed on the customer's monitor 640 in step S1100. The central controller 400 transmits an acceptance of the quotation provided by the customer to the broker in step S1110, and provides the customer's identity only to the broker selected by the customer in step S1111. Upon receiving

the acceptance of the quotation from the customer, the broker confirms the transaction in step S1120, inputs a contract number in step S1130, inputs necessary corrections in step S1131, and transmits the data to the central controller 400 in step S1132.

The central controller 400 receives the data from the broker in step S1140, and then deletes the RFQ 100 from other brokers'windows in step S1141. At the same time, the central controller 400 transmits the broker's confirmation on the transaction to the customer in step S1142, inputs the transaction history to an executed order page in step S1143, and stores the transaction data in the customer position management database in step S1144. The customer then receives the transaction data and thus the transaction is concluded in step S1150.

FIG. 12 shows a flow chart of a process of an offset of the positions according to the preferred embodiment of the present invention.

The central controller 400 checks, whenever the customer makes a new transaction, the customer's positions in the customer's accounts possessed by the other brokers in order to check whether an opposite position of the identical contract and identical prompt date is provided. When there is an opposite position in the customer's account possessed by the other brokers, the central controller 400 transmits an offsetting requirement to the customer in order for the customer to offset the positions.

FIG. 12 shows a flow chart of a process for offsetting the positions according to the preferred embodiment of the present invention.

The central controller 400 checks the customers'positions according to the prompt dates with respect to the respective brokers in step S1200.

When an opposite position is found, the central controller 400 transmits an offsetting position requirement to the corresponding customer in step S1210.

Upon receiving data in step S1220, the customer selects an offsetting position order to select the position to be offset in step S1230. The customer fills in the order form displayed on the customer monitor 640 in order to generate an offset order in step S1231. The customer then provides a password in step S1232 and transmits corresponding data to the central controller 400 in step S1233.

The central controller 400 receives the data from the customer in step S1240, inputs the order number in step S1242, inputs the time stamp in step S1244, and transmits the offsetting order 300 to both brokers concerned, one broker holding a long position and the other holding a short position in step S 1246.

The brokers receive the offsetting order 300 from the central controller 400 in step S1250. The brokers check the customer's position in step S1252, and transmit a transaction confirmation to the central controller 400 in step S1254. The broker designated by the customer also receives the offsetting order 300 in step S1260, checks the customer's position in step S1262, and transmits the transaction confirmation to the central controller 400 in step S1264.

The central controller 400 receives the transaction confirmation in step S1270, and transmits the same to the customer in step S1272. The customer receives the confirmation in step S1280.

FIG. 13 shows a flow chart of a process for giving up the positions from a first broker to a second broker according to the preferred embodiment of the present invention.

The first broker gives up the customer's positions to the second brokers following the customer's offsetting order 300 in accordance with a prearranged give-up process.

In detail, a broker holding a customer's position contacts the other broker, designated by the customer, who is holding the opposite position in step S1300. The broker gives up position to the other broker in step S1310, and transmits a completion of the give-up process to the central controller 400 in step S1320.

The designated broker agrees to the position offset in step S1301, and receives the position offset by the other broker in step S1311, and transmits the completion of the give-up process to the central controller 400 in step S1321.

The central controller 400 receives the data from both brokers in step S1330, stores the offsetting history to the customer database 460 in step S1331, and transmits the data to the customer in step 1332. The customer receives the data in step S1340.

FIG. 14 shows a flow chart of a process of a prearrangement of giving up agreement.

The prearranged give-up process is guaranteed by the give-up agreement duly signed by and between brokers and customers.

In detail, the broker checks and reviews the terms and conditions of the give-up agreement in step S1400. The broker agrees with the terms and conditions in step S1410, and signs the agreement in step S1420. The broker then transmits the agreement to the central controller 400 in step S1430.

The central controller 400 receives the agreement of the broker in step S1440, and transmits the same to the customer in step 1441, and stores the same to the broker database in step S1442. The customer receives the agreement of the broker in step S1450.

According to the present invention, the customer concurrently generates the requests for quotations to a plurality of the brokers so that the customer can perform the most profitable transaction, and the brokers can do business with the customer without confirming the customer's margins one by one. Since the brokers can offset the customers'opposite positions possessed by the brokers according to the prearranged position offset and transfer process, the transactions between the customers and the brokers in the futures exchange can be executed more efficiently.

Since the customer does not need to divulge his identity to the

brokers when requesting the quotations from the brokers, in the case the transactions are not completed, the identity of the customer is not known by the brokers.

Since the customer can offset the positions according to the prearranged offset, the customer is not required to pay an additional margin.

While this invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.