JP2000315235A - Asset transaction method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an asset transaction method via an asset transaction system that is exempted from the limitation of a conventional system by engaging a contract object in response to the engagement request of the contract object given from a transactor object. SOLUTION: A transactor objet 26A included in a booth process 30A of an asset seller forms a contractor object 50A for selling the assets and specifies the quantity, price and other transaction parameters. A transactor object 26B included in a booth process 30B of an asset buyer specifies the quantity, price and other parameters for transmitting the presence of interest and forms a notification filter object 52B. The object 26B receives a copy of the object 50A and decides to engage a contract as long as the object 50A is acceptable. The object 26 forms a contract object having the price, quantity and parameter and reports them to a user.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to an electronic trading system, and more particularly to an electronic trading system distributed on a network.

[0002]

2. Description of the Related Art Even in the prior art, an "electronic trading system"
(Also known as "electronic stock exchanges" or "trading matching networks") are widely known, but their systems are extremely complex, specialized, narrow in scope, and difficult to manage and use There is a disadvantage that. Generally, in those systems, the user enters the order electronically into a list or "board" of unfilled orders. These orders represent a desire to trade in goods or securities, according to a set of parameters managed and permitted by the exchange. Therefore, they are tailored to the specific market and have specific market specific parameters, restrictions and order matching rules. The programs, processes, and databases for individual exchanges are closely related to the individual products being traded. For example, consider the difference between an option exchange and an exchange that handles steel pipes. Options exchanges must have parameters, rules and procedures specific to the option contract and the underlying security. Exchanges that handle steel pipes also have a set of rules and parameters that are specific to this business area.

[0003]

In the prior art of the electronic trading system, knowledge of rules specific to the product to be traded is important for order matching between selling and buying. A system that uniquely matches the parameters is required. For example, in order to match options for buying and selling options for common stock, participants must discuss specific contract specifications (including strike price, underlying security or index, and time limit), number of contracts, and price per contract. Must agree. On the other hand, exchanges dealing with steel pipes will require type, shape, weight and price matching. In the prior art electronic trading, exchanges must match each individual market in order to match. Furthermore, when defining the matching rules, the convenience of the exchange, not the participant, is given top priority. That is, the matching strategy is determined by the exchange in view of the efficiency of matching and maximization of income. Thus, rather than the exchange meeting the needs of the individual participant, the participants must formulate their trading strategy to adapt to the mechanisms provided by the exchange. Thus, there is a need for a trading system that avoids these difficulties and gives traders flexibility.

[0004]

SUMMARY OF THE INVENTION The present invention provides an asset trading method using an asset trading system that avoids the limitations of conventional systems and provides other advantages that will be apparent to those skilled in the art. In a broad sense, the asset trading system of the present invention includes a virtual market and a plurality of trader client user workstations connected by a network, and trades can be performed without external mediation. The method includes forming a trader object associated with an asset to be traded and transmitting from one of the workstations to the virtual marketplace to form a received trader object, forming an object for immediate communication, and transmitting immediately. Object is stored on one of the workstations and is capable of interacting with the accepted trader object, wherein the trading system is independent of any rules or parameters associated with the traded asset; The accepted trader object forms a contract object, wherein the contract object comprises transaction parameters associated with the traded asset, and wherein the contract object is responsive to a contract request from the accepted trader object for the contract object. Contract objects are filled, thereby The so as to deal the assets between the virtual marketplace is complete and Deployment, and includes the stages.

[0005] For a more detailed explanation of the present invention, accompanying drawings are attached. These drawings are for illustrative purposes only, and should not be used to unduly limit the scope of the invention.

[0006]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An entire asset transaction system based on the principles of the present invention is shown at 20 in FIG. System 20 is coupled to a plurality of user workstations via support network 22. This support network can be a public network such as the Internet, for example, or it can be a private network. This network is maintained to access system 20. Preferably, the network 22 operates according to the TCP / IP protocol. Because transactions on the system 20 are executed without the need for external direction or intervention, the network 22 is not necessarily high-speed for the purpose of ensuring the fairness and fair access to transactions on the system. It does not need to be a network. A user of the system 20 uses the workstation 24 to
Form a software representative comprising a trader object 26 that is sent to the client and an immediate communication object 28 that is stored on the workstation for interacting with the trader object 26.

As shown in FIG. 2, the workstation is preferably equipped with a Java-enabled web browser such as that available from Netscape Communications. Browser 1
00 provides an execution environment for all software except for trader objects that are sent to system 20 to operate. Preferably, all programs provided by the system are written in the Java language so that they can run on all major computers and operating system platforms. The server also provides document screens (or documentation views) and licensing / encryption functions.

