WO2001039065A1

WO2001039065A1 - System and method for collecting security transaction sentiment data

Info

Publication number: WO2001039065A1
Application number: PCT/US2000/026457
Authority: WO
Inventors: Harish Devarajan; Jesse Stone; David Michaels; Hyung-Jin Kim; Mark Tolani; Richard Yen; Huy Ton
Original assignee: Shockmarket Corporation
Priority date: 1999-11-23
Filing date: 2000-09-21
Publication date: 2001-05-31
Also published as: AU1430701A

Abstract

A method of collecting sentiment data relating to security trading (20). The method includes providing a ballot having a plurality of reasons for trading a security (24) to an investor after the investor has placed an order for the security (22). The ballot is configured for receiving electronic entries. The method further includes receiving a reason identified by the investor on the ballot for trading the security and storing the reason identified by the investor and the security traded in a database along with other sentiment data (25). A system for collecting sentiment data is also disclosed.

Description

SYSTEM AND METHOD FOR COLLECTING SECURITY TRANSACTION SENTIMENT DATA

BACKGROUND OF THE INVENTION

The present invention is related generally to methods and systems for monitoring and analyzing security transactions, and more particularly, methods and systems for collecting and presenting sentiment data for security transactions.

The stock market in general has provided high rates of return for money invested over the last few years. This, along with the availability of online trading has resulted in a significant increase in the number of people investing in the stock market. Financial institutions and individual investors often rely on computer systems and programs to analyze investment options and strategies.

Many investors analyze how a company or financial market has performed in the past and its expectations for the future prior to investing in a company's stock. In this manner, investors attempt to forecast what a financial security such as a

company's stock will do in order to purchase financial securities which will go up in value and provide the greatest rate of return. Unfortunately, even after careful analysis the ability to project the future activity and performance of a financial security is never a sure thing. Nevertheless, many financial planners, creators of investment portfolios, and individual investors attempt to project the future performance of financial securities with varying results. Much of the stock information available today including that online includes subjective market editorial or complicated technical indicators. When people, for example, provide messages on stock investment chat boards, a reader does not know if the writer of the message actually invested in the stock or is merely voicing his opinion about a stock in an attempt to affect the stock price.

Furthermore, there is no way for an investor to easily analyze his stock trading performance and review whether the reasons for making a particular trade was in fact a valid reason. The sentiment behind people's trading activities would

provide a useful insight for investors trading in related securities or common industry securities.

SUMMARY OF THE INVENTION

A method and system for collecting, analyzing, and presenting user sentiment data for security transactions is disclosed.

A method of one embodiment of the present invention is for collecting sentiment data relating to security trading. The method generally includes providing a ballot configured for receiving electronic entries and electronically receiving sentiment data and associated security transaction information entered

on the ballot by an investor. The method further includes storing the sentiment data and the associated security transaction information in a database. A system of the present invention is for collecting sentiment data related to security transactions. The system generally includes a computer system accessible for online interactive communication with users and a processor configured to receive sentiment data and associated security transaction information. The system further includes storage medium for storing the sentiment data and associated security transaction information.

In another aspect of the invention, a computer program product for collecting sentiment data relating to security trading generally comprises computer code that presents a sentiment ballot to an investor for entering sentiment data. The product further includes computer code that receives the sentiment ballot and stores the sentiment data along with associated security

transaction information, and a computer readable medium that stores the computer code.

In another aspect of the invention, a method for collecting user sentiment data electronically generally comprises providing a ballot having a plurality of reasons for placing an order to a user. Each of the plurality of reasons has a weight assigned thereto. The ballot is configured for receiving electronic entries and comprises a top-level ballot including a primary list of reasons and a second- level ballot including a secondary list of reasons. The primary list includes

reasons with a higher weight than the reasons on the secondary list. The method further includes receiving a reason identified by the user on the ballot for placing

the order and increasing the weight of the reason matching the identified reason and decreasing the weight of the other reasons. Reasons from the primary and secondary lists are switched if the weight of a reason on the secondary list is greater than the weight of a reason on the primary list.

A method for creating a certificate verifying that an order was placed by a user for use in electronic communication generally comprises placing an order in an electronic media and creating a certificate generated from information contained in the order after the order is completed. The certificate specifies the user and type of order placed and is configured for attachment to a message from the user in the electronic media.

In another aspect of the invention a method of collecting security trading information generally comprises electronically receiving security transaction information from an investor, storing the security transaction information in a database along with other security transaction information from other investors,

and grouping investors based on the security transaction information.

The above is a brief description of some deficiencies in the prior art and advantages of the present invention. Other features, advantages, and embodiments of the invention will be apparent to those skilled in the art from the following description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram illustrating screens used to trade stock and collect and display information relating to a user's reasons for performing the trade, in a system of the present invention.

Fig. 2 is a top-level ballot screen used to input user sentiment data.

Fig. 3 is a second-level ballot screen.

Fi ^xog.- 4 is a third-level ballot screen.

Fig. 5 is a table illustrating a database used to store trading activity and ballot information.

Fig. 6 is a flowchart illustrating collection and storage of user sentiment data in the database shown in Fig. 5.

Fig. 7 shows bar charts displaying the top reasons for buying, selling, or shorting a specific stock and the number of shares traded for these reasons.

