JP2002049759A - Virtual investment simulation system and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a virtual investment simulation system and its method capable of performing a virtual transaction almost in real time. SOLUTION: The virtual investment simulation system 10 is provided with a Web server 11 for accepting a virtual buying or selling order, a stock price feed server 13 for receiving present stock price information price, a pseudo transaction server 12 for executing a virtual stock dealing, on the basis of order information and the present price information and a DB 15 for storing the transaction result at least. Thus, since the buying or selling order of a stock and the present stock price information are inputted almost in real time and the virtual transaction is successively executed by the pseudo transaction server 12, a user can simulate the stock dealing in almost similar manner to a real stock dealing.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a virtual investment simulation apparatus and a virtual investment simulation method, and more particularly, to a virtual investment simulation apparatus and a virtual investment simulation method capable of performing virtual transactions in almost real time.

[0002]

2. Description of the Related Art With the spread of the Internet in recent years, it has become possible to conduct stock trading on the Internet, and many securities companies operate trading sites on the Internet. But,
For individuals who are not accustomed to stock trading, such as individual investors, there is a resistance to conducting actual stock trading immediately. Therefore, a stock trading simulation site has been proposed in which virtual stock trading is performed by using predetermined fictitious funds with reference to stock prices in an actual market.

[0003]

In stock trading in an actual market, the stock price fluctuates in one day, and the result may vary greatly depending on the timing of placing a buy order and a sell order. However, in the conventional virtual stock trading site as described above, buy orders and sell orders are processed with reference to, for example, the closing price of the stock market on that day. No matter what time it comes out, the result is the same, and there is a problem that it is impossible to simulate the actual stock trading faithfully. An object of the present invention is to solve the problems of the prior art as described above,
It is an object of the present invention to provide a virtual investment simulation device and a virtual investment simulation method capable of performing virtual trading in almost real time based on an actually fluctuating stock price.

[0004]

A virtual investment simulation apparatus according to the present invention comprises: an order receiving means for receiving a virtual buy order or a sell order; a current value information receiving means for receiving current price information; It is characterized by comprising virtual stock trading execution means for executing virtual stock trading based on current value information, and storage means for storing at least a trading result.

According to the present invention, a buy order or a sell order of stock and current value information of stock are input almost in real time,
Since the virtual trades are sequentially executed by the virtual trade execution means, the user can simulate a stock trade based on a fluctuating stock price substantially similar to an actual stock trade.

[0006]

Embodiments of the present invention will be described below in detail. First, an outline of a virtual investment game system using the simulation device of the present invention will be described. A user of the virtual investment game system first performs user registration and obtains a user ID. At the start of the virtual investment game, for example, 100 million yen is held as fictitious funds, and many users start stock trading at the same time and compete for the performance. One game is held for about three months, for example.
When one game is over, the next game starts a few days later. Note that participation from the middle may be permitted.

For a game participant, a prize (prize money) is given to, for example, a top prize winner of the final operation result. In addition, a prize (prize money) is given to a winner who is randomly selected from correct answerers of the quiz given once a week regardless of the performance. However, the prize (prize money) is made different according to the ranking of the operational results for each week.

[0008] A game participant inputs an order for buying and selling stock via the Web, and the server of the system of the present invention accepts the order for buying and selling. After a certain period of time has passed since the server accepted the trade order, the server sequentially matches the contents of the accepted order with stock price data transmitted from the exchange, and performs virtual trading processing.

[0009] From the exchange, stock price present value information delayed for a certain time is intermittently transmitted to the system. The oldest one of the current value information for which no execution decision has been made is stored in the current value history DB
And an order to be executed at the current value.
At this time, only the order time older than the current time is acquired. As a result, even if the current value information is received with an arbitrary delay, matching with the order can be obtained. And in the case of a "sell order", if the number of shares held is sufficient,
In the case of a "buy order", check whether the cash held is sufficient.

Next, if the order type is “market”,
Treats the stock as having been traded based on the stock price data that was first attached after receiving the order. Also, if the order type is “limit”, if the limit of the buy (sell) order is higher (lower) than the stock price data that was initially attached after accepting the order, the buy / sell will be performed at the limit price. Treat it as done.

[0011] The server subtracts (in addition to) the amount of the buy (sell) order from the tentatively provided fund for the completed order, and calculates the participant's asset balance. On this occasion,
Transaction fees and securities transaction taxes are also deducted.

[0012] The number of shares held and cash related to all the selected orders are updated, and the transaction history is saved. In the order history, the transaction (contract) time is entered, and an executed flag is set to the current value processed this time.

Each time the server requests from the participant,
Calculate the participant's asset balance and display it on the screen. When calculating the asset balance, the latest data of the stock price data transmitted from the exchange is used. Once a day, the ranking is determined and displayed based on the asset balance of all participants. In the ranking display, all the participants are displayed in a certain number of persons, such as the top rank, the ranking around the participants, and, for example, the 1st to 100th ranks and the 101st to 200th ranks. The displayed items are, for example, the last ranking of the previous game, the final asset balance, the ranking as of the previous week, the asset balance, and the like.

Next, an embodiment will be described. FIG.
1 is a block diagram illustrating a configuration example of an entire system including a virtual investment simulation device (virtual investment game system) 10 of the present invention. In the virtual investment game system 10, a Web (WWW: World Wide Web) server 11, a pseudo transaction server 12, a stock price feed server 13, and a DB server 14 including a DB (database) 15 have a well-known LAN.
16 and the Web server 11
Is connected to the Internet 20 by a router (not shown), and the stock price feed server 13 is connected to a stock price information server 40. In addition, a plurality of maintenance and management servers and terminals (not shown) may be connected to the LAN 16.

The DB 15 stores various information described later. Each of the servers 11 to 14 can be realized by mounting a well-known commercially available OS on a well-known commercially available server device, and creating and implementing a program that executes a commercially available or later-described process. The client-side user terminals 30 and 31 may be, for example, well-known commercially available PCs (personal computers) that include a well-known Web browser and can access the Internet 20.

