Electronic Trading System

• US 20070198397A1
• Filed: 08/25/2006
• Published: 08/23/2007
• Est. Priority Date: 02/25/2004
• Status: Abandoned Application

• Current Assignee: Patsystems PLC
• Original Assignee: Patsystems PLC
• Inventors: GREAVES, Ian, MCGINLEY, John
• Application Number:
  US11/467,227
• Publication Number:
  US 20070198397A1
• Time in Patent Office: Days
• US Class Current: 705/37
• CPC Class Codes: G06Q 40/04 Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
• CPC Class Codes: H04L 2012/5632 Bandwidth allocation
• CPC Class Codes: H04L 2012/5636 Monitoring or policing, e.g. compliance with allocated rate, corrective actions
• CPC Class Codes: H04L 2012/5651 Priority, marking, classes
• CPC Class Codes: H04L 45/10 Routing in connection-oriented networks, e.g. X.25 or ATM
• CPC Class Codes: H04L 47/10 Flow control; Congestion control
• CPC Class Codes: H04L 47/11 Identifying congestion
• CPC Class Codes: H04L 47/36 by determining packet size, e.g. maximum transfer unit [MTU]

Abstract

An electronic trading system is disclosed for principally for trading in intangible things, particularly financial instruments. The trading system comprising a quality-of-service (QoS) subsystem, which subsystem is operative to impose limitations upon trading activities in order that the performance of a component of the system or of the system as a while is maintained within specified tolerances. For example, it may limit the number of events that can be initiated by a trader. It may also allow some messages to be routed through the system with a priority that is higher than others when such messages have a particular content (e.g. are inherently urgent in nature or essential to proper operation of the system) or are to or from a privileged user. The system also has an integrated protocol stack for routing of data to enable the location of data bottlenecks to be identified.

Claims

1. An electronic trading system comprising a multi-level quality-of-service (QoS) subsystem, which subsystem is operative to impose limitations upon the initiation of electronic trading activities in order that the performance of a component of the system or of the system as a whole is maintained within specified tolerances.

2. A trading system according to claim 1 in which the QoS subsystem imposes a limit upon the rate at which data can enter the system.

3. A trading system according to claim 2 in which the QoS subsystem limits the number of requests that will be accepted on an input.

4. A trading system according to claim 3 in which the QoS subsystem controls the number of requests that can be made in a time slice.

5. A trading system according to claim 1 which the QoS subsystem imposes a limit on the size of burst data that may be received into the system in a time slice.

6. A trading system according to claim 1 in which the token bucket algorithm is used in order to limit the flow of requests into the system.

7. A trading system according to claim 6 in which the time slice is a sliding time slice.

8. A trading system according to claim 1 in which the QoS subsystem operates such that the system provides a level of service that is dependent upon the identity of a user from which the service originates or to whom it is directed.

9. A trading system according to claim 1 in which the QoS subsystem operates such that the system provides a level of service that is dependent upon the nature of a service that is requested.

10. A trading system according to claim 1 in which the QoS subsystem is operative to measure its performance and dynamically reconfigure operation of the system based on these measurements to ensure a defined level of quality of service.

11. A trading system according to claim 1 in which the QoS subsystem is operative to increase restrictions on users'"'"' access to the system as its load exceeds a predefined limit.

12. A trading system according to claim 1 in which the QoS subsystem is operative to assign a priority to a message, messages with a high priority being handled in preference to those with a low priority.

13. A trading system according to claim 12 in which the priority is determined in accordance with one or more of the sender of the message, the recipient of the message or the content of the message.

14. A trading system according to claim 12 in which the priority is a numerical value that is calculated by addition of contributed values derived from one or more of the sender of the message, the recipient of the message or the content of the message.

15. A trading system according to claim 1 in which the QoS subsystem is operative to control latency and accuracy of communication of data from the trading system to external client applications.

16. A trading system according to claim 15 in which the client application may request that the data is sent as fast as possible or that data batching may be applied.

17. A trading system according to claim 15 in which the client application may request that all data changes during a period are to be reported or that only the latest data be reported.

18. A trading system according to claim 1 in which the QoS subsystem monitors performance of the application by way of Java management extensions.

19. A trading system according to claim 1 that utilises a rule-based system to control alarm reporting, fault diagnosis and reconfiguration.

20. A computer software product executable upon a computer hardware platform to perform as an electronic trading system comprising a multi-level quality-of-service (QoS) subsystem, which subsystem is operative to impose limitations upon the initiation of electronic trading activities in order that the performance of a component of the system or of the system as a whole is maintained within specified tolerances.

21. A server in a network of trading computers comprising a computer hardware platform executing a computer software product to perform as an electronic trading system comprising a multi-level quality-of-service (QoS) subsystem, which subsystem is operative to impose limitations upon the initiation of electronic trading activities in order that the performance of a component of the system or of the system as a whole is maintained within specified tolerances.

22. A method of operating an electronic trading system that comprises a quality-of-service (QoS) subsystem, which subsystem imposes limitations upon initiation of trading activities in order that the performance of a component of the system or of the system as a whole is maintained within specified tolerances.

23. A method according to claim 22 in which the QoS subsystem imposes a limit upon the rate at which data can enter the system.

24. A method according to claim 23 in which the QoS subsystem limits the number of requests that will be accepted on an input.

25. A method according to claim 24 in which the QoS subsystem controls the number of requests that can be made in a time slice.

26. A method according to claim 22 in which the QoS subsystem imposes a limit on the size of burst data that may be received into the system in a time slice.

27. A method according to claim 22 in which the token bucket algorithm operates to limit the flow of requests into the system.

28. A method according to claim 27 in which the time slice is a sliding time slice.

29. A method according to claim 22 which the QoS subsystem operates such that the system provides a level of service that is dependent upon the identity of a user from which the service originates or to whom it is directed.

30. A method according to claim 22 in which the QoS subsystem operates such that the system provides a level of service that is dependent upon the nature of a service that is requested.

31. A method according to claim 22 in which the QoS subsystem operates to measure its performance and dynamically reconfigure operation of the system based on these measurements to ensure a defined level of quality-of service.

32. A method according to claim 22 in which the QoS subsystem operates to increase restrictions on users'"'"' access to the system as its load exceeds a predefined limit.

33. A method according to claim 22 in which the QoS subsystem operates to assign a priority to a message, messages with a high priority being handled in preference to those with a low priority.

34. A method according to claim 33 in which the priority is determined in accordance with one or more of the sender of the message, the recipient of the message or the content of the message.

35. A method according to claim 33 in which the priority is a numerical value that is calculated by addition of contributed values derived from one or more of the sender of the message, the recipient of the message or the content of the message.

36. A method according claim 22 in which the QoS subsystem control latency and accuracy of communication of data from the trading system to external client applications.

37. A method according to claim 36 in which the client application may request that the data is sent as fast as possible or that data batching may be applied.

38. A method according to claim 36 in which the client application may request that all data changes during a period are to be reported or that only the latest data be reported.

39. A method according to claim 22 in which the QoS subsystem monitors performance of the application by way of Java management extensions.

40. A method according to claim 22 that utilises a rule-based system to control alarm reporting, fault diagnosis and reconfiguration.