[0008] The workstation 24 also includes a license certificate for verification of the legitimacy of the account using the virtual marketplace. The license certificate and the encryption key are used for licensing and secure transmission of the trader object. When you open an account, the license certificate and the encryption key
Assigned by 0. Workstation 24 also
Pool of collective software representatives 10
4. Includes a complete set of software representative authoring tools 106, a software representative component library 108, and a market simulator 110 for software representative testing. The system document 112 also
It can also be provided by a server 48 within the system 20, where the system documentation 112 can be easily maintained using any of a number of available web authoring tools. Documents can be composed of a series of HTML (Hyper Text Markup Language), which provide operational instructions to various software tools and the information needed to form software representatives.

The license certificate 102, the software representative pool 104, and the software component library 108 may also be stored locally within the workstation 24, for example, on a hard drive 114 within the workstation. It is. Software representative authoring tool 106, system simulator 110, document 112, and representative component
Library 108 can also be stored on server 48, which is part of system 20.

[0010] The software representative component library 108 is a set of object-oriented classes (preferably written in Java) that are used to support software-representative building. Library 108 includes trader objects, instant delivery objects, contract objects,
And an abstract base class for notification objects, an interface to booth objects, and support classes for money, dates, asset indicators and other commonly used objects. Individual component classes can be loaded by billing the system.

FIG. 5 illustrates some of the reusable components provided to facilitate the formation of software representatives. These reusable components include an abstract trader object class 116, an abstract contract object class 118, an asset class 120, a money class 122, an abstract notification filter class 124, an abstract contract list class 126, and an abstract immediate transfer. Includes object class 128. These classes provide general and basic functionality to various object types. Usually, various objects are
Expanded by inheritance and customization (individualization) in response to specific trader strategies. The essential classes are abstract trader objects
Class 116, and abstract contract class 118 or abstract notification filter class 124. Another class is additional, non-essential tools or guideline templates to reduce formation time. Also required in the software representative component library 108 is a booth interface specification, from which the trader object receives functions from the system 20.

[0012] The software representative authoring tool 106 is also an object-oriented class (Jav) that can be loaded by billing the system 20.
a). Preferably, these software-representative authoring tools are program-forming means with a user-friendly image interface to assist in the creation of new software-representatives.

The market simulator 110 is a system 2
This is an operating program in the browser 100 loaded from 0 (preferably a Java applet). Simulator 110 allows a user to test software representatives under controlled and repeatable conditions where user assets are not at risk. Simulator 110
By providing the same booth API (application program interface) as the system 20,
A software representative that runs satisfactorily on the simulator 100 will still run on the system. Simulator 110 utilizes independent execution threads available in Java so that many software representatives can run simultaneously. Both system 20 and simulator 110 are capable of keeping a log of trader object messages for debugging and auditing purposes.

The collective software representative of the software representative pool 104 is:
To be used, tested in simulation, or extend new software representatives,
Available on system 20. FIG. 6 shows, by way of example,
It shows the internal components of the trader object 26 '. FIG. 6 is an example of a trader / buyer trader object because the sell strategy is to place a contract to sell an asset on the market and wait for the buyer to buy.
If the asset is not bought, trader object 2
6 'decreases the target price over time until the minimum price is reached. In this process, the buyer buys until enough assets are found below the target price.
It is just a passive thing to keep shopping. The target price is adjusted downward by the selling method and adjusted upward by the buying method to a target limit value at a ratio determined according to the aggressiveness of the target (the degree of enthusiasm for achieving the target).

As shown in FIG.
Is the trader object 26 sent to this system
Multiple booth processes, one for each one
0 is provided. The system 20 also includes a plurality of information posting processes, one-to-one corresponding to each individual asset traded in the system. The booth process 30 and the information posting process 32 are connected by a high-speed transmission / reception line 34. FIG.
The system 20 is constructed at two geographically separated locations, with mirrored or duplicated sites, to preserve the integrity of the system in the event of a failure at one site, as shown in FIG. It is desirable.

As shown in FIG. 7, booth process 30
Can be physically implemented using one or more booth processors 36, which can be any suitable general purpose processor, such as a DEC ALPHA ™ processor. Similarly, the information posting process 32 may be physically implemented using one or more information posting processors 38, which may be any suitable general purpose processor such as, for example, a DEC ALPHA ™ processor. The line 34 can be physically implemented using a local area network (LAN) 40 between the booth processor 34 and the information posting processor 36. LAN4
0 is preferably connected to the support network 22 via a router and a firewall. The router includes a booth assignment processor for finding free booths for new trader objects as they enter the system. The router also ensures security and sends an exception message to the immediate delivery object if at least one booth processor fails. Booths that accept trader objects can be distributed across multiple booth processors, across dual or duplicate sites. Information postings can also be spread across multiple sites, but a representation or representation for each traded asset must be formed at each site. If one booth processor fails, the trader object can be deactivated and the link between the immediate transfer object and the trader object is lost, or the trader object is disabled at a predetermined time. In response to a check-in or selection failure, the participant system can re-introduce. However, if the information posting processor fails, the current status and subscription list must not be synchronized. This can be accomplished by having duplicate information bulletins operating in parallel at mutually different sites. Since the trader object associated with an information bulletin may be stuck in many processors, the notification method is possible through a multi-way transmission message over the network. The copy arrives at the relevant booth process and at the same time at the duplicate information posting process. If no failure occurs, the selection can be indicated to the local information posting processor.