FIG. 2 is an explanatory diagram showing the exchange of information between the servers 11 to 15 in the virtual investment game system 10 of the present invention. The Web server 11 connects to the user via the Internet 20 and, after authenticating the user, accepts the order information from the user and transfers the information to the DB server 14 after adding the acceptance time. The DB server 14 stores the order information in the order history DB in the DB 15.

The stock price feed server 13 always receives stock price information for which a trade has been established from a stock price information server 40 which provides a stock price information service operated by a known service company.
Transfer to the DB server 14. Transaction completion time information is added to the stock price information, and is received after a predetermined delay time (for example, about 20 minutes) from the conclusion. Stock price information is D
It is stored in the current value history DB in B15.

As will be described in detail later, the pseudo transaction server 12 retrieves one of the oldest stock price information from the current value history DB, and retrieves and retrieves order information to be traded for the stock price information from the order history DB. Executing simulated transactions.
Then, the transaction result is stored / updated in the contract history DB, the held securities DB, and the held cash DB in the DB 15. The pseudo transaction server 12 repeatedly executes the above processing asynchronously with other servers.

FIG. 3 is a flowchart showing the contents of the user access process according to the present invention. This processing is
It is executed in the server b. When the user accesses the Web server 11, it is determined in S10 whether or not the user has already been registered.
Then, the process proceeds to step S11 to execute the user registration process. In S11, when predetermined information such as an address and name is registered, a user ID and a password are issued.

In S11, it is checked through which customer site the user has accessed. This check is, for example, the customer of this system (sponsor)
For example, it can be determined by adding a parameter unique to the customer to the URL of the banner advertisement of the present system on the website of the securities company A. Then, the customer of the system, for example, the web site of A securities company
If you access our system from the site,
Customer information "A securities" is also registered.

In S12, the registered user is authenticated based on the input ID and password, and if OK, the process proceeds to S13. In S13, the customer information of the user is determined. If the user is a customer user, the process proceeds to S14; otherwise, the process proceeds to S15. In S14, the customer-specific screen is displayed, and the advertisement of the customer is displayed. In S15, a general-purpose screen for general users is displayed, and, for example, an advertisement of a securities company as a customer of the system or another advertisement is rotated and displayed.

In S16, it is determined whether or not the user has input a sell or buy order. If the determination result is affirmative, the process proceeds to S17. FIG. 7 is an explanatory diagram showing an example of an input screen for a sell order to be selected from the holdings. FIG.
FIG. 8 is an explanatory diagram showing an example of an input screen for a sell order at a limit price. FIG. 9 is an explanatory diagram showing an example of an order condition confirmation screen of a sell order. In the case of a sell order, the execute button on the sell order screen of FIG. 9 is pressed, and the HTTP request is sent to the Web server 1
After 1 is accepted, check if it is a correct order.

FIG. 11 is an explanatory diagram showing an example of a brand search screen in a buy order. FIG. 12 is an explanatory diagram showing an example of a brand search result display screen in a buy order. FIG.
It is explanatory drawing which shows the example of an order condition input screen in a buy order. FIG. 14 is an explanatory diagram showing an example of an order condition confirmation screen for a buy order. In the case of a buy order, the execution button on the buy order screen of FIG. 14 is pressed, and the HTTP request is sent to We.
(b) After the server 11 accepts the order, it checks whether the order is correct.

In S17, the input order information is transferred to the DB server 14, and the DB server 14 adds the order information to the order history DB of the DB 15. Thereafter, the Web server 11 returns an order notification screen as shown in FIG. 10 or FIG. 15 to the client as an HTTP response. FIG. 10 is an explanatory view showing an example of a notice screen for accepting a sell order. FIG. 15 is an explanatory diagram illustrating an example of an order acceptance notification screen for a buy order.

FIG. 6 is an explanatory diagram showing the contents stored in the DB 15 in the present invention. As shown, the DB 15 includes an order history DB, a current value history DB, a held securities DB, and a held cash D.
B, consisting of a contract history DB. The following contents 1 to 10 are stored in each item of the order history DB. [1] Order number ...
serial number. [2] Order time: The time when the order was received.
[3] User ID: Uniquely assigned to each user
ID. [4] Sell or Buy: Indicates a buy order or a sell order. “B” for buy, “S” for sell. [5] Brand code: 4-digit security code. [6] Number of shares: The number of shares ordered.
[7] Limit order: In the case of a limit order, the limit is entered. NULL for market orders (nothing set).

[8] Execution time: The order whose execution has been completed is
Execution time enters. In the implementation, the number of seconds since 00:00 on January 1, 1970 GMT is recorded. If it has not been executed yet, it is NULL (nothing has been set). [9] Cancellation time: When an order is canceled, the cancellation acceptance time is entered. GMT1970 on implementation
The number of seconds since 00:00 on January 1 is recorded. NULL if the order has not been canceled (nothing set). [10] Error code: If the order execution is not performed correctly, an error number is entered here.

Returning to FIG. 3, in S18, it is determined whether or not the user has requested a portfolio. If the determination result is affirmative, the process proceeds to S19. In S19, the DB server 14 is caused to search for information on all stocks and cash owned by the user, the market capitalization is calculated, and the result is displayed to the user in the form of a list. In S20, it is determined whether or not to end the process. If the result is negative, the process returns to S16, but if affirmative, the process ends.

FIG. 4 is a flowchart showing the contents of the stock price information input processing in the present invention. This processing is executed in the stock price feed server 13. In S30, it is determined whether or not stock price information has been received from the stock price information server 40. If the determination result is affirmative, the process proceeds to S31. In S31, the received stock price information is added to the current value history DB of DB15.