Fig. 8 is a chart showing stocks which were traded for the same reason as listed in one of the charts shown in Fig. 7.

Fig. 9 is a bar chart illustrating volume of shares traded for a specific reason, company, and trade action over a specified period of time. Fig. 10 is a graph of stock price versus time with trade activity, reasons for trade, and news events identified on the graph.

Fig. 11 is a Web page displaying a certificate used to verify that a trade was made by a specific investor.

Fig. 12 is an entry screen used to create the certificate shown in Fig. 11.

Fig. 13 is a screen displaying a portable certificate containing a URL linked to the page displaying the certificate shown in Fig. 11.

Fig. 14 is a screen illustrating a chat room bulletin board displaying a posted message containing the portable certificate of Fig. 13.

Fig. 15 is a summary screen provided to a user after completion of a stock trade and ballot.

Fig. 16 is a table illustrating trades made by other investors with similar trading histories.

Fig. 17 is a screen for use in entering reasons for display on one or more of the ballot screens.

Fig. 18 is a screen for use in modifying a ballot by changing the order or grouping of reasons on the ballot.

Corresponding reference characters indicate corresponding parts throughout the several views of the drawings. DETAILED DESCRIPTION OF THE INVENTION

A system and method for monitoring security transaction sentiment data is disclosed. The following description is presented to enable any person skilled in the art to make and use the invention. Descriptions of specific embodiments

and applications are provided only as examples and various modifications will be readily apparent to those skilled in the art. The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is to be accorded the widest scope encompassing numerous alternatives, modifications, and equivalents consistent with the principles and features disclosed herein. For purpose of clarity, details relating to technical material that is known in the technical fields related to the invention have not been described in detail so as not to unnecessarily obscure the present invention.

Referring now to the drawings, and first to Fig. 1, a series of screens used

to conduct online security transactions and input user sentiment data are shown. The term "sentiment data" as used herein includes, for example, reasons for conducting a security transaction, persons who suggested a security transaction, location of investor when security transaction was first considered, length of time investor followed the stock before conducting the transaction, length of time investor plans to hold the stock, and other information relating to why an investor selects or executes a security transaction. For example, user sentiment data may include a reason why an investor made a certain transaction and associated security transaction information may include the type of security traded (e.g., company stock), trade action (e.g., buy, sell, short, cover) and the number of shares of stock traded. The system of the present invention is used to collect sentiment data after the order is placed, before the order is placed, or at the time the order is placed, analyze the data collected, and display the data in various formats, as described below. The data may be used by an investor to review stocks traded for reasons similar to those used by the investor or may be used to analyze performance of one or more investors over a period of time, for example. A certificate may be created based on the sentiment data entered by an investor to verify that he made a specific trade action for a number of shares of a stock and may even include the reason why the investor made the transaction. As further described below, this certificate may be used to provide credible information to support an investor's statements made in electronic communications, for example.

The following describes a system for use in monitoring, analyzing and

presenting data regarding the trading of financial securities such as stock. It is to be understood, however, that the system described herein may also be used to monitor and analyze trading activities of other types of financial securities or other activities such as the buying or selling of various goods or services. The system is preferably used in conjunction with an online brokerage service (e.g., E*TRADE or DATEK). The system may be integrated directly into the brokerage Web site, or the system may be located on a separate Web site which is linked directly to the brokerage site. For example, the brokerage site may include a selectable icon representing the sentiment collection system, which will display information within the current window or launch a separate browser window when selected. The browser window may contain, for example, a summary of the sentiment collection system and instructions describing how to register to use the system. The user may then register so that whenever he processes a trade on the brokerage site he will be brought to ballot screens described below, to enter his sentiment data. Once the user is registered to use the system he will then be allowed to view various charts and graphs providing a

summary of the sentiment data collected by the users. The sentiment data may also be available for anyone to view at the brokerage sites or at another web site on the Internet, for example.

It is to be understood that although the system is described herein for use with a brokerage site on the Internet, the system may also be used in other types of applications. For example, the system may be stored on a server and obtained through a network system for a select group of users, or the system may be run on a single computer and accessed by a user to provide analysis based only on the

activity of the user. However, if the system is not used in direct connection with a brokerage company or Web site, the data collected may not be as credible as the data collected in conjunction with the actual transaction.

The methods and processes described below are preferably implemented in a computer program product having computer codes which perform the various steps of the method and process. The computer codes are preferably stored in a computer readable medium, such as CD-ROM, floppy disk, zip disk, tape, flash memory, system memory, hard drive, or data signal embodied in a carrier wave, such as over a network.

Fig. 1 shows an example of screens which may be displayed to a user when trading stock online and using the system of the present invention. The first two screens 20, 22 (or screens containing similar information) are typically presented to a user when trading stock on an online brokerage site. After logging on to the brokerage site and entering a password the user may enter the type of stock, specific trade action (e.g., buy, sell, short, cover), and the number of shares