[0017] Also, since the multiple trading objects execute the matching algorithm in parallel in the active booth process, the distribution of contract objects by multi-directional transmission allows a high degree of scalability (scalability) in the system. ) Becomes possible. In general, since multi-way transmission messages between sites arrive later than intra-site messages, the Booth process can impose matching delays to reduce unfairness.

The system 20 also includes a clearing and accounting processor 44 on the LAN 40. All significant events, including contract registration, selection, execution, and suspension, are recorded over time by the clearing and accounting processor 302. The internal audit history requires a record of the encrypted content of the trader object to help resolve potential disputes and find logical flaws in the trader object's system. . System fees and clearing are performed by these processors. The clearing processor, like the information posting processor, can be duplicated across multiple sites.

As shown in FIG. 3, a trader uses a workstation 24 to form a software representative comprising a trader object 26 and an instant communication object 28, and a system 20 through a network 22. Send the trader object to. The trader object is transmitted to the booth and a predetermined target by the instant communication object 28. For example, as shown in FIG. 6, the goals are price range, quantity range,
Aggressiveness, buy / sell distinction, and assets to be traded. The sample trader object becomes both a buyer and a seller in one trader object, and changes its behavior based on a buy or sell goal. The trader object 26 is the contract object 5
It is programmed to write 0. The contract object 50 is derived from an existing contract class or a class derived from the contract class, and represents a right to buy or sell a specific asset. Contract object 50 may include a start time, an end time, a selected time interval, a price, a quantity, and an asset indicator. Also, the contract object 50
May include other information required for the trader object for the trader's unique purpose, for example, if the asset being traded is an article, may add rating, delivery mode or location information.

The contract object 50 is shown in FIGS.
1, the contract registration method 200 and the registration completion handling 20
2. Contract expiration handling method 204, contract selection method 20
6. Methods may be performed that include a contract cancellation method 208, a contract execution method 210, a contract execution method 212, a contract cancellation method 214, and a contract cancellation method 216.
Trader object 26 also forms notification filter object 52. These notification filter objects 52 assist the trader object 26 in collecting information about the transaction of the asset involved. At least some of the trader objects include a notification registration method 210, a contract notification registration handling 22 shown in FIG.
2. Notification object methods including contract formation request handling method 224, contract copy request handling method 226, notification cancellation method 228, and notification cancellation handling method 230 can be invoked.

The trader object 26 manages several lists for handling contract objects 50, as best shown in FIG. On the side applying for a transaction (shown on the left side of FIG. 6), the trader object 2
After 6 'forms the contract object 50, the contract object places a copy of the contract object in the unregistered contract list 54. After the contract is registered with the appropriate information posting process 32, the registering information post invokes the contract's registration completion procedure, which causes the contract to be placed and the contract itself to be placed in the registered contract list 56. . If another trading object selects and contracts a contract object, as described below, the contract handling of the drafting (or original) contract is invoked, and the contract handling contracts and contracts the contract itself. In the contracted contract list 66. A list management object can be provided on the system 20, which can measure and record the quantity and average price of contracts in the system, and facilitate determining when a trader object has achieved its goals. The contract object is the information bulletin inspection method 400 (FIGS. 16 and 17)
Which calls the contract expiration handling of the contract object to re-adjust the target price and re-register the contract at a lower price in step 400a. The value and speed of the reduction is determined by the target aggressiveness.
With more complex trading objects, it is also possible to apply for several contracts at different prices in order to sell the whole quantity at a higher average price. It is also possible to cancel the contract while observing the purchase contract in order to make a more advantageous or quicker transaction.

On the side receiving the offer to trade (shown on the right side of FIG. 6), when the trader object 26 'receives a copy of the contract object 52 according to the notification filter object 54, the trader object:
Copy of contract object filtered contract list 6
Fill in 8. If the trader object 26 decides to select the contract object 50, the trader object calls its contract selection method (described below) and moves a copy of the contract object to the unselected contract list 60. If the trader object successfully selects the contract object 50, the trader object is notified and moves the contract to the selected contracts list 62. If the trader object decides to contract contract object 50, the trader object calls its contract contract method (described below) and moves a copy of the contract object to uncontracted contract list 64. If the contract execution is successful, the trader object transfers a copy of the contract to the contracted contract list 66, splitting into buyers or sellers.

