System and method for the automated brokerage of financial instruments

• US 8,170,940 B2
• Filed: 03/26/2009
• Issued: 05/01/2012
• 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
• Primary Examiner(s): JOHNSON, GREGORY L
• Application Number:
  US12/412,175
• Publication Number:
  US 20090182656A1
• Time in Patent Office: 1,132 Days
• Field of Search: None
• US Class Current: 705/36.R
• 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. A method comprising:

processing by a server a plurality of activity requests from a user, the server residing in a multi-tier automated financial instrument brokerage system, the brokerage system further comprising a backend database in a separate tier from the server for storing customer account data, wherein processing at least some of the activity requests uses customer account data retrieved from the backend database;

maintaining an application-in-memory cache that is resident in the server;

storing customer account data retrieved from the backend database in the application-in-memory cache of the server;

determining, according to a plurality of predetermined usage rules, whether to use the customer account data stored in the application-in-memory cache of the server instead of the customer account data retrieved from the backend database when processing activity requests; and

refreshing the customer account data stored in the application-in-memory cache in response to a multicast packet, wherein the multicast packet is provided upon acknowledgement of a financial transaction.

2. The method of claim 1 wherein the processing step comprises:

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

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

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

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

4. The method of claim 1 wherein at least one of the activity requests is a request by the 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.

5. The method of claim 1 wherein at least one of the activity requests is a request by the user to view a balance for a customer'"'"'s customer account.

6. The method of claim 1 wherein at least one of the activity requests is a request by the user to sell a financial instrument, wherein the sale is conditional on data in a customer account associated with the sale request.

7. The method of claim 1 wherein at least one of the activity requests is a request from another server in the system that uses the customer account data to process an order activity request related to a customer account.

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

9. The method of claim 1 wherein the predetermined usage rules include a rule that the customer account data stored in the application-in-memory cache 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.

10. The method of claim 1 wherein the predetermined usage rules include a rule that customer account data stored in the application-in-memory cache 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 application-in-memory cache.

11. The method of claim 10 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.

12. The method of claim 10 wherein the account event comprises an order associated with that customer account to purchase or sell a financial instrument.

13. The method of claim 10 wherein the account event comprises a modification of an order associated with that customer account to purchase or sell a financial instrument.

14. The method of claim 10 wherein the account event comprises a cancellation of an order associated with that customer account to purchase or sell a financial instrument.

15. The method of claim 10 wherein the account event comprises an execution of an order associated with that customer account to purchase or sell a financial instrument.

16. An apparatus comprising:

an automated financial instrument brokerage system having a plurality of tiers, wherein each tier includes at least one server dedicated to a particular task, the brokerage system comprising (1) a front end server for processing a plurality of heterogeneous activity requests received over an internet from a remote user, (2) a backend database located in a backend tier for storing customer account data, and (3) an application-in-memory cache that is resident in at least one server located in an intermediate tier, wherein at least some of the activity requests need customer account data for processing;

wherein the intermediate tier server is configured to (1) store customer account data retrieved from the backend database in the application-in-memory cache, (2) determine, according to a plurality of predetermined usage rules, whether to use the customer account data stored in the application-in-memory cache of the intermediate tier server instead of the customer account data retrieved from the backend database when processing activity requests, and (3) update the customer account data stored in the application-in-memory cache in response to a multicast packet, wherein the multicast packet is provided upon acknowledgement of a financial transaction.

17. The apparatus of claim 16 wherein in response to a determination to use the customer account data stored in the application-in-memory cache when processing an activity request, that activity request is processed using the customer account data stored in the application-in-memory cache, and in response to a determination to not use the customer account data stored in the application-in-memory cache when processing an activity request, that activity request is processed using the customer account data stored in the backend database.

18. The apparatus of claim 17 wherein the intermediate tier server is further configured to store customer account data in the application-in-memory cache for a limited duration after that data has been retrieved from the backend database.

19. The apparatus of claim 17 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 associate with the purchase request.

20. The apparatus of claim 17 wherein the activity request is a request by a user to view a balance for a customer'"'"'s customer account.

21. The apparatus of claim 17 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.

22. The apparatus of claim 17 wherein the activity request is a request from another server in the system that uses the customer account data to process an order activity request related to a customer account.

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

24. The apparatus of claim 17 wherein the predetermined usage rules include a rule that the customer account data stored in the application-in-memory cache 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.

25. The apparatus of claim 17 wherein the predetermined usage rules include a rule that customer account data stored in the application-in-memory cache 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 application-in-memory cache.

26. The apparatus of claim 25 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.

27. The apparatus of claim 25 wherein the account event comprises an order associated with that customer account to purchase or sell a financial instrument.

28. The apparatus of claim 25 wherein the account event comprises a modification of an order associated with that customer account to purchase or sell a financial instrument.

29. The apparatus of claim 25 wherein the account event comprises a cancellation of an order associated with that customer account to purchase or sell a financial instrument.

30. The apparatus of claim 25 wherein the account event comprises an execution of an order associated with that customer account to purchase or sell a financial instrument.

31. The apparatus of claim 16 further comprising a database located in the intermediate tier and wherein the intermediate tier server is further configured to store customer account data retrieved from the intermediate database in the application-in-memory cache.