he wishes to trade in the stock trade screen 20. After entering this information the user will select a submit button 21 located on the stock trade screen 20 to process his order. The user is then presented with a confirmation screen 22 which also includes a submit button 21 which the user must select to continue processing his order. After confirming his stock trade, a top-level ballot screen 24 used to collect sentiment data from the user will appear. The ballot screen 24 is preferably presented to the user immediately after he has made a trade so that the reason he made the trade is fresh in his mind. Once the user specifies the reason for making the trade, a summary screen 25 will appear. The summary screen 25 provides the user with various types of statistics on recent sentiment data collected for the stock he just traded and sentiment data for different stocks traded for reasons similar to the one he selected, as described below. The summary screen 25 may include different types of sentiment data displayed in various formats and preferably includes links to pages containing related data which may be of interest to the user.

The user may elect not to vote on a particular stock trade. In this case the user may move on to a different site or return to the stock brokerage home page, for example. The user may be required to select a reason for a certain number of

trades (e.g., 3 out of 4 trades) in order to continue to have access to the collected sentiment data.

The top-level ballot screen 24 is shown in Fig. 2 with additional detail. The top-level ballot 24 includes a number of reasons why a user may have traded a specific security. For example, as shown in Fig. 2, the ballot screen 24 includes reasons why a user may have bought stock of Company X. A different ballot screen is used for other trade actions since reasons listed for a buy action may not be applicable to the other trade actions (i.e., sell, short, cover). Some reasons listed under a specific stock for a buy action may be similar to a reason listed

under the same stock for one of the other trade actions but may be worded slightly different. For example, within a buy ballot for Company Y one reason listed may be "Company Y site crashes" and within a sell ballot for Company Y one reason listed may be "Market overreaction to Company Y site crash." These two reasons are referred to as opposition pairs, and are linked together (e.g., will point to each other in the database) so that it is possible to compare trade volumes between them.

The reasons listed on the top-level ballot screen 24 are preferably grouped into classes. As shown in Fig. 2, the classes may include company analysis, industry analysis, general market conditions, and price/chart analysis. The top- level ballot 24 includes four reasons for each class, for example. Each reason is listed with a short summary title such as "Company X rumored to move into software business." If the user does not see the reason he is interested in, but believes his reason would be listed within one of the four classes, he can click on "more" under that class. A second-level ballot screen 26 will appear expanding the list of reasons under Company Analysis, as shown in Fig. 3. The second-

level ballot 26 includes a list of all the reasons in a given class including those listed on the top-level ballot 24. If the user still does not see a reason which matches the specific reason he had in mind when he traded the stock he can type in a one-line description of his specific reason in a box 27 next to "Other" on the second level ballot. When a user creates a new reason, it will be sent to an analyst, as described below. The analyst will decide whether the reason belongs on the ballot. If the analyst decides to add it to the ballot, he will provide a summary title and detailed explanation. If the user wants to go back to the top- level ballot 24 to view the other classes, he can select "back" to get back to the top-level ballot.

If a user is interested in finding more about a specific reason shown on the top-level ballot 24 (Fig. 2) or second-level ballot 26 (Fig. 3), he can view a detailed description of the reason at a third-level ballot 28 (Fig. 4). The reason title summaries on the top-level ballot 24 and second-level ballot 26 are preferably hyper- linked to the corresponding third-level ballot 28. For example, when the user clicks on one of the reason summaries, he is brought to a new Web page (screen 28) devoted primarily to the reason summary he clicked on. The third-level ballot screen 28 provides an expanded explanation of the reason, and may also include a date if the reason is related to a specific event. Below the detailed explanation is a button 30 which reads "Vote for this reason." The user can click on button 30 to vote for this reason without having to return to the top- level ballot 24 or second-level ballot 26. The screen 28 preferably includes links 32 to get the user back to the top-level ballot 24 or second-level ballot 26 if he does not wish to vote for this reason after reading the detailed explanation.

The reasons included in the ballot may be selected by an equity analyst, for example. When coverage is initiated on a new security, the analyst will prepare an initial list of reasons to display on the ballot screens 22, 24 (Figs. 2 and 3). The equity analyst may review information on securities in the same sector as the new security and recent news stories related to the security. Global reasons (i.e., reasons that appear on the ballot of each stock for a specific trade action) are automatically included in the ballot for each new stock.

The list of reasons on the ballot screens 24, 26 are preferably periodically updated throughout the day. For example, the analysts may review news items which may impact a particular industry or stock and add new reasons to the ballots. In addition to adding new reasons, the reason lists are preferably continuously updated so that the top reasons (i.e., reasons selected most often) are located on the top-level ballot screen 24. The equity analysts follow the news of a number of stocks in order to keep the ballots up to date. When a new item appears that the analyst believes should appear as a reason on one or more of the ballots, the analyst enters the reason into a database. The equity analyst may use entry screens as shown in Figs. 17 and 18, for example. The analyst enters the reason summary and a longer reason explanation. The reason may be identified as a global reason, in which case the reason will be automatically listed under all stock ballots. The analyst next maps the reason to the appropriate trade actions.

The analyst can also select a class, cluster, weight, and display order for use in sorting the reasons on the ballots (as described below). Fig. 17 shows an

exemplary entry screen for entering a new reason and mapping it to specific stocks and trade actions. Fig. 18 shows an exemplary screen for modifying class, cluster, display order, and weight for a specific stock and trade action.