Each booth process 30 includes a booth interface 68 (FIG. 3) for interacting with each one of the corresponding trader objects. Each booth process also includes a statistics store 70 (FIG. 3) to maintain system statistics. Booth process 3
0 may invoke a number of the methods shown in FIGS. 14 and 15 to facilitate the functioning of each one-to-one corresponding trader object 26. These functions include a contract registration method 300, a contract cancellation method 302, a contract selection method 304, a selected contract cancellation method 306, a contract execution method 30
8, information bulletin information request method 310, message recording method 312, notification registration method 314, restriction setting method 316, notification cancellation method 318, booth information acquisition method 320, and exit handling method 322. Booth process 30
Performs the methods described above to facilitate the interaction of each one-to-one corresponding trader object with the appropriate information posting process.

Each information posting process 32 is handled by a list 72 of registered contract objects 50 registered by various trader objects, a list 76 of selected contracts registered by various trader objects, and an information posting. It maintains a list 78 of notification selection objects that are registered by various trader objects to obtain information about the assets that are in place. Each information posting process calls the multiple methods shown in FIG. 16 and FIG.
It includes an information bulletin manager object 80 (FIG. 1). These methods include an information bulletin inspection method 400, an information bulletin arrangement method 402, a contract registration method 404, a contract or notification cancellation method 406, a contract selection method 408, a contract cancellation method 410, a contract execution method 412, a notification registration method 414, and This is an information bulletin information request method 416.

When the trader object 26 forms the contract object 50, the trader object calls the contract object contract registration method 200 (FIGS. 10 and 11). In step 200a, the contract registration method of the contract object is the booth process contract registration method 30.
0 (FIGS. 14 and 15). The booth process contract registration method finds the appropriate information posting process 32 in step 300a, invokes the contract registration method 404, and enters a copy of this contract into the unregistered list 54 of trader objects in step 300b. In step 404a, the contract registration method of the information posting process is as follows. The contract object is entered into the registered contract list 74, the registered filter object list 78 is inspected, and a copy of the contract object is copied to each matching filter object and the drafting side. Sent to the transacting object, this drafting transacting object transfers a copy of the contract from the unregistered contract registration list 54 on the registered contract list 56. Furthermore, the contract object registration completion handling method 202 is called by the booth object after calling the contract registration method of the information bulletin.

Since a plurality of copies of the contract object are transmitted to a plurality of involved trader objects 26,
The contract formation request handling method 224 of the notification object (FIG. 1)
2) is called to allow the receiving trader object to make a copy of the contract in the trader object's environment. The accepting trader object 26 may not use the same contract type and treatment as the drafting contract. In fact, the drafting contract object and the notification copy are derived differently and encompass functionally disparate ones, even though they derive from the same abstract base class provided by the system 20. There are several attributes or data items belonging to the base class and resident. Those attributes are copied to the new contract when the receiving booth process invokes the contract copy request handling method 226 (FIG. 12) of the notification object. The method can also test whether the copied contract object has other attributes available that are customary in the market of the traded asset, and can also copy them. This feature can be used for a number of purposes, such as to communicate information between cooperating trading objects, or to communicate additional trading conditions tailored to specific markets that are invisible to the system. As an example,
There may be special clearing procedures and delivery terms required by convention or by third party information posting manager objects. This feature gives system 20 the flexibility to adapt to many different market requirements.

Once the contract object has been converted to the contract form of the receiving trader object, its registration completion handling method 202 (FIGS. 10 and 11) is called. The registration completion handling performs the logic of the receiving trading object, since the copy will be written in its own type during trading and will have its own way. In other words, the registration completion handling of the drafting contract can be completely different from the registration completion handling of the receiving copy. It is desirable to do so since these registration completions handle different trader objects with different strategies. Any event that occurs in the contract object registered in the information posting process is transmitted from the information posting to the receiving copy by calling the execution, cancellation, selection, and expiration of the contract copy handling method by the booth. . This allows the contract copy of the receiving trader object to behave according to the rules of the receiving trader object when the event occurs. Further filtering or selection of contracts is performed by the receiving trader object. As market conditions change due to additional parameters added by custom or required by third party information posting managers or since registration of the notice,
This may be necessary.