Each item of the current value history DB has the following contents 1 to
7 is stored. [1] ID: serial number. [2] Brand code: 4-digit security code. [3] Market: Represents exchanges and listed companies. One of Tl, T2, TF, TM, 01, 02, OF, JQ. [4] Current value: The stock price (unit: yen) of the transaction that actually took place on the exchange. [5] Current value time: Time at which the current value is added.
In the implementation, the number of seconds since 00:00 on January 1, 1970 GMT is recorded. [6] Update time: When this data is added or changed in the DB, the time is recorded. In the implementation, the number of seconds since 00:00 on January 1, 1970 GMT is recorded. [7] Execution time: When pseudo execution is performed using this stock price, the execution time is held. While not being used for execution yet, it is NULL (the state where nothing is set).

FIG. 5 is a flowchart showing the contents of the pseudo transaction processing in the present invention. This process is executed by the pseudo transaction server 12. In S40, the process waits until unprocessed stock price information is input. Specifically, the determination is made based on whether or not the current value history DB includes stock price information whose execution time is NULL. If there is unprocessed stock price information, the process moves to S41, and the stock price information with the oldest current time is acquired from the unprocessed stock price information.

In step S42, one of the order information (of the same brand) corresponding to the acquired stock price information whose order time is equal to or older than the current time of the stock price information is acquired. If the order is a limit,
Further, in the case of sell, only the order information whose stock price is higher than the limit price and in the case of buy, the stock price is lower than the limit price is selected. In S43, it is determined whether or not the acquisition was successful in S42 (corresponding order information was present). If the determination result is negative, there is no corresponding order information, so the process returns to S40. Shifts to S44. If there is no order information to process,
After stopping the processing for a predetermined time (for example, 60 seconds), S40
You may return to.

In S44, it is determined whether the order is a sell or a buy. If the order is a sell, the process proceeds to S45, and if the order is a buy, the process proceeds to S45. In S45, it is determined whether or not the number of shares of the brand owned by the user is equal to or greater than the number of shares in the sell order. If the determination result is negative, S is determined.
Move to 48. In S46, it is determined whether or not the imaginary cash owned by the user is equal to or greater than the price of the purchase order (current value determined at present × number of shares purchased + commission + consumption tax), and the determination result is negative. In this case, the flow shifts to S48. In S48, the order is canceled by setting a cancellation time in the order history DB, and S42 is set.
Return to

In S47, the following processing (1) to
After simultaneously executing (4) as a transaction process, the process returns to S42. (1) Update the number of shares and cash held by the user. The following contents 1 to 4 are stored in each item of the held securities DB. [1] User ID: serial number. [2] Brand code: 4-digit security code. [3] Number of shares held: The number of shares held by the user of the user ID with the stock code. [4] Average purchase unit price: When the number of shares held is 0 and the transaction is completed, the purchase price is entered. In the case of additional purchase: (Number of shares held immediately before additional purchase x average purchase unit price immediately before additional purchase + current number of shares purchased x unit price of one share purchase) / (number of shares held immediately before additional purchase + number of additional purchase shares this time).

Each item of the held cash DB has the following contents 1 to
4 is stored. [1] User ID: serial number.
[2] Currency ID: Indicates a yen (1) or a US dollar (2).
[3] Amount held: the amount held by the user of the user ID in the currency. [4] Average purchase rate. In the case of a sell order, (number of shares sold × current value−commission−consumption tax−tax of capital gain) is added to the held cash information, and the number of shares sold is subtracted from the information on the number of held shares. In the case of a buy order, (the number of shares sold × the current value + the commission + the consumption tax) is subtracted from the held cash information, the number of shares to be purchased is added to the held stock information, and the average purchase unit price is updated.

(2) Record a contract history, which is a pseudo transaction history. The following contents 1 to 12 are stored in each item of the contract history DB. [1] Execution number: Serial number. [2] Order number: Indicates which order in the order history. [3] Order time ...
Copy the order time kept in the order history. [4] Execution time: The time when execution was performed. The current time of the current value used for this execution is copied. [5] User ID ... serial number [6] Sell or buy ... Indicates a buy order or sell order.
"B" for buying and "S" for selling. [7] Brand code ...
4-digit security code. [8] Number of shares: The number of shares in this transaction.
[9] Contract value. [10] Commission: Value calculated based on the commission system. [11] Consumption tax: 5% of commission. [12] Capital gain tax amount: At the time of sale, the withholding tax is calculated and held based on the number of shares sold x the number of shares sold.

(3) Write the execution time, which is the transaction time, in the order information. (4) Set a processed flag in the stock price information. With the above-described configuration and processing, virtual transactions can be performed in almost real time.

Next, an example of an actual simulated transaction will be described. It is assumed that the specific held user and the held cash of the specific user whose user ID is "1146" are only those shown in FIG. In other words, the number of shares held is
It is assumed that there are 800 shares and the cash held is 99,318,425 yen. FIG. 18 is an explanatory diagram showing an example of held securities and held cash data of a specific user.

Here, the user inputs a sell order as shown in FIG. 16 at order time 953517929, and thereafter,
It is assumed that a buy order as shown in FIG. 17 is input at order time 953518458. FIG. 16 is an explanatory diagram illustrating an example of data of a sell order. FIG. 17 is an explanatory diagram showing an example of data of a buy order. These pieces of order information are stored in the order history DB.

On the other hand, it is assumed that the following three transactions are established in the market. [1] Brand code, 11:03 on March 20, 2000
4682, 802 yen [2] 11:15 on March 20, 2000, brand code
8314, 1010 yen [3] 11:20 on March 20, 2000, stock code 4682, 790 yen. As a result, three pieces of current value information as shown in FIG.
It is assumed that the current value is stored in the history DB. FIG. 19 is an explanatory diagram illustrating a data example of current value information. The update time is the time stored in the current value history DB. For example, in the first current value information (upper part in FIG. 19), the difference between the current value time and the update time is 1200 seconds, that is, 20 minutes.