When a reason is first created it is assigned to various securities and trade actions. For each of these, a class, cluster, display order, and weight is assigned. The weight determines which of the reasons within each class are displayed on the top-level ballot 24 and the display order determines the order of the reasons within each cluster. The clusters (described below) are also displayed in a predetermined order on the second-level ballot 26. The weight and display order are used to organize the reasons along with various other rules. For example, since the static reasons always appear on the ballot, they preferably remain listed in the same order on all ballots so that the user gets used to seeing them in the same position relative to one another, regardless of their current popularity. The news items, in contrast, may be listed with respect to their weight and display order, for example. The following describes an example of a method used to organize the list of reasons.

The analyst creating the initial reason list for the ballot 26 assigns a weight to each reason. The reasons with the highest weights (primary reasons) are listed on the top-level ballot 24. Preferably, the reasons listed on the top-level ballot 24 are those which are most likely to be selected by an investor. This reduces the time it takes for an investor to fill out the ballot, since he will not need to look at the second-level ballot 26 if his reason is located on the top-level ballot 24. However, this method may statistically alter the weighting of the reasons, since an investor may be more likely to pick one of the first few choices. Thus, it is to be understood that different weighting and ranking schemes may be used. The weights are preferably periodically updated so that as a reason

becomes more popular (such as when a big news event is released) it will move to the top-level ballot 24. One method for updating the weights of the reasons is to increase the weight of a reason every time a user votes for the reason and slightly decrease the weight whenever a user votes for a different reason within the same cluster. Reasons which are infrequently selected may eventually be dropped off the list. For example, if a reason's weight becomes very small due to lack of popularity, an alarm may go off to the analyst recommending that the analyst remove the reason from the ballot.

The following provides an example of a method for calculating weights

for the reasons listed on the ballot. The sum of the weights of each reason is set equal to the number of reasons on all second-level ballots 26 for a specific trade action and stock For example, if the ballot has five reasons, the weights for each of the five reasons will add up to five. When a reason receives a vote, its weight will be increased slightly (e.g., by 0.1). The other weights will then all be modified equally so that the total of the weights still equals the number of reasons. For example, suppose the weights (wl, w2, w3, w4, w5) for five reasons are each equal to one and someone votes for the reason with weight w2. The weight w2 will be increased by 0.1 and all the other weights (wl, w3, w4,

w5) will be multiplied by 5.0/5.1 so that the total sum remains equal to 5. The result will be: w2 = 1.078 and wl = w3 = w4 = w5 = 0.980. If the reason having weight w3 next receives a vote, the new weights will be: wl = 0.961, w2 = 1.057, w3 = 1.059, w4 -= 0.961, and w5 = 0.961. The weight w3 is now slightly larger than weight w2. This is because although both reasons with weights w2 and w3 have each received one vote, the vote for the reason having weight w3 was more recent.

By calculating the weight in the manner described above the weight will