The notification filter object 52 is simpler than the contract object because it is used only by the drafting trader object 26 and the information posting manager object 80 of the information posting process that handles a particular asset. The notification object 52 provided by the system 20 as part of the component library 108 (FIG. 2), like the contract object, is an abstract base class. To enable a class (a class is a template for one or more objects), the notification object is extended through the inheritance of the object to include features and treatments specific to the original class. Must. The notification object is a notification object notification registration method 220 (FIG. 12).
Call. In step 220a, the notification registration method 220 for the notification object calls the notification registration method 314 (FIGS. 14 and 15) for the booth process. Step 3
At 14a, the booth object notification registration method finds the appropriate information posting process 32 and invokes the information posting process notification registration method 414 (FIGS. 16 and 17). In step 414a, the method for registering the notification of the information posting process is to fill in the notification object in the notification list 78 of the information posting process, and to create a series of contract notifications for the new registered filter in step 414b. Examine all 74 contract objects. As a result, a trader object entered into the system with a delay can be made known to the market equally as compared to a trader object that has been waiting for a relatively long time, and can be started immediately without delay when starting. Will be possible. When the notification object 52 is formed, whether the product involved (which identifies the information posting process), the price range involved, the quantity range involved, is notified as a sell contract or a buy contract , And an allowed expiration time limit are attached to the notification object 52.

When a registered object is selected as the receiving trading partner object, the registered object is moved from the registered contract list 74 (FIG. 3) to the selected contract list 76 (FIG. 3). In step 506, the background process 500 (FIG. 13) repeatedly calls the information bulletin inspection method 400 (FIGS. 16 and 17) of each information bulletin process. The information bulletin inspection process 400 of the information bulletin process examines the registered bulletin list 74 of the information bulletin process at step 400a and checks the contracts of each expired contract object for both the drafting contract object and all copies thereof. Expired handling method 204 (FIG. 1)
0 and FIG. 11). In step 204a, the contract expiration handling of the contract object examines the traded object's contracted contract list 66 to determine whether the quantity has reached the target value. If the target value has been reached, the contract object is removed from the registered contract list 56 in step 204b. If the target value has not been reached, step 204
At c, the strategy is changed, for example, the target price is adjusted. At step 204d, the updated contract object is registered. Also, the information bulletin inspection method 400 of the information bulletin process examines the selected contract list 76 (FIG. 3) for contract objects that convey the selected expiration time interval, returns them to the registered contract list 74, and Is notified by calling the contract expiration handling method 204 (FIGS. 10 and 11).

If the in-trade object 26 decides to release the contract object 50, the in-trade object will return to the contract object's contract release method 214.
(FIGS. 10 and 11). In step 214a, the contract cancellation method 214 of the contract object is the contract cancellation method 302 of the booth process (FIG. 14).
And FIG. 15). The booth process termination method 302 finds the appropriate information posting process 32 in step 302a, and the process termination method 406.
Call. The contract cancellation method 406 of the information posting process removes the contract object from the registered contract list 74 in step 406a.

Similarly, if the trader object decides to cancel the notification object 52, the trader object uses the notification object notification cancellation method 22.
8 (FIG. 12) can be called. In step 228a, the notification object notification canceling method 228 (step 228a) cancels the booth process notification 318 (FIGS. 14 and 1).
Call 5). Booth Process Notification Cancellation Method 318
Finds an appropriate information posting process 32 in step 318a and cancels the notification 406 of the information posting process.
Call. The notification release method 406 of the information posting process removes the notification object from the notification list 78 in step 406a.

If the trader object 26 wants to cancel the selected contract before it expires, the trading object can invoke the contract object contract cancellation method 208 (FIGS. 10 and 11). The contract object termination method 208 calls the booth process selected termination method 306 in step 208a. The Booth Process Selected Contract Termination Method 306 finds the appropriate information posting process 32 in step 306a and invokes the information posting process subscription termination method 410.
Step 41 is the contract cancellation method 410 of the information posting process.
At 0a, the contract is removed from the selected contract list 76 and the contract is re-notified.

In operation, the system 20 simply facilitates the action of a trader object as submitted by the user. This is shown in FIG. 4, where the first trader object 26 in the booth process 30A programmed to sell asset C by the user.
A forms a contract object 50A for the sale of asset C, specifying quantities, prices, and other transaction parameters. Next, the trader object 26A
Registers the contract object by calling the contract object contract registration method 200 (FIGS. 10 and 11). The method includes a step 200a, which is a call to the booth contract registration method 300, and a step 200b of entering the contract object on the unregistered contract list 54 of trading objects (FIG. 6). In response to this, the booth 30A establishes a contract registration method 30 for the booth 30A.
Call 0. The method includes a step 300a of finding an appropriate information posting process 32 (in this case, information posting process 32c) for a particular asset and invoking a contract registration method 404 of the information posting process. Further in response, the appropriate information posting process 34C uses the information posting process contract registration method 404 (FIGS. 16 and 1).
Call 7). This method includes the contract object 50A
Step 404a of entering the contract object 50A in the registered contract list 74 (FIGS. 3 and 4), and all the notification filters and information in the notification list 78 (FIGS. 3 and 4).
A step 404b of inspecting the object and sending a copy of the contract object to each matching notification filter 52 is included. Upon completion of the notification, the trader object 26A responds to the appropriate information bulletin notice by the registration completion handling method 202 called by the booth from the information bulletin, and the contract object registration completion handling method 202 (FIG.
0 and FIG. 11), and invokes the contract object registration completion handling method 202 (FIGS. 10 and 11). The method 202 includes a step 202a of moving a contract object from an unregistered contract list 54 of trading objects (FIG. 6) to a registered contract list 56 (FIG. 6).