FIG. 20 is an explanatory view (1) showing an example of data at the time of execution of the pseudo transaction. In the process of S41 in FIG.
Of the current value data shown in FIG.
The information of (a) is obtained. However, with regard to this current value data, although the sell order information in FIG. 16 has the same brand, the pseudo transaction process is not performed because the order time is newer than the current time. Then, the execution time is entered in the current value data (b), and the process proceeds to the next current value data. Regarding the acquired current value data (c), there is no order data to be executed, so that the pseudo transaction processing is not performed. Then, the execution time is entered in the current value data (d), and the process proceeds to the next current value data.

FIG. 21 is an explanatory view (2) showing an example of data at the time of execution of the pseudo transaction. Next, the acquired current value data (e) has the same brand as the sell order information (f) of 800 shares in FIG. 16 and is executed because the order time is older than the current time. Since the user owns 800 shares of the same brand, a virtual transaction is established. As a result, contract history information as shown in (g) is generated and stored in the contract history DB. This information includes fees,
The consumption tax and capital gain tax amount are also calculated and entered.

FIG. 22 is an explanatory view (3) showing an example of data at the time of execution of the pseudo transaction. The execution time is entered in the order information (h) in which the virtual transaction has been established, and the held securities data (i)
Is updated to 0 shares, and the amount of the held cash data (k) is added. Next, other order information for the current value information (e) is searched, but there is no target order information, so the execution time is entered and the process is terminated.

Next, a second embodiment will be described. The above-described first embodiment is a method of receiving the latest execution value in real time (semi) in real time, inspecting the virtual order and processing the execution every time the latest execution value is updated. in this way,
Although it is possible to simulate day trading, since the order quantity is not checked, it is possible that a virtual order is filled with a quantity that cannot be actually filled. Also, it is impossible to execute a partial contract according to the transactable quantity.

Further, in order to simulate a virtual transaction in the form of following a transaction actually performed, an order placed in the actual
They ignore things that have not yet been executed (signs) and may judge that a virtual order that should have been executed if it were actually put out was "cannot be executed".

The biggest reason why it has been difficult to achieve high simulation accuracy is that "it is not possible to obtain a real-time order status on an actual exchange". This is because major exchanges do not provide information for secondary use.

In the second embodiment, it is possible to simulate real stock trading without actually participating in actual stock trading as if it were actually participating.
According to the second embodiment, even if the user does not have to obtain the status of the orders collected on the real exchange, the user can order a certain stock trade without any need to actually try the order. As described above, it is possible to know whether the virtual order is executed or not with higher accuracy than the methods known so far, and the simulation accuracy is significantly improved.

<Order Reasoning System> The order status recognizing system 50 of the present invention will be described. <Database schema> A table is created in the database 53 based on the following schema.

CREATE TABLE bis_stock (-issue order status table bis_id SERIAL PRIMARY KEY,-order status identification number symbol INTEGER NOT NULL,-issue identification number update_time INTEGER NOT NULL,-order status update time check_time INTEGER-virtual The time the contract system checked);

CREATE_TABLE bis_quote (-Order status detail table bis_id INTEGER NOT NULL,-Order status identification number type CHAR (1) NOT NULL,-Type ('A' = Bid, 'B' = Bid, ' X '= contract) price INTEGER NOT NULL,-quote for quote, contract for contract volume INTEGER NOT NULL,-quote for current volume, contract for current day PRIMARY KEY (bis_id, type, pri
ce));

The order status inference system 50 repeatedly executes the processing of the flowchart shown on the left side of FIG. In S50, the latest contract information and quote information are received from the exchange via the stock price information vendor. S5
In 1, the order status is inferred based on the trade / quote information of the brand on the day. The order status estimation method is shown below.

1. If the sell (buy) quote / quantity changes, this may indicate whether a new sell (buy) order has been added on the exchange,
Indicates that some of the placed sell (buy) orders have been lost or decreased depending on whether they were filled or canceled. A new order status is added by adding the following changes to the latest order status of the same brand.

Since the sell (buy) quote is the best sell (buy) order, a row of a sell (buy) quote with a lower (higher) value is searched for and deleted. -Search for a row with the same sell (buy) price and update the quantity to the changed quantity.

2. If the last traded value / quantity changes, this indicates that a new trade has been made on the exchange. A search is made for a line with the same value in the latest order status of the same brand (if there is none), the quantity is added, and a new order status is set.

In S52, the inferred order status is inserted into the database. For example, when the order status of a certain brand changes, the brand identification number and time are inserted into the brand order status table, and the order status identification number is issued. The contents of the order status are represented by a set of rows having the same identification number in the order status detail table.
Each line is

(Type, value, quantity)

The following three items are included. “Type” indicates any one of {Bid (A), Bid (B), Contract (X)}. If the "type" is "sell (buy)", the "value" is the bid price at which one or more stock orders (buy orders) existed at that time, and the "quantity" is the sell order (bid price) of the bid price. Shows how many shares have been issued. If "Type" is "Contract",
The “value” is the execution value of one or more shares executed by the time on the day, and the “quantity” represents the number of executions of the execution value by the time on the day.

Example: (Sell, 2880000, 111) (Sell, 2870000, 29) (Buy, 2860000, 119) (Contract, 2870000, 680)

In this example, at the time the order status is deduced, there are 111 sell orders of 2.88 million yen, 29 sell orders of 2.87 million yen, and 119 buy orders of 2.86 million yen of the relevant issue. It is estimated that there were 680 shares of the 2.87 million yen contract today.

<Virtual Order Reception / Inquiry System> The virtual order reception / inquiry system 51 performs the same processing as the user access processing in the Web server of the first embodiment, and stores the virtual order information in the DB 53.

<Virtual Contract System (All Day Pseudo Zaraba System)> The virtual contract system 52 of the second embodiment will be described. In addition, an effect of simulating the execution system based on the zaraba system generally used in actual major exchanges is obtained, and this system is used throughout the day. Therefore, this system is referred to as "all-day pseudo zaraba system". Create a table in the database based on the following schema.

