The present invention generally relates to systems and methods for conducting account requests or transactions over a network. More particularly, the present invention relates to systems and methods for conducting account requests or transactions using natural language queries for example in connection with on-line securities trading platforms.
Various systems and methods have addressed problems associated with securities trading platforms. Typical online trading platforms provide a multi-user environment for the processing of securities related transactions. Each of these systems and methods has advantages and disadvantages. For example, U.S. Pat. No. 6,408,282 entitled “System and method for conducting securities transactions over a computer network” discloses the trading of securities over the Internet both on national exchanges and outside the national exchanges. The system supports a GUI interface and a continuous display of real-time stock quotes on the user's computer screen.
U.S. Pat. No. 7,020,611 entitled “User Interface Selectable Real Time Information Delivery System and Method” discloses a system that enables users to retrieve information from different types of user interfaces. The information is originally saved in a format suitable for a particular type of user interface, such as video displays. The information is then converted to a different format suitable for a different type of user interface, such as an audio speaker.
It would be desirable to create a system and method that is easy and intuitive to use for any level of online investor. It would also be desirable to create a process by which users could find information about securities, buy or sell securities, and project future growth among other things. Such improvements would take much of the complexity out of online trading and truly open up on-line trading to any level of user.
The invention is directed to a system and method for conducting account requests with a financial institution accessible with a client device over a network. An account is established with the financial institution and a user can access the account via the client device. The client device has a user interface that includes a natural language input. A request is input via the natural language input. The inputting step causes network components (e.g., server 42 and one or more software modules 50) to determine whether the request can be granted. Information respecting the request is transmitted to the user interface. The information includes an indication of whether the request can be granted.
The inputting step can cause the network components to query a search engine. In this case the search engine returns search results respecting the request. The request can be generally selected from the group including: a request for historical account information, a request for market price data, a request for analysis information, a request for a purchase of a security, a request for a sale of a security, or a request for status information.
The received information respecting the request can include a plurality of transaction choices, ones of which when selected cause the network components to execute steps in furtherance of the request. The received information respecting the request can also include a request for confirmation of the request. The system can access account information associated with the account and use at least a portion of the account information in connection with processing the request. The system can optionally include a speech recognizer and can receive audio based requests.
For a better understanding of the present invention, reference is made to the following description and accompanying drawings, while the scope of the invention is set forth in the appended claims:
a-2c show exemplary menu interfaces as are known in the art;
a and 4b show a command line interface for user initiated transactions as is known in the art;
The server(s) can also access and/or maintain account information (e.g., stored in database 46, 46′, and 46″) for a plurality of users. The servers can also provide a user interface (e.g., via a web interface) so that a given user can log into the system, request information (e.g., historical or current security pricing . . . ), initiate a transaction (buy or sell a security, options . . . ) or the like. It is understood that a virtually unlimited number of users can be associated with the system.
It is also understood that the system may be implemented with a variety of security measures (not shown) to ensure system integrity. For example, the system may include various security mechanisms to ensure that the user is properly authorized to access the system including: passwords, digital certificates, encryption, biometrics or the like as is well known in the art. In cases where speech recognition is utilized, the user's account information can include one or more biometric templates (or voice prints) associated with the user. The system can then perform speaker identification and/or voice authentication prior to taking any further action.
The server(s) can access real time and historic data sources as shown by database 46, 46′ 46″. Data sources can include user account data, data relating to one or more securities, as well as other on-line information (e.g., accessed via the Internet). The term “security” as used herein is defined in 15 U.S.C. §78c(a)(10) and generally includes “any note, stock, treasury stock, security future, bond, debenture, certificate of interest or participation in any profit-sharing agreement or in any oil, gas, or other mineral royalty or lease, any collateral-trust certificate, preorganization certificate or subscription, transferable share, investment contract, voting-trust certificate, certificate of deposit for a security, any put, call, straddle, option . . . ”.
In this example, the client device 30 (typical PC and web browser) is operable to access the Internet World Wide Web. The client device 30 generally has an associated operating system 48 such as Microsoft Windows or Linux and includes a typical Web Browser 49 such as Microsoft Internet Explorer or the like. The hardware and software configuration of client devices for Internet access is routine and generally known to those skilled in the art.
In the context of securities trading, it is generally known to provide a standard menu based user interface. For example,
a-4c show a command line interface 24 for user initiated transactions as is known in the art. In this example the user can buy, sell, buy to cover (bc), or sell short (ss) by inputting an order string 25 in a specific format In this example, the user wishes to purchase 100 shares of Ameritrade stock at market price. Accordingly, the user inputs the string “buy100amtd”. In the event the user needs additional information, they utilize the menu system and navigate to another screen to request such information. Similarly, if the user wishes to initiate another type of transaction (e.g., mutual funds, options, bonds & CDs . . . ) they again utilize the menu system and navigate to another screen to initiate such transactions.
The invention is accessed via a natural language interface that is integrated into an online trading platform. The natural language interface allows for an input process that is easy and intuitive to use for any level of online investor. Creating a process by which users could find information about securities, buy or sell securities, and project future growth would be an invaluable tool. As such, the invention takes much of the complexity out of online trading and truly opens it up to any level of user.
The invention provides the ability to access the account information of the user initiating the transaction and use that information to narrow the search and return better results. This “tagging” of information assists in the returning of good results in a timely manner. The invention can also be used to either search just the website associated with the on-line trading system or do a broader search on the World Wide Web. If the query is based strictly on the trading system website, the invention uses the individual's account information and history along with whatever stock information is present on the website's database to return the best match. If the query is based strictly on the World Wide Web, the invention will return the best match from information pulled therein. A technical effect of the invention is to provide an improved user interface enabling users to access a plurality of functions from a single input screen. Another technical effect of the invention is to provide an improved user interface that simplifies the input process.
The system generally waits for user input as shown by block 72. Upon receiving user input, the system parses the user input as shown by block 74. The system than makes a preliminary determination as to the general type of user request. The system then executes the applicable code segment or module to carry out the user request. For example the user may input a request in one of the following general categories: buy 81, sell 82, buy to cover 83, sell short 84, options 85, get quote 86, project growth 87, get historical information 88, search the World Wide Web and the like. Each of these requests or transactions are discussed in more detail below.
The format for a natural language input string or query will generally include a plurality of phrases or tokens (separated by spaces, commas or the like). In the case of a Buy/Sell request, the format is generally as follows: Action (e.g., transaction type) . . . Quantity . . . Security . . . Symbol . . . Order Type . . . Price. The input string is not required to be in a particular format or sequence. It is also understood that a subset of tokens may be sufficient to identify certain requests or transactions. For a typical buy or sell transaction “action” generally includes one of the following: Buy, Sell, Buy to Cover, Sell Short. The “Quantity” portion of the query will generally be a numeric input. The “Security” portion of the query generally identifies the type of security at issue (e.g., shares, options . . . ). The “Symbol” portion of the query generally identifies the security at issue (e.g., security name, security symbol). The order type is typically an alphanumeric string (e.g., limit, market, stop market, stop limit, trailing stop %, trailing stop $). The “Price” portion of the query generally is an alphanumeric string.
Assume for example, the user inputs the following string: Buy 100 shares AMTD market.
In a typical implementation, the system may maintain one or more libraries of acceptable tokens in each category (see e.g., blocks 105, 107, 109, 111, 113, 115). For example the Action token library may include the following tokens: Buy, Sell, Buy to Cover, Sell Short, Quote, Project Account Growth, Search and the like. The Quantity token library may include alphabetic representations of certain numbers (e.g., one, hundred, thousand . . . ). The Security token library may include the following tokens: Share, Stock, Bond and the like. The Order Type token library may include the following tokens: Limit, Market, Stop Market, Stop Limit, Trailing Stop %, Trailing Stop $ and the like. The “Other” token library may include other token types that do not fit into any of the categories set out above. The term library as recited herein is used in its general sense (e.g., a collection of information) and does not assume a particular format or structure. It is understood that libraries 105, 107, 109, 111, 113, 115 can be stored locally, remotely or a combination thereof.
Once the input string is parsed, the system will identify any Action tokens (in this example “Buy”) as shown by block 104. Any quantity tokens are identified at block 106 (in this example “100”). Any security tokens are identified at block 108 (in this example “shares”). Any symbol tokens are identified at block 110 (in this example “AMTD”). Any order type tokens are identified at block 112 (in this example “market”). Any other tokens are identified at block 114. Control is passed to block 116 where the system determines whether sufficient information exists to process the request. The system can also access the users account information to assist in interpreting the request as shown by block 118 (discussed in more detail below). In this example, the user has input a string that contains sufficient information to initiate a buy transaction so control is passed to block 122. The system then generates a confirmation screen as depicted by block 124. The user is then prompted to confirm that they wish to execute the trade.
Assume for example, the user inputs the following string: Sell 20 shares Google limit $500. Referring again to
The format for a natural language quote request is generally as follows: Action (optional) . . . Symbol . . . Date (optional). The input string is not required to be in a particular format or sequence. It is also understood that a subset of tokens may be sufficient to identify certain transactions. For a typical quote request “Symbol” generally identifies the security at issue (e.g., security name, security symbol). The “Date” portion of the query (optional) generally can be included so that the results indicate the historical pricing of the security at issue. In the case of a quote request, the user can also include an optional “Action” portion of the query (for example “quote”).
Assume for example, the user inputs the following string: AMTD Dec. 12, 2005. Referring to
Control is passed to block 116 where the system determines whether sufficient information exists to process the request. The system can also access the users account information to assist in interpreting the request as shown by block 118 (discussed in more detail below). In this example, the user has input a string that contains sufficient information to request a quote of AMTD on Dec. 11, 2005. The system then generates a results screen as depicted by block 124.
Assume for example, the user inputs the following string: Quote AMTD. Referring to
Control is passed to block 116 where the system determines whether sufficient information exists to process the request. The system can also access the users account information to assist in interpreting the request as shown by block 118 (discussed in more detail below). In this example, the user has input a string that contains sufficient information to request a current quote of the pricing of AMTD. The system then generates a results screen as depicted by block 124.
The foregoing examples provide user access to features that have corresponding menu entries in an existing on-line trading platform. The invention is advantageous in that the user can access a variety of functions from a single interface, without the need to traverse various menu levels and the like However, the invention can also provide access to features that do not have corresponding menu entries in an existing on-line trading platform. This allows for the introduction of new features without modifying the existing menu structure and can speed feature introduction.
For example, the invention can provide access to research or analysis tools. One useful tool provides projected account growth based on certain assumptions about future returns. The format for such a natural language request is generally as follows: Action . . . Yield . . . Years/Date. The input string is not required to be in a particular format or sequence. It is also understood that a subset of tokens may be sufficient to identify certain transactions. For a typical account projection request the “Action” token is generally: Project account growth. The “Yield” portion of the request will generally be a numeric input such as (10%) or an alphabetic input to identify a particular index to be used in the projection (e.g., Dow). The “Years/Date” portion of the request is generally a numeric input and identifies the number of years to carry out the projection (e.g., 10). If just one year is specified, the system will carry out the projection from the current date through the year specified.
Assume for example, the user inputs the following string: Project account growth 10% 2015. Referring to
Control is passed to block 116 where the system determines whether sufficient information exists to process the request. The system can also access the users account information to assist in interpreting the request as shown by block 118. In this example, the user has input a string that contains sufficient information to request an account growth projection (for current securities owned by the user) with a 10% yield from the current date through the last day of 2015. The system utilizes the users account information and identifies the user's account balance. Assume for this example, the users account balance on Jan. 1, 2007=$10,000. The system then carries out one or more future value calculations. For example, the system can utilize the following formula: fv=p(1+r)n, where: fv=future value, p=starting principal, r=rate and n=number of years. The system then generates a results screen as depicted by block 124.
Assume for example, the user inputs the following string: Compare the DOW to the Russell 2000 from 2004-2006. Referring to
Control is passed to block 116 where the system determines whether sufficient information exists to process the request. The system can also access the users account information to assist in interpreting the request as shown by block 118. In this example, the user has input a string that contains sufficient information to request a comparison of the DOW and Russell 2000 indexes from 2004 though 2006. The system generates a results screen as depicted by block 124.
The foregoing examples generally provide a user with information derived primarily from the on-line trading system's database 46, 46′ and 46″. However, the system can also initiate a web search and return the search results to the user. For example, if the system is unable to locate an action token or otherwise discern a specific user request, the system can initiate a web search and return the results to the user.
Assume for example, the user inputs the following string: China trade deficit. Referring to
In the foregoing examples, the results screens 130, 150, 170, 180, 200, 220 and 240 are shown as separate screens. It is understood that the results can be integrated with or otherwise included in the natural language interface 60 (e.g., within message portion 64). It is also understood that a variety of results, with varying levels of detail, can be provided without departing from the scope of the invention Although the examples above show only text based input, the system can be configured with a speech recognition module and can accept audio based natural language requests without departing from the scope of the invention. While the foregoing description and drawings represent the preferred embodiments of the present invention, it will be understood that various changes and modifications may be made without departing from the scope of the present invention.