If the trader object 26A wants to invalidate the contract object 50A, the trader object calls the contract cancellation method 214 (FIGS. 10 and 11). The method 214 also includes a step 214a that invokes the Booth Process Termination Method 302. In response, booth process 30A invokes its contract cancellation method 302 (FIGS. 14 and 15). The method includes finding the appropriate information posting process 32C and invoking the information posting process termination method 406 (step 3).
02a. Further in response, the information posting process 32C invokes a contract cancellation or notification method 406. In this method, as described above, the contract object 5
OA is called from the registered contract list 74 of the information posting process, and a step 406a for calling the cancellation handling is included.

On the other hand, another trader object 26B in the booth process 30B programmed by the user of the system to purchase the asset C is a quantity for transmitting the interest of the contract object to the trader object 26B. , Price, and other parameters together with the notification filter object 52B.
The trader object 26B invokes the notification filter object notification registration method 220 (FIG. 12). The method 220 includes a booth process notification registration method 31.
4 is included. In response, booth 26B communicates with its notification registration method 314 (FIG. 14).
And FIG. 15), which also includes a step 314a of finding an appropriate information posting process 32C for the particular asset and calling a notification registration method 414 of the information posting process. Further in response, the appropriate information posting process invokes notification registration method 414 (FIGS. 16 and 17). The method includes a notification filter object 44
Step 414a of entering B into the notification list 78 (FIGS. 3 and 4) of the information posting process, inspecting all registered contract lists 74 (FIGS. 3 and 4), and copying a copy of each matching contract object to the trader. Transmitting 414b to the object 26B.

If the trader object 26B wants to remove its notification filter object 52B,
The trader object invokes the unsubscribe method 228 (FIG. 12) of the notification filter object. This method 2
28 includes a step 228a that calls the booth process notification release method 318 (FIGS. 14 and 15). In response, the booth process invokes its unsubscribe method 318. The method includes a step 318a of finding the appropriate information posting process 32C and invoking the information posting process unsubscribe method 406. The method includes a step 406a of removing the notification object 52b from the notification list 78 of the information posting process.

The trader object 26B, according to its notification request filter object 52B,
, And the trader object 26B communicates with the contract filter request handling method 22 of the notification filter object.
4 (FIG. 12). The method 224 includes forming 224a a new copy of the contract object of the appropriate type of notification copy. Next, the receiving-side in-transaction object 26B receives the contract copy request handling method 226.
Calling (FIG. 12), this method 226 copies important contract attributes from the duplicated original to the local notification copy formed during method 224, step 2
26a. Once the contract object is converted to the contract type of the receiving transacting object, the contract object's contract completion handling method 202 (FIGS. 10 and 11) is invoked. Now that the copy is embedded in the object's own type during the receiving transaction and has its own way,
The registration completion processing method performs logic specific to the receiving trading object 26. In other words, the registration completion handling method of the drafting contract object and the receiving copy can be completely different. This is desirable because these contract objects are used for different trading objects with different trading strategies. As described above, any event affecting a contract registered in the information bulletin can be transferred to the accepted copy by calling the handling method. This ensures that the contract copy of the receiving trading partner object, when the event occurs,
It will be able to act according to the rules of the receiving trading partner object.

If the contract object 50A can be accepted by the trader object 26B, the trader object 26B sets the contract selection method 206 (FIG. 10 and FIG. 1).
Call 1). The method 206 is for contract object 5
Step 2 of moving 0A to the unselected contract list 60 (FIG. 6)
06a and step 206b of calling the booth process contract selection method 304. In response, the booth process 26B uses its contract selection method 304 (FIG. 14).
And FIG. 15). The method 304 includes a step 30 of finding an appropriate information posting process and invoking a contract selection method 408 (FIGS. 16 and 17) of the information posting process.
4a. In response, information posting process 3
4C uses the contract selection method 408 (FIGS. 16 and 17).
Call. The method 408 determines whether the contract object is a copy and registered, and if so, places the copy in the selected contract list 76 of the information posting process.
(FIGS. 3 and 4) and a step 408b of invoking the selected handling method 209 of copies of the contract object to hide all other copies of the contract.
The method selects a contract object for an unselected contract list 60.
From the list to the selected contract list 62.

