System and Method for the Automated Brokerage of Financial Instruments

• US 20090182656A1
• Filed: 03/26/2009
• Published: 07/16/2009
• Est. Priority Date: 10/22/2003
• Status: Active Grant

• Current Assignee: Scottrade Incorporated (Charles Schwab Corporation)
• Original Assignee: Scottrade Incorporated (Charles Schwab Corporation)
• Inventors: Tully, Michael James, Scott, Virgil Michael
• Granted Patent: US 8,170,940 B2
• Time in Patent Office: Days
• US Class Current: 705/35
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes
• CPC Class Codes: G06Q 40/04 Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
• CPC Class Codes: G06Q 40/06 Asset management; Financial planning or analysis

Abstract

Disclosed herein in a preferred embodiment is an automated financial instrument brokerage system wherein a front end layer interacts with customers to generate activity requests for an intermediate layer. The intermediate layer preferably processes the activity requests and places financial instrument orders on a financial market if appropriate. A backend layer preferably provides data to the intermediate layer for processing activity requests. Multiple heterogeneous front end customer applications may be supported by the same intermediate layer. Further, multiple backend layer applications may interact with the intermediate layer in a manner transparent to the front end layer. Further, scalability can be achieved be partitioning various tasks of the intermediate layer onto separate servers, and more preferably on separate redundant servers. Load balancers may then be used in the intermediate layer to provide distributed access to these servers. Also disclosed herein is a caching technique whereby turnaround time for processing activity requests can be reduced by reducing the number of times that the intermediate layer needs to interact with the backend layer.

Claims

1. In an automated financial instrument brokerage system comprising a backend database for storing customer account data and a server for processing activity requests received from a user, wherein at least some of the activity requests need customer account data for processing, a method comprising:

maintaining a memory that is resident in the server;

storing customer account data retrieved from the backend database in the resident memory; and

determining, according to predetermined usage rules, whether to use the customer account data stored in the resident memory when processing activity requests.

2. The method of claim 1 wherein the resident memory is an application-in-memory cache.

3. The method of claim 2 further comprising:

if the determining step results in a determination to use the customer account data stored in the cache memory when processing an activity request, processing that activity request using the customer account data stored in the cache memory; and

if the determining step results in a determination to not use the customer account data stored in the cache memory when processing an activity request, processing that activity request using the customer account data stored in the backend database.

4. The method of claim 3 wherein the storing step comprises:

storing customer account data in the cache memory for a limited duration after that data has been retrieved from the backend database.

5. The method of claim 3 wherein the activity request is a request by a user to purchase a financial instrument, wherein the purchase is conditional on there being sufficient buying power stored in a customer account associated with the purchase request.

6. The method of claim 3 wherein the activity request is a request by a user to view a balance for a customer'"'"'s customer account.

7. The method of claim 3 wherein the activity request is a request by a user to sell a financial instrument, wherein the sale is conditional on data in a customer account associated with the sale request.

8. The method of claim 3 wherein the activity request is a request from another server in the system that needs customer account data in order to process an order activity request related to a customer account.

9. The method of claim 3 wherein the predetermined usage rules include a rule that the customer account data stored in the cache memory is not to be used when processing an activity request if that customer account data has been stored in the cache memory for longer than a predetermined length of time.

10. The method of claim 9 wherein the predetermined length of time is approximately five minutes.

11. The method of claim 3 wherein the predetermined usage rules include a rule that the customer account data stored in the cache memory is not to be used when processing an activity request if that customer account data has already been used a predetermined number of times when processing previous activity requests.

12. The method of claim 3 wherein the predetermined usage rules include a rule that customer account data stored in the cache memory is not to be used when processing an activity request if an account event has occurred in connection with that customer account since the time that the customer account data was stored in the cache memory.

13. The method of claim 12 wherein the account event is any from the group consisting of:

an order associated with that customer account to purchase or sell a financial instrument;

a modification of an order associated with that customer account to purchase or sell a financial instrument;

a cancellation of an order associated with that customer account to purchase or sell a financial instrument; and

an execution of an order associated with that customer account to purchase or sell a financial instrument.

14. A computer-readable medium for determining whether to process an activity request in an automated financial instrument brokerage system in accordance with customer account data stored in a memory resident on a system server or with customer account data stored in a system backend database, the computer-readable medium comprising:

computer code executable by a processor for determining if a customer associated with an activity request has customer account data stored in the resident memory;

computer code executable by a processor for determining, if the customer associated with the activity request does have customer account data stored in the resident memory, whether to use the customer account data stored in the resident memory when processing the activity request, wherein the usage determination is made in accordance with a plurality of predetermined usage rules.

15. The computer-readable medium of claim 14 wherein the resident memory is an application-in-memory cache.

16. The computer-readable medium of claim 15 wherein the usage rules include a rule that the customer account data stored in the cache memory is not to be used when processing an activity request if that customer account data has been stored in the cache memory for longer than a predetermined length of time.

17. The computer-readable medium of claim 15 wherein the predetermined usage rules include a rule that the customer account data stored in the cache memory is not to be used when processing an activity request if that customer account data has already been used a predetermined number of times when processing previous activity requests.

18. The computer-readable medium of claim 15 wherein the predetermined usage rules include a rule that customer account data stored in the cache memory is not to be used when processing an activity request if an account event has occurred in connection with that customer account since the time that the customer account data was stored in the cache memory.