decay exponentially over time (w <x e^'τ). As previously described, the weights

are used to determine which reasons are placed on the top-level ballot screen 24.

The exponential decay of the weights over time will prevent a sudden decrease in the weight of a particular reason so that the reasons listed on the top-level ballot screen 24 are not constantly changing. The weight is also used to determine when a reason has become old and should no longer be listed on the ballot. A reason is preferably deleted from the second-level ballot 26 when its weight

drops below a certain threshold (e.g., 0.1).

The reasons are preferably not listed simply by weight on the second- level ballot screen 26 because this would result in a constant shuffling of the reasons on the ballot. Instead, the display order is used to organize the list of reasons on the second-level ballot screen 26. The display order is used to organize reasons within the cluster on the second-level ballot 26. The cluster is a subgroup of reasons within a class provided to organize the reasons in a structured and logical way for the user. For example, the clusters allow reasons to appear generally in the same display order every time the user sees the ballot. This makes the ballot

easy to use, thus encouraging frequent voting by an investor. Referring to Fig. 2, the reasons under the Company Analysis and Industry Analysis classes may be grouped into clusters such as news, ongoing conditions, local static, and global static, for example. The clusters for the General Market Conditions class may include news, ongoing conditions, and global static. The Price/Chart Analysis class may be broken into non-technical and technical clusters, for example. The news cluster would include items such as "Microsoft announces new online auction site." These reasons are typically confined to a small number of companies (perhaps in the same industry) and are only on the ballot for a short amount of time. Ongoing conditions may include "Falling PC prices." These reasons typically impact a large number of companies and may remain on the ballot for a long period of time. A static reason may be "Marketing strategy." These reasons do not change over time. A static reason may be global (i.e., apply to all (or almost all) stocks) or local (i.e., does not apply to all stocks). For example, a local static reason is one that does not change over time and does not apply to all stocks, whereas a global static reason does not change over time and does apply to all stocks. Preferably, each cluster contains either all global reasons or no global reasons. This provides for easier updating by the analyst and simpler groupings for the user. The cluster and class for each reason are selected when the reason is added to the ballot, or when the ballot is initially created.

The display order is preferably selected when the reason list is first composed, and may be automatically adjusted over time based on weights or other factors, or adjusted manually when a new reason is inserted into the list. For example, if three reasons are included in a cluster within a class and the preferred order is to have reason 2 on top, followed by reason 3, followed by reason 1 at the bottom, the display order values would be: reason 2 = 1; reason 3 = 2 and reason 1 = 3.

Table 1, shown below, provides an example of a reason list, with associated cluster, global or non-global identifier, display order, and weight.

TABLE 1

The first column in the table lists the summary reason, the second column specifies the cluster in which the reason is located, the third column indicates whether the reason is a global or non-global reason, the fourth column specifies the display order, and the fifth column specifies the weight. This reason list may appear on a second level ballot screen 26, for example, with only the first column being visible to the user. The other columns are used to organize the reasons and are not visible to the user. The reasons are first grouped within their cluster based on the display order number, and the clusters are then positioned relative to one another. The order of the clusters is predetermined and preferably remains the same so that a user will always see the same type of reasons in a specific location in the reason list. For example, as shown in Table 1 the news cluster is listed first. The weight is used to determine which of the reasons are placed on the top-level ballot screen 24. For example, the first three reasons and the fifth

reason listed in Table 1 would be placed on the top-level ballot 24 since they have the highest weights within their class. These reasons would then be positioned relative to one another on the top-level ballot 24 according to the position of their cluster on the second level ballot screen 26.

It is to be understood that the reasons described above, classes, clusters, types of clusters, number of reasons, ballots, and ranking scheme may be different than described above without departing from the scope of the invention. For example, the number of reasons listed on a ballot may be increased or decreased, and the reasons may be condensed onto a single ballot screen. Also, the reasons may be ranked strictly according to weight or may be static, always remaining in the same position. Instead of including a list of reasons or other sentiment data, the ballot may include a brief description of the sentiment data

being requested and a blank space identified for entering the reason or other sentiment data. The ballot may also be an e-mail containing the sentiment data which is sent to a data collection center. The ballot may also be presented in other forms such as a stand alone application or a browser plug in module, for example.

After the user submits the ballot with his selected reason and the order is executed, the data is sent to a table 40 as shown in Fig. 5, for example. User sentiment data is preferably registered as being credible only when orders are executed. Thus, user sentiment based on an open order is not included in table

40. This results in data presentation which includes only credible data and provides user sentiment only for dollars spent, not intended dollars spent. For example, if a user places several limit orders far from the market value in the hopes of skewing user sentiment numbers, the data will never be entered if the orders do not get executed. This also prevents market orders placed during non- market hours and later cancelled from being included in the sentiment data. Also, users are preferably only permitted to register trading reasons right after they have placed an order for a security. For example, if the ballot is not submitted within fifteen minutes after the order has been executed the ballot may be considered stale and not counted in the aggregate total. When either a ballot is entered or an order is placed, the data is stored in temporary memory. If only the ballot is received, the data will remain in temporary storage until the end of the day. If the trade is not executed before the first market close following the order's placement, the ballot will be deleted. If only the executed order is received, it will remain in memory for fifteen minutes. If a corresponding ballot is not received within this time, the data will be deleted. This process is further described below with respect to the flow chart shown in Fig. 6.

For limit orders, the time between ballot submission and order execution can vary from seconds (if it is a marketable order) to months. The sentiments are preferably posted with the date that the order was executed. However, the sentiments may also be posted with the date that the order was placed, even though it may have been executed at a later time. The reason for posting with the date that the order was placed rather than executed is because the reason for making the trade at the time of the order may no longer be applicable on the date

the order is executed. As discussed above, the data will not be considered credible and included in the database until the order is actually executed.

Market orders may be assumed to be executed so that ballot data received for market orders can be considered credible. While it is true that market orders can be canceled or replaced, the assumption that they are executed is fairly reasonable. In the case of non-market orders (limit/stop/stop-limit) the price information can be used to approximate when the order executes. For example, the price of a security may be checked every few minutes (with interpolation between intervals). If a stock price reaches the stop or limit price, the sentiment for that order will be considered credible and entered into the database.

Information on cancellation and replacement orders may also be used to further refme the sentiment data. For example, if an order for two hundred shares is cancelled after one hundred shares are executed, only one hundred shares of sentiment data are registered as credible.

The data collected in the table 40 of Fig. 5 may be transferred to an intraday aggregate sentiment table at periodic intervals (e.g., every hour). The data may be sorted within the table by stock or reason, for example, to allow for quick searching and presentation of the data. At the end of the day the data from the intraday sentiment table is preferably transferred to a daily aggregate sentiment table. The data from the daily table may be sorted and then transferred as a daily bucket, for example, to a final sentiment data table.

The data within the table may also include a market hour flag and a valid

flag, each set to either true or false. The market hour flag is used to provide consistency among different charts and graphs. For example, one graph may

only include data for market hours (e.g., hours that the market is open) while another graph includes data for sentiment entered at any hour. In order to provide consistency between the two graphs, only data with a true flag for market hours will be entered in both graphs. The valid flag identifies whether a trade was executed within a specified period of time (e.g., same day) after the data was entered. If the valid flag is false the data will not be included in a chart. This provides consistency for charts displaying the same data, but viewed at different times.

In addition to the information shown in table 40 of Fig. 5, the table may also include execution time, sentiment ID (identifying a line of data in the table), subscriber ID (for user), brokerage ID (for brokerage site), brokerage trade ID (identifying specific trade), vote time, volume placed and executed, price type ID (e-g-, market or limit order), user reason ID (if user typed in new reason not listed in ballot), valid flag (true/false), and market hour flag (true/false).

Fig. 6 shows a flowchart illustrating a process for collecting and storing the sentiment data. The user first enters the stock name, number of shares and trade action on screen 20 (Fig. 1) at the brokerage site (step 50). The confirmation screen 22 next appears and the user clicks on the submit button 21 to confirm his order at step 52. The user is then brought to the top-level ballot screen 24 where he reviews the reasons listed (Fig. 2). If the user sees the reason that he traded the stock listed on screen 24 he can select the reason and submit the ballot. The user may also click on a class heading to see additional choices

(Figs. 2 and 3). If the user wants additional information on any of the reasons he can click on a specific reason which will bring him to screen 28 (Fig. 4). Once at screen 28, he may vote for the reason shown or return to the top-level ballot 24 or second-level ballot 26. The user may also enter a reason for his trade on screen 26 if none of the reasons listed matches his own. Once the ballot is placed (step 54) and the order is executed (step 56) the data is inserted into the sentiment table 40 (step 58) (Figs. 5 and 6). If the ballot is not placed within fifteen minutes after the order has executed the data is deleted (steps 60 and 62). If the ballot is placed but the order is not executed by the end of the day, the valid flag will be set to false and the data entered into the sentiment table (steps 64, 65, and 58). It is to be understood that the process for collecting and storing the data may be different than described and shown herein. For example, the user may be able to enter sentiment data for a period longer than fifteen minutes or the ballot may be stored longer than one day to wait for the order to be executed.

The data is preferably collected from many different brokerage services and stored in a common database so that users may view data across the online trading community. The data may also be collected from a single brokerage firm. As described below, the data may be sorted by trade action (buy, sell, cover, short), security, or a fixed time period (e.g., three hours, two days, one week). The data may also be analyzed for one investor to determine the investor's own performance. The following provides examples of formats for displaying the data.

Fig. 7 shows three charts 70, 72, 74 illustrating shares traded for the three

top reasons for buy, sell, and short activity of a certain stock. Each chart lists the three top reasons selected by persons trading the stock and the number of shares traded. These charts allow a user to view the reasons that other traders listed for transacting in a given security over a specified time period. For example, the user can see why other traders have been selling Microsoft stock over the past week. The user can change the security he is viewing, the trade action, or the time period.

While viewing the charts shown in Fig. 7, the user can click on any of the reasons to see how other securities were affected by this reason. Fig. 8 shows the resulting chart 80. The share volume for the original company is displayed showing the percentage traded for the selected reason along with two other companies with a high percentage of shares traded for the same reason. The chart displays what percentage of users selling these securities listed this reason as compared to all other reasons. For example, if "Falling PC prices" in the Reasons for Selling chart 72 of Fig. 7 is selected, the chart 80 in Fig. 8 will be displayed. The chart shows the percentage of stocks of Company X sold for "Falling PC prices" as compared to the percentage of stocks of Company X sold for other reasons. The chart also includes bar charts for two companies with a high percentage of stocks sold for the same or similar reason as "Falling PC

prices." Other trade actions may also be viewed. For example, it may be useful to see how many traders are selling one company stock because of this reason and how many users are buying a competitors stock for the same reason.

As described above, many of the reasons are listed only for specific securities. Thus, not all reasons are relevant to multiple securities. For example, if a company is charged with incorrect accounting practices, this may hurt that particular company but not necessarily its competitors. If a reason is only relevant for a single company, clicking on that reason will preferably generate a screen telling the user that no other companies have traded for that reason. Similarly, reasons may only be applicable for buy trade activity and not sell trade activity. Error messages may be displayed if the selected trade action is not relevant to any other securities.

Fig. 9 shows a chart 82 displaying share volume for a given security, trade action, and reason over a specified time period. For example, a user may be interested in seeing how many people traded a stock over the past week (broken down by day) or day (broken down by hour) for a specific reason. This allows a user to see, for example, trade activity when a company announced that they were acquiring another company. This chart may also show share volume over time for a specific reason and market sector or industry.

The data may also be presented to show the activity of a single investor.

For example, Fig. 10 shows a graph 84 of share price versus time for Company X stock. Plotted on the graph are bars positioned at the time the investor traded stock, with the volume of shares shown on each of the bars. The number of

shares bought are indicated on the bars extending upwardly from the horizontal

axis. The number of shares sold is indicated on the bar extending downwardly from the horizontal axis. Triangles identified as A-C are positioned on the graph above each bar to identify the reason given for trading the stock. Also shown on this graph are breaking news events, indicated by circles containing the numbers 1 and 2. The key to this graph includes the reasons (A-C) specified for each stock trade and the specific news events indicated by circles 1 and 2. This graph 84 allows a user to view his trading history and rate his performance over a period of time. The graph 84 is useful in helping an investor determine how well he timed the market, not just with respect to price movements but with respect to trade reasons. For example, if the user made a poor trade and notices that he made the trade right after a damaging news release, this may indicate that he should monitor the news (or real-time user sentiment) before trading. Also, if he made a good trade but for an unrelated reason (e.g., he sold stock at a stock's intraday high for personal reasons but the stock dropped because of a poor earnings report), he can realize that this was luck and not trading skill.

Another option which may be provided in conjunction with this graph is a personal effectiveness grade based on objective criteria. The user's perceived trading effectiveness may be graded using an objective criteria based on financial success and trade reasons. The user's trades may be analyzed to determine whether the user correctly anticipated rises in stock prices for the correct reasons and this information may then be used to provide the user with a score based on how well he timed the market. For example, if a user purchased Company X stock for reason Y at 2:00 p.m., a four hour window around the time of the trade can be analyzed to determine if more people made the same trade before or after

his trade. If Nl is defined as the number of shares of Company X stock that investors bought for reason Y from 12:00 p.m. to 2:00 p.m., and N2 is defined as the number of shares that investors bought from 2:00 p.m. to 4:00 p.m., the user's score S may calculated as:

S = N2/(N1+N2).

Thus, if the user was one of the first persons to trade for this reason, his score is

1.0; if he was one of the last to trade, his score is 0. If the support for the reason is uniform across time, the user's score is 0.5. The score may then be combined with a factor based on how much money the investor made from his trade to calculate a grade for the investor to give him a feel for if he is making the right trades for the right reasons.

The system may also be used to verify to others that a user has made a specific trade. For example, Fig. 11 shows a certificate 90 created to verify that a person posting a message actually did trade the security discussed in their message. This allows users to back up their opinions in messages created in electronic communications (e.g., chat rooms, e-mail). On existing bulletin boards, such as www.ragingbull.com, for example, users can post any random

information and those reading the message have no way of knowing whether or not the information is accurate. With the certificate 90, a reader may even click on the message and view recent trades that the poster of the message has made (as shown in Fig. 10, for example). This provides credibility to the poster of the message. For example, if a poster of a message recently bought Company X stock with the reason of "Their strategy to challenge Company Y is succeeding", a follow-up post on the bulletin board to this effect will be considered more credible because the poster of the message has actually spent money and purchased stock. The certificate owner may configure their privacy level to expose as little or as much information as they are comfortable with.

In order to create the certificate 90, the user is provided a screen 92 where he can enter a user name for his portable certificate after confirming his order and selecting a reason (Fig. 12). The certificate 90 will then be created at a specific URL 94 (e.g., http://www.shockmarket.com/1234567) shown in screen 96 (Fig. 13). The URL 94 may be linked to a page displaying the certificate 90 verifying the user's most recent trade. The URL 94 can be posted along with the user's postings or e-mails to make them more credible. For example, a user can post on an online bulletin board that he believes Company X is a good buy at the current price and include the URL 94 (Fig. 14). If someone clicks on the URL 94, he will be brought to a Web page which displays the portable certificate 90 for the user's last trade (Fig. 11). The page may also display additional trading information about the user (as shown in Fig. 10, for example), if the user has elected to display additional information about his trading activities.

A summary screen 25 may be displayed to the user immediately after he submits his ballot to provide the user a quick overview of reason data relating to the trade he just made (Fig. 15). The summary screen 25 includes the reason chart 80 (Fig. 8), the ranking of the reason the user selected for the stock he just traded, along with the top five reasons selected by others for the stock he traded. The summary screen 25 further includes a URL for connecting the user to a web site to create a portable certificate 90 to use in verifying to others the trade he just made. The summary screen 25 is designed to encourage investors to submit a ballot after they place an order and may include additional features, or other types of presentation of data.

Table 100, shown in Fig. 16 may be included in the summary screen or on a separate screen to identify investors that have conducted similar trades as the user, based on trading and balloting history. The table 100 lists trades made by investors with similar investor sentiment, based on a number of ballots (e.g., past twenty- four) the user has filled out. Included in the table is the time the trade was made, the stock traded, the trade action, the number of shares traded, the reason for the trade and an investor affinity rating which identifies how similar two investors are. For example, every time the user and another investor make the same trade for the same reason, the investor affinity value is increased by 1. The user can request to see recent trades (e.g., within the last day) made by an investor having a strong bond (high affinity rating) with the user. This allows the user to view a list of trades made recently by people with similar investment strategies. Similarity between investors (investor affinity) may also be based on risk preferences, industry preferences, or average time between trades, for example. The system may thus, group the investors based on security transaction

information or sentiment data submitted by the investors. It is to be understood that the graphs and charts shown and described herein are only examples of the type of data which may be presented. Many other types of charts, graphs, and data may be presented.

In view of the above, it will be seen that the several objects of the invention are achieved and other advantageous results attained.

As various changes could be made in the above constructions and methods without departing from the scope of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.

Claims

CLAIMSWHAT IS CLAIMED IS:

1. A method of collecting sentiment data relating to security trading, comprising:

providing a ballot configured for receiving electronic entries;

electronically receiving sentiment data and associated security transaction information entered on the ballot by an investor; and

storing the sentiment data and the associated security transaction information in a database.

2. The method of claim 1 wherein the sentiment data comprises reasons for trading the security.

3. The method of claim 2 further comprising identifying other investors

who have made trades of the same security for the same reason.

4. The method of claim 1 wherein the ballot includes a plurality of reasons for trading the security and wherein the electronic entries include selection of one or more of the reasons.

5. The method of claim 1 wherein providing the ballot comprises updating said plurality of reasons at periodic intervals.

6. The method of claim 1 wherein providing the ballot comprises providing the ballot to the investor after the investor has placed on order online to trade the security.

7. The method of claim 6 further comprising identifying when the order is executed.

8. The method of claim 1 wherein providing the ballot comprises providing the ballot to the investor before the investor has placed on order online to trade the security.

9. The method of claim 8 further comprising identifying when the order is executed.

10. The method of claim 1 wherein providing the ballot comprises

displaying a Web page to the investor.

11. The method of claim 1 further comprising displaying sentiment data to the investor.

12. The method of claim 11 wherein displaying sentiment data comprises presenting reasons selected by other investors for trading the security.

13. The method of claim 11 wherein receiving sentiment data comprises receiving a reason identified by the investor for trading the security and displaying sentiment data comprises presenting securities traded by other investors for the same reason identified by the investor.

14. The method of claim 13 further comprising displaying recent trades made by the other investors.

15. The method of claim 1 wherein the associated security transaction information comprises storing number of shares traded and trade action.

16. The method of claim 1 wherein the security is stock.

17. The method of claim 1 further comprising receiving an order for the security transaction after receiving the sentiment data.

18. The method of claim 1 further comprising receiving a confirmation that an order has been placed for the security transaction.

19. A system for collecting sentiment data related to security transactions, the system including a computer system accessible for online

interactive communication with users, said system comprising:

a processor configured to receive sentiment data and associated security transaction information from investors; and

computer storage medium for storing the sentiment data and associated security transaction information.

20. The system of claim 19 wherein the security transaction information comprises a stock identifier, number of shares, and trade action selected by the investor.

21. The system of claim 19 wherein the sentiment data comprises a

reason for selecting the security transaction.

22. The system of claim 19 further comprising a ballot page configured for receiving electronic entries of the sentiment data and the associated security

transaction information from investors.

23. The system of claim 22 wherein the ballot page is a web page.

24. The system of claim 23 wherein the ballot page is linked to an online brokerage site.

25. A computer program product for collecting sentiment data relating to security trading, comprising:

computer code that presents a sentiment ballot to an investor for entering sentiment data;

computer code that receives the sentiment ballot and stores the sentiment data along with associated security transaction information; and

a computer readable medium that stores the computer code.

26. The computer program product of claim 25 further comprising computer code that displays the sentiment data and the associated security transaction information.

27. The computer product of claim 25 wherein the computer readable medium is selected from the group comprising of CD-ROM, zip disk, floppy disk, tape, flash memory, system memory, hard drive, and data signal embodied in a carrier wave.

28. A method for collecting user sentiment data electronically, comprising:

providing a ballot having a plurality of reasons for placing an order to a user, each of said plurality of reasons having a weight assigned thereto, the ballot configured for receiving electronic entries and comprising a top-level ballot including a primary list of reasons and a second-level ballot including a secondary list of reasons, said primary list having reasons with a higher weight than the reasons on said secondary list;

receiving a reason identified by the user on the ballot for placing the order; increasing the weight of the reason matching the identified reason and decreasing the weight of the other reasons; and

switching reasons from the primary and secondary lists if the weight of a reason on the secondary list is greater than the weight of a reason on the primary list.

29. The method of claim 28 wherein increasing and decreasing the weight of the reasons comprises exponentially increasing and decreasing the weights.

30. The method of claim 28 wherein said plurality of reasons are grouped into classes and the reasons within each of the classes are grouped into clusters, the clusters being arranged relative to one another in a predefined order.

31. A method for creating a certificate verifying that an order was placed by a user for use in electronic communication, comprising:

placing an order in an electronic media;

creating a certificate generated from information contained in the order after the order is completed, the certificate specifying the user and type of order placed and being configured for attachment to a message from the user in the

electronic media.

32. The method of claim 31 wherein placing an order comprises trading a security online.

33. The method of claim 31 wherein placing an order comprises buying stock.

34. The method of claim 31 wherein placing an order comprises selling stock.

35. The method of claim 31 wherein creating a certificate comprises creating a certificate specifying the security traded, trade activity, number of shares traded, and the user.

36. The method of claim 31 wherein the message is an e-mail message.

37. The method of claim 31 wherein the message is a posting on an electronic chat room.

38. The method of claim 31 wherein the message is a posting on an

electronic bulletin board.

39. The method of claim 31 wherein creating a certificate comprises creating a URL linked to a Web page containing the certificate.

40. A method of collecting security trading information comprising:

electronically receiving an investor's security transaction information;

storing the security transaction information in a database along with other security transaction information from other investors; and

grouping investors based on the security transaction information.

41. The method of claim 40 wherein grouping the investors further

comprises grouping the investors based on sentiment data provided by the investors.

42. The method of claim 41 wherein the sentiment data comprises a reason for trading a security.

43. The method of claim 40 further comprising identifying a bond between investors and wherein the bond increases when investors conduct a security transaction with the same security and the same sentiment data.

44. The method of claim 40 further comprising displaying sentiment data from investors within a group.

45. The method of claim 40 wherein the security transaction information comprises a stock identifier, number of shares selected for trade, and a trade action.

46. The method of claim 45 wherein the security transaction information further comprises a date and time that the security transaction was executed.