Next, if the trader object 26B decides to contract, the trader object invokes its contract execution method 210 (FIGS. 10 and 11). The method 210 includes a step 210a of moving the contract to the unfilled list 64 (FIG. 6) and a step 210b of invoking the contract filling method 308 (FIGS. 14 and 15) of the booth process. The method 308 finds an appropriate information posting process, and the contract commitment method 412 of the process.
(FIG. 16 and FIG. 17). In response, the information posting process 32C invokes its contract execution method 412 (FIGS. 16 and 17). The method 412 determines whether the contract object has been properly selected by the contracted trader object and, if so, places the contract object in the selected contract list 76.
(FIG. 16 and FIG. 17), a step 412a for determining whether or not the transfer has been performed, a contracted handling method 212 of the drafting contract and a step 412b for calling the copy in progress, and information posting statistics 7
Step 412c of updating 0 is included. In response, the drafting contract and the active copy invoke their contract handling method 212 (FIGS. 10 and 11). The method 212 includes the step 21 of moving the contract to the filled list 66.
2a.

The system provides fairness to trader objects operating within the system in two ways. That is, (1) to allow the same processor time for all trader objects, and (2) to randomize the selection process. Equal allocation of processing time can be easily achieved using the time division processor schedule found in many operating systems. The randomization of the selection process is important so that no trader object can consistently win the selection competition compared to other objects. It is not practical to notify all registered trading objects on the list of registered trading objects at the same time, but when a notification is sent to the listed registered objects, there will be a consistent transaction. Must not arrive earlier than the others.

An example of the logical flow of a software representative formed on a workstation used in the system 20 is shown in FIGS. As shown in FIG. 8, the logic of the object for immediate communication 28 can follow the following steps. The process begins at step 600. In step 602, the instant delivery object indicates whether the user wants to buy or sell, or the indicator, quantity, starting price, price limit,
And ask for a time limit. In step 604, the instant delivery object converts the trader object to system2.
Send to 0. In step 606, the instant communication object 28 calls the method of operating the trader object, and transmits the user's goal as a parameter.
At step 608, the trader object is considered to operate completely independently, but the immediate communication object can remain active to detect exceptions not handled by the trader object. By operating independently, the user's object is not adversely affected by any inconsistencies in accessing the network 22.

As shown in FIG. 9, the logic of the trader object can follow a number of steps. In step 700, the object for immediate transmission 28 is
How to activate the trader object (step 60 in FIG. 8)
Call 6). In step 702, the trader object 26 determines whether the goal is to buy or sell. If the goal is not a sale, the logic then proceeds to step 704. If the goal is to sell, the logic then proceeds to step 706. In step 706, the trader object sets the target price to the upper limit. In step 708, the trader object
Divide the quantity into salable sizes. At step 710, the trader object forms a short-term contract object with the appropriate price and quantity parameters. In step 712, the trader object registers the formed contract object. At step 714, the trader object 26 continuously monitors whether the filled list 66 includes a quantity within the quantity target. If so, the logic proceeds to 716 where the trader object returns the result to the immediate object 28 and exits. Of course, this is just one example of a possible logic of a trader object for passive sale.

If the goal of step 702 is buy, the logic proceeds from step 704 to the next. Step 7
At 04, the trader object sets the target price to the lower limit. In step 718, the trader object forms a notification filter object with the restrictions that match the goals. At step 720, the trader object registers a notification filter object. In step 722, the trader object determines whether the contracts in the notified list have at least the target minimum quantity. If not, the logic repeats until a minimum number of contract objects are available. If the contract satisfies the minimum quantity target, then at step 724, the trader object determines, for a certain quantity within the quantity limit,
Select the contract with the lowest price. Step 726
In, the trader object transfers the contract to an unselected contract list 60. In step 728, the trader object waits until all selections of the contract are successful. At step 730, the trader object determines whether the average price is less than or equal to the target maximum. If not, the trader object then returns to step 722. If the average price is less than or equal to the target value, the trader object moves to step 732, moves the contract to the unexecuted list 64, and proceeds to step 7
At 34, contracts in the selected list are filled. In step 736, the trader object waits until all contracts have been filled. In step 738,
The trader object reports the result to the user and exits.

At system initialization, the system activates the background method 500 (FIG. 13). Step 5
At 02, the system forms an information posting process 32 for each type of asset traded on the system.
In step 504, the system 20 forms the booth process 30 for as many trader objects as are allowed on the system and operate simultaneously. Step 506
In, the system 20 continuously and repeatedly calls the information bulletin inspection method of each information bulletin process 32.

When the trader object 26 is delivered to the system 20, the system
Perform Step 8. At step 510 of method 508,
The system accepts and authenticates (and decrypts, etc.) the trader object 26. In step 512, the system creates an instance of the particular trader object 26. In step 514, the system calls the method of operation of the trader object and transmits the parameters received from the immediate transfer object 2.