CREATE TABLE bis_order (-virtual order table order_id INTEGER PRIMARY KEY,-order identification number bis_id INTEGER,-order status at the time of order (NULL = unknown, 0 =
None) vol_done INTEGER NOT NULL,-Partial contract quantity until now order_time INTEGER,-Order time user_id INTEGER NOT NULL,-Orderer identification number buy_or_sell CHAR (1) NOT NULL,-Trade identification ('B' = Buy,
S '= Sell) symbol INTEGER NOT NULL,-Symbol ID number volume INTEGER NOT NULL,-Order number price INTEGER,-Limit (NULL = Marketing) exec_time INTEGER,-Execution time (NULL = Unexecuted) cancel_time INTEGER -Cancellation time (NULL = No cancellation));

CREATE TABLE bis_exec (-virtual execution table bis_exec_id SERIAL PRIMARY KEY,-partial execution identification number order_id INTEGER NOT NULL,-order identification number bis_id INTEGER NOT NULL,-identification number of order status at the time of this execution price INTEGER NOT NULL,-Execution value vol INTEGER NOT NULL,-Execution amount exec_time INTEGER NOT NULL-Execution time);

"1 phase" of the virtual contract system 52
Is defined as from the extraction of the oldest one of the unprocessed order statuses from the database to the update of the database as the processed status. The virtual contract system 52 repeats this phase all day. The right side of FIG. 24 is a flowchart showing the processing contents of the virtual contract system.

Each phase consists of pre-processing, any number of sub-phases, and post-processing. In the pre-processing, all the virtual orders with unexecuted contracts among the virtual orders for the brands in the order status used in that phase are extracted from the database (S60), and rearranged according to the priority described later (S61). In each sub-phase, virtual orders are extracted one by one in descending order of priority, matched with the order status, and virtual contract processing is performed. In the post processing, the order status is processed and the database is updated (S62 to S6).
4).

The priority of the virtual order is “Principle of price priority”
It is based on the principle of time priority. However, sell orders take precedence over any buy orders. In the case of sell (buy) orders with different bid prices, those with lower (high) bid prices have higher priority. For sell (buy) orders with the same bid price, the one with the earlier order time has higher priority. If the order time is the same at the same bid price, either of them may be prioritized.

<Process in Each Sub-Phase (S64)> 1. If the order time of the virtual order is later than the update time of the order status, jump to 4. 2. If the order status at the time of ordering the virtual order is unknown, Perform "immediate contract processing" (described later) 3. Perform "Partial contract processing" (described later) 4. End

<Immediate execution processing> 1. The latest order status of the brand is acquired from the database. The virtual order table of the database is updated with the order status as the “order status at the time of order” of the virtual order. If not, update the database with no order status at the time of order, and skip to 4. 2. If the hypothetical order is sell (buy), the quantity of the sell (buy) quote (described as Q (P)) with the same bid price (described as P) in the most recent order situation and Each value of the deal (described as p)
The quantity (described as X (p)) is stored for each. These quantities represent real sell (buy) orders that fill before this virtual order on a time-first principle. 3. Perform "Partial execution" (described later) using this latest order status. 4. Finish

<Partial Contract Processing> 1. If the virtual order is sell (buy), of the virtual contract of the sell (buy) order of the same brand of the member who issued this virtual order today, it is equal to or more than the bid price of the virtual order. (Below) is summed up for each value (described as p) (described as D (p)). 2. Within the order status, the quote (P) or higher (less) for this virtual order
The quantity of the buy (sell) quote of is assumed to be C (p) for each value (p), and the quantity of contracts above (or below) the quote price P is assumed to be Y (p) for each value (p). Calculate N (p) = C (p) + Y (p) -D (p) -X (p) -Q (p) for each value p above (or below) P. N (p) is the number of shares in the real order that matches this virtual order.

3. N (p) is examined in order from the highest (lowest) value. If the value is 0 or more, (partial) contract is made with that value, and the database is updated. The number of contracted shares is the smaller of N (p) and the number of uncontracted shares. The execution time is the larger of the virtual order time and the order status update time. 4. End

<Contract Price Determination Method> The contract price determination method will be described. <In the case of a limit order> * When the limit price is the same as the bid price of the trading partner (actual order), the contract is executed at that price. (Selling price = buying price) * If there is a difference between the limit price and the trading partner's bid price and the reference value falls in the meantime, the contract is executed at the reference value. (Selling price ≤ reference value ≤ buying price)

* When the limit price is different from the bid price of the trading partner and the reference price does not fall between them, ** When the trading partner sells and the bid price is higher than the reference price, the contract is executed at the bid price. (Reference price <Sell price) ** If the trading partner buys and the bid price is lower than the reference price,
Contract at the quote. (Buy price <reference value) * If the limit price is higher than the reference value for selling, the limit price is rounded up to the tick unit and the contract is executed. (Reference price <Sell price) * If the bid price is lower than the reference price when buying, the price is rounded down to the tick size and executed. (Purchase price <Reference value)

<In the case of a market order> * When the trading partner sells and the quote price is below the reference value, the contract is executed at the reference value. * If the trading partner sells and the bid price is higher than the standard price, the contract is executed at the quote price. * If the trading partner buys and the ticker is above the standard, the contract is executed at the standard. * If the trading partner buys and the bid price is lower than the standard price, the contract is executed at that bid price.

Note: In each case, if the contract value is higher than the stop height, the contract is executed at the stop height. If the contract value is lower than the stop low, the contract is executed at the stop low. The “current price for calculation” is used as the reference value. The “current price for calculation” is the last listed quote for domestic listed stocks, and the latest time out of “special quote”, “quote adjustment price” and “current value / price per unit”. If not, "Ex-rights modified theoretical price"
(In the case of a previous match) or "current value for calculation at the end of the previous match" (in the case of a late match).

In the JASDAQ, the priorities are "current day price">"one-side stop price">"value of the average of the sell price and buy price rounded down to the tick size">"reference value of the day".

<Embodiment> As an example of the embodiment, an example in which the present invention is used as a part of the virtual stock trading game disclosed in the first embodiment will be described. In this embodiment, as shown in FIG. 23, the server sends stock price information including the latest current price / quantity, the sell quote / quantity, and the buy quote / quantity from the stock quote information providing vendor while the market is open ( Semi) Real-time reception through a dedicated line. A Web server is used for the front end of this server.
Basically anyone can join if there is an environment that can connect to (WWW). Each end user is given a virtual fund,
Place a virtual order or query the trading status through the page displayed in the browser.

The invention of the second embodiment describes in this embodiment, "how to be executed if a series of trade orders of this user are not virtual but real." Used to simulate each user. Although the motivation of the game participants is multiple, the mainstream is `` I want to practice in the game before risking real assets '', providing more accurate and realistic virtual transactions This possible embodiment works effectively.

<Specific Processing Example> Here, the operation will be described assuming specific values and quantities. Brand 999
9 The order status inferred at 13:00

Brand order status table [(order status identification number, brand identification number, order status update time, check time)] (234, 9999, 96699600, NULL)

Order status details table [(order status identification number, type, value, quantity)] (234, sell, 2880000, 111) (234, sell, 2870000, 29) (234, buy, 2860000,119) (234 , Contract, 2870000,680).

At 13:05, it is assumed that the user 1234 has placed 100 shares of a sell order for this brand with a limit price of 287,000 yen.

Virtual order table [(order identification number, order status at the time of order, partial contract quantity, order time, orderer identification number, trade identification, brand identification number, number of shares ordered, limit price, execution time, cancellation time)] (54321, NULL, 0, 96699900,1234, sale, 9999, 100, 2870000, NULL, NULL)

The stock price information of this stock at 13:10 is as follows: The latest contract price: 2870000 The latest contract volume: 29 Sell bid price: 2880000 Sell bid volume: 111 Bid quote: 2870000 I do.

The order status is deduced as follows and inserted into the database. Brand order status table [(order status identification number, brand identification number, order status update time, check time)] (235, 9999, 96700200, NULL)

Order status detail table [(order status identification number, type, value, quantity)] (235, sell, 2880000, 111) (235, buy, 2870000, 50) (235, buy, 2860000,119) (235 , Contract, 2870000,709)

When the virtual execution system fetches the order status 235 and matches it with the order 54321, the order status at the time of ordering becomes 234 by the immediate execution processing (described above), and the virtual order table [(order identification number, order (54321, 234, 0, 96699900, 1234, sell, order status, partial contract volume, order time, orderer identification number, trade identification, stock identification number, number of shares ordered, limit, execution time, cancellation time) 9999, 100, 2870000, NULL, NULL)

Q (2870000) = 29 X (2870000) = 680 Q (p) = X (p) = 0 (p is any value except 2870000) (meaning of Q (), X (), The calculation method is described above). Then, the partial execution processing (described above) is first performed for the order status 234.

Since the user 1234 has not executed the stock 9999 today, D (p) = 0 (for any value p). For order status 234, C (p) = 0 (p is any value) Y (2870000) = 680 Y (p) = 0 (p is any value except 2870000), so N (2870000) = C ( 2870000) + Y (2870000) -D (2870000) -X (2870000) -Q (2870000) = 0 + 680-0-680-29 = -29 <0 N (p) = 0 (p is any except 2870000 Value), and there is no share to be filled at order status 234.

Subsequently, a partial contract process is executed for the order status 235. This time, C (2870000) = 50 Y (2870000) = 709 C (p) = Y (p) = 0 (p is any value except 2870000), so N (2870000) = C (2870000) + Y (2870000) -D (2870000) -X (2870000) -Q (2870000) = 50 + 709-0-680-29 = 50 N (p) = 0 (p is any value except 2870000) User 1234 will take 50 shares out of the 2.87 million yen purchase order issued to the place and execute it.

In the database, a virtual order table [(order identification number, order status at the time of order, partial contracted quantity, order time, orderer identification number, trade identification, brand identification number, number of shares ordered, limit price, execution time, cancellation time) Time)] (54321, 234, 50, 96699900,1234, sell, 9999, 100, 2870000, NULL, NULL) and virtual fill table [(partial fill ID, order ID, order status at fill, (Contract value, contract amount, contract time)] (235, 54321, 235, 2870000, 50, 96700 200) is inserted.

It is assumed that the latest contract price: 2880000, the latest contract quantity: 70, the sell price: 2880000, and the sell price: 41, come from the vendor at 13:15 as the stock price information.

The order status is deduced as follows and inserted into the database. Brand order status table [(order status ID number, brand ID number, order status update time, check time)] (236, 9999, 96700500, NULL) Order status detail table [(order status ID number, type, value, quantity) (236, Sell, 2880000, 41) (236, Buy, 2870000, 50) (236, Buy, 2860000,119) (236, Trade, 2880000, 70) (236, Trade, 2870000,709)

When the virtual execution system retrieves the order status 236 and matches it with the order 54321, the partial execution process executes C (2870000) = 50 Y (2880000) = 70 Y (2870000) = 709 C (p) = 0 (p Y (p) = 0 (p is any value except 2870000, 2880000), and since this user has already executed 50 shares at 287,000 yen, D (2870000) = 50 Where N (2870000) = C (2870000) + Y (2870000) -D (2870000) -X (2870000) -Q (2870000) = 50 + 709-50-680-29 = 0 N (2880000) = C ( 2880000) + Y (2880000) -D (2880000) -X (2880000) -Q (2880000) = 0 + 70-0-0-0 = 70, so the contracted purchase of 2.88 million yen issued on the exchange A user can take 70 shares of an order,
Since the user needs only the remaining 50 shares, the database uses the virtual order table [(order identification number, order status at the time of order, partial contract volume, order time, orderer identification number, trade identification, stock identification number, order number, (Limit, Execution time, Cancel time)] (54321, 234, 100, 96699900, 1234, Sell, 9999, 100, 2870000, 96700500, NULL) and virtual contract table [(Partial contract ID, Order ID, Order status at execution, execution value, execution amount, execution time)] (236, 54321, 235, 2880000, 50, 96700 500) is inserted, and order 54321 is completed.

<Modification> As a modification of the second embodiment, a method using only the latest contract value / quantity can be considered. This method is useful for exchanges that do not provide quotes / quantities for secondary use. This method can be realized by excluding some functions from the above-mentioned “method using quote / quote in addition to the latest contract / quantity”. That is, the operation performed when a new sign is acquired may be excluded from the order situation inference method in the order inference system.

In another possible embodiment, the end user installs the software incorporating the present invention on his computer without going through the central server,
It is also possible to simulate virtual trading by directly receiving (semi) real-time stock price information from a stock price information provider.

Further, the end user installs software incorporating the present invention on his / her computer without going through the central server, obtains past stock price history data through some medium, and plays the stock price history. It is also possible to simulate virtual trading in real time while backing up. In this embodiment, although the reality decreases, it becomes possible to try the transaction again assuming another scenario.

<Effects of the Second Embodiment> The invention of the second embodiment estimates the order status from the most recent execution, the change of the quote, etc. in order to overcome the difficulty of obtaining or using the actual order status of the exchange. By simulating a contract by matching the inferred order status with the virtual order, a virtual transaction close to reality is simulated. In particular, it is characterized by the following points. Making trading of quantities that cannot be traded in reality almost impossible. Partial execution according to tradable quantity makes impossible possible. Orders that have not yet been filled by the exchange but have been placed can be subject to virtual trading.

While the embodiments of the present invention have been disclosed above, the following modifications can be considered in this embodiment. In the embodiment, for example, when buying stocks, a function of searching by company name or the like is disclosed. However, it is uneasy for a beginner to know which stock to buy. Therefore, various kinds of statistical information may be provided to beginners as a reference for stock purchase.

For example, for a person who wants to buy a brand whose price is rising, a list of the top number of brands whose brand has risen by a predetermined rate (%) or more in a predetermined period is displayed. Alternatively, for a person who wants to buy a brand whose price is falling, a list of the top predetermined number of brands that have fallen by a predetermined rate (%) or more in a predetermined period is displayed. In addition, for those who want to buy volatile stocks,
A list of the top number of issues whose volatility over a predetermined period is equal to or higher than a predetermined rate (%) is displayed.

The data of the excellent performer of the virtual investment game may be statistically processed to provide the following brand list, for example. (1) Top 10 companies by market capitalization of the predetermined number of shares held by the top predetermined number of game results at a certain point in time;
(3) Cumulative sales contract amount of the top predetermined number of people at a certain time
10 companies, (4) Top 10 companies that have realized realized profits at a given time, (5) Top 10 companies that have realized realized losses at a certain time, (6) The top 10 companies with unrealized gains from the top predetermined number of companies, and (7) the top 10 companies with unrealized losses from the top predetermined number at a certain point in time.

Further, virtual trading data for each participant may be statistically processed to provide, for example, the following brand list. (1) Top 10 companies by market capitalization of shares held at a given time;
(3) Cumulative sales contracts at a certain point 10 companies (4)
Top 10 companies that have realized realized profits at a certain time, (5) Top 10 companies that have realized realization losses at a certain time, (6) Top 10 companies that have unrealized profits at a certain time, (7) Top 10 companies with unrealized losses. Such a brand list may be displayed in the order of the participants' ranking, or may be displayed in alphabetical order or alphabetical order of the nicknames registered by the participants at the time of registration. By searching for a nickname of a participant, a mechanism for displaying a brand list of the participant having a specific nickname may be created. In addition, a mechanism for searching for a participant whose name is displayed in the name list of the above (1) to (7) is created from a specific name, and based on this, the participants can use, for example, e-mail or the like. A mechanism for mutually exchanging information may be created.

Note that the participant can be prevented from displaying his / her brand list on the Web. By displaying such a stock list after a lapse of, for example, one week from the last day of the statistical processing target period, it is possible to adjust the influence of the stock list on actual market price formation. In addition, the above-mentioned statistical information should be made visible only to game participants, and non-game participants can see the amount of money, but the name of the brand should be displayed as "*****" in plain text. Thus, it becomes a material for inviting users to participate in the game. As an embodiment, an example in which the present invention is applied to a virtual investment game is described. However, the virtual investment simulation device of the present invention can be suitably used for education and training for training human resources for actual stock investment. is there.

Note that the virtual investment simulation system of the first embodiment does not consider the actual transaction volume in the market,
Perform a virtual transaction using the latest transaction actual price. As a result, there is a problem that, although the number of transactions in the market is very small, it is possible to buy and sell far from the actual market transaction volume in the virtual investment simulation. For example, buy a stock that moves in the range of 1-2 yen for 1 yen,
By repeating the transaction of selling at 2 yen, it is possible to obtain on a simulation an investment return that is considered difficult in the actual market due to liquidity problems.

This problem can be solved by combining the following processes. (1) Total purchase price per issue held (average purchase unit price × number of shares purchased)
If the total purchase amount (current value data × number of shares purchased) of the buy order for the brand exceeds, for example, 10 million yen, the buy order for the brand is canceled or the order execution is postponed. (2) If the total purchase amount per brand exceeds, for example, 10 million yen, a process for canceling the purchase order for the brand is performed. (3) The stock price
For example, for low-ranking stocks of 50 yen or less, (1)
Alternatively, the upper limit of the total purchase amount of (2) is, for example, 1000
Reduce from 10,000 yen to 1 million yen. (4) Calculate a fixed percentage of the actual market transaction volume, for example, 1/100 for each issue, and if the total number of shares purchased by the participants exceeds this, according to the number of shares ordered To adjust the number of shares in the buy order for each participant who distributes the number of shares to be prorated, or according to the time of the buy order,
A process is performed to make adjustments so that purchases can be made preferentially in the order of time.

Further, by setting a limit on the total purchase amount per issue as described above, it becomes a result of investing in more issues on the virtual investment simulation, and the educational effect of learning the method of diversified investment is thereby obtained. Can be expected.

In the virtual investment simulation, only trading in unit shares may be possible. This allows the user to get an experience closer to the actual buying and selling of stocks. Further, when the total purchase price of a certain stock in unit shares exceeds the upper limit of the total purchase price in the preceding paragraph, there is a problem that the purchase of the relevant stock becomes impossible on the virtual investment simulation. This problem can be solved by extracting brands in which such a problem occurs, and performing processing such that these brands can be purchased with unit shares as the upper limit.

[0106]

As described above, the virtual investment simulation apparatus of the present invention comprises: an order receiving means for receiving a virtual buy or sell order; a current value information receiving means for receiving current price information; A virtual stock transaction execution means for executing a virtual stock transaction based on the information and the current value information, and a storage means for storing at least a transaction result. According to the present invention, a buy order or sell order of stocks and current value information of stocks are input almost in real time, and virtual trades are sequentially executed by the virtual trade execution means. This makes it possible to simulate stock trading.

Further, according to the invention of the second embodiment, the order status is inferred from the latest execution, the trend of the quote, etc., and the execution is simulated by matching the inferred order status with the virtual order, thereby realizing a close to reality. Can simulate virtual trading, making it almost impossible to trade in quantities that cannot be traded in reality, making it possible to do partial contracts according to tradable quantities, not yet traded on exchanges There is an effect that the order for which is placed can be a target of virtual trading.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration example of the entire system of the present invention.

FIG. 2 is an explanatory diagram showing information exchange between servers.

FIG. 3 is a flowchart showing the contents of a user access process of the present invention.

FIG. 4 is a flowchart showing the content of stock price information input processing of the present invention.

FIG. 5 is a flowchart showing details of a pseudo transaction process according to the present invention.

FIG. 6 is an explanatory diagram showing accumulated contents of a DB 15 in the present invention.

FIG. 7 is an explanatory diagram showing an example of an input screen of a sell order to be selected from owned shares.

FIG. 8 is an explanatory diagram showing an example of an input screen for a sell order with a limit price.

FIG. 9 is an explanatory diagram showing an example of an order condition confirmation screen of a sell order.

FIG. 10 is an explanatory diagram showing an example of a sales order acceptance notification screen.

FIG. 11 is an explanatory diagram showing an example of a brand search screen in a buy order.

FIG. 12 is an explanatory diagram showing an example of a screen for displaying a brand search result in a buy order.

FIG. 13 is an explanatory diagram showing an example of an order condition input screen for a buy order.

FIG. 14 is an explanatory diagram showing an example of an order condition confirmation screen for a buy order.

FIG. 15 is an explanatory diagram illustrating an example of an order acceptance notification screen in a buy order.

FIG. 16 is an explanatory diagram showing an example of data of a sell order.

FIG. 17 is an explanatory diagram showing a data example of a buy order.

FIG. 18 is an explanatory diagram showing an example of securities held and cash data held by a specific user.

FIG. 19 is an explanatory diagram showing a data example of current value information.

FIG. 20 is an explanatory diagram (1) showing an example of data at the time of executing a pseudo transaction.

FIG. 21 is an explanatory diagram (2) illustrating an example of data at the time of executing a pseudo transaction.

FIG. 22 is an explanatory diagram (3) illustrating an example of data at the time of executing a pseudo transaction;

FIG. 23 is a functional block diagram showing a configuration of a second exemplary embodiment of the present invention.

FIG. 24 is a flowchart showing an outline of processing of a main part of the second embodiment of the present invention.

[Explanation of symbols]

10 virtual investment game system, 11 Web server,
12: pseudo trading server, 13: stock price feed server, 1
4 ... DB server, 15, 53 ... Database, 16 ... L
AN, 20: Internet, 30, 31: User terminal, 40: Stock price information server, 50: Order status inference system, 51: Virtual order reception / inquiry system, 52: Virtual contract system

Claims (6)

[Claims] An order receiving means for receiving a virtual buy order or a sell order, a stock price information receiving means for receiving at least current stock price information, and a virtual order based on information received by the order information and the stock price information receiving means. A virtual investment simulation device, comprising: virtual stock transaction execution means for executing stock trading; and storage means for storing at least a trading result. 2. The order receiving means records the received order information with a receiving time added thereto, and the virtual stock transaction executing means records the time of the order information and the current value received by the current value information receiving means. The virtual investment simulation apparatus according to claim 1, wherein the order information to be executed is selected by comparing the order information with the time. 3. The order receiving means stores the received order information in a first storage area of a storage means, and the current value information receiving means stores the received current value information in a second storage area of the storage means. The virtual stock transaction execution means reads out the oldest current value information from the second storage area and searches for order information in the first storage area based on the current value information, thereby virtually 3. The virtual investment simulation apparatus according to claim 2, wherein a stock transaction process is executed, and the transaction result stored in the storage unit is updated based on the execution result. 4. The virtual investment simulation apparatus according to claim 1, further comprising information providing means for providing statistical information on stock prices including a stock ranking or a portfolio to a user. 5. The stock price information receiving means receives stock quote information including a sell quote and its quantity, a buy quote and its quantity, together with the latest current price. The virtual investment simulation apparatus according to claim 1, wherein virtual stock trading is executed based on the stock price information received by information receiving means. 6. A step of receiving a virtual buy or sell order, a step of receiving current price information of a stock price, a step of executing a virtual stock transaction based on the order information and the current value information, and storing a transaction result. Performing the virtual investment simulation method.