The system allows information bulletins to be managed individually. In the case of a managed information bulletin, the system 20 implements the information bulletin loading method 516. In step 518, the system calls the specific information posting manager object 80. At step 520,
The system 20 calls the operation method of the information bulletin manager object and transmits the parameters received from the object for immediate transmission.

Many modifications of the present invention will be apparent to those skilled in the art. It is therefore intended that the appended claims cover all such modifications as fall within the true spirit and scope of the invention.

[Brief description of the drawings]

FIG. 1 is a schematic diagram of a computerized asset trading system according to the principles of the present invention.

FIG. 2 is a schematic diagram of a user's workstation used in the system.

FIG. 3 is a schematic diagram of a software representative environment used in the system.

FIG. 4 is a schematic diagram of the interaction between software representatives.

FIG. 5 is a schematic diagram of a reusable software representative component.

FIG. 6 is a schematic diagram of contract copy handling by a drafting side (left side) and a receiving side (right side) transaction object.

FIG. 7 is a schematic diagram of the physical equipment of the system.

FIG. 8 is a flow chart showing an example of a logical flow of an object for immediate transmission in the system of the present invention.

FIG. 9 is a flow chart illustrating an example of the logical flow of a trader object within the system of the present invention.

FIG. 10 is a diagram of several contract object methods that can be performed by a contract object formed by a trading object.

FIG. 11 is a diagram of several contract object methods that can be performed by a contract object formed by a trading object.

FIG. 12 is a diagram of several notification filter object methods that can be implemented by a notification filter object formed by a trading object.

FIG. 13 is a schematic diagram of a logical flow of the system.

FIG. 14 is a diagram of several booth object methods that can be performed by the booth object.

FIG. 15 is a diagram of several booth object methods that can be performed by the booth object.

FIG. 16 is a diagram of some information posting object methods that can be implemented by the booth object.

FIG. 17 is a diagram of some information posting object methods that can be implemented by the booth object.

Claims (12)

[Claims] 1. An asset trading method in an asset trading system comprising a virtual market and a plurality of trader client user workstations connected by a network and capable of trading without external mediation. Forming a trader object associated with an asset to be traded and transmitting from one of the workstations to the virtual marketplace to form a received trader object, forming an object for immediate communication, An object is stored on one of the workstations and is capable of interacting with the accepted trader object;
The trading system is independent of any rules or parameters associated with the traded asset, wherein the accepted trader object forms a contract object, and the contract object comprises trade parameters associated with the traded asset. Contracting the contract object in response to a contract object contract request from the accepted trader object, thereby completing a transaction of the asset between a user's workstation and the virtual marketplace. , An asset trading method comprising each step. 2. The asset trading method according to claim 1, wherein said network is the public Internet. 3. The asset trading method according to claim 1, wherein the network is a private network. 4. The step of forming and sending the trader object comprises forming a software representative, the software representative comprising the trader object and the instant delivery object. 2. The software representative of claim 1, wherein the software representative is stored on the trader client user workstation, and the software representative sends the trader object to the virtual market. Asset trading method. 5. The method of claim 1, wherein said step of forming said trader object comprises forming a notification object, said notification object transmitting a contract commitment request to a second contract object. . 6. The asset trading method according to claim 1, wherein the contract object includes an asset identifier, a price identifier, a quantity identifier, and a time identifier. 7. The asset trading method according to claim 6, wherein the contract object changes the value of the price identifier when the time identifier expires. 8. The asset trading method according to claim 1, wherein the trader object notifies the immediate communication object when the contract is executed. 9. The asset transaction method according to claim 5, wherein the notification object notifies the immediate transmission object when the second contract object is filled. 10. The virtual market comprises a plurality of booths and a plurality of information posting processes, and wherein the step of transmitting the trader object to the virtual market comprises the step of transferring the trader object to one of the plurality of booths. 2. The asset trading method according to claim 1, further comprising transmitting the asset to the booth, wherein the booth registers the asset associated with the contract object in one of the plurality of information posting processes. 11. The transaction object associated with the traded asset, wherein a second trader object and the trader object match for the trade parameter associated with the traded asset, and wherein one of the plurality of information posting processes is associated with the traded asset. 11. The asset trading method according to claim 10, wherein the parameter matching is notified to a second immediate communication object associated with the second trader object. 12. The transaction object associated with the traded asset, wherein a second trader object and the trader object match for the trade parameter associated with the traded asset, and wherein one of the plurality of information posting processes is associated with the traded asset. 11. The asset trading method according to claim 10, wherein the matching of the parameters is notified to the object for immediate transmission related to the second trader object.