BACKGROUND OF THE INVENTION Stock market securities (which are represented by symbols) are traded all over the world. It is common to apply mathematical formula or other types of logic to market data in order to attempt to predict the future price of a security. The purpose of such attempts is, generally, to determine whether to buy or sell a security. In recent years, many people involved in trading securities have programmed computers to monitor market data and generate buy or sell signals if their own formula or logic would yield such a result.

The term"trade"as used herein will refer to a transaction wherein a specific volume of a particular security is purchased or sold for a given unit price.

The term"market event"as used herein will refer to events related to the bidding for, and trading of securities. A market event can be a bid, an ask or a

trade. Every market event relates to a security, and has an associated price and volume.

The term"market data"as used herein will refer to the historic data relating to market events. Raw market data must identify at least the security involved, the time of the event, the type of the event (i. e., bid, ask or trade), and the price and volume. A market event may occur at any time, subject, of course, to any limitations imposed upon trading that security by law or by other rules, such as the rules of an exchange. Similarly, raw market data reporting that event may be generated and transmitted at any time subsequent to the event.

Although it may be desirable to obtain raw market data as close to the time of the event as possible, the raw market data reflecting an event needs to be coded and then transmitted electronically. Once the raw market data is transmitted, a number of factors determine when that data is received. As is well known, network congestion or other factors can delay the receipt of data.

The term"trade data"as used herein will refer to the market data related only to trades, and not to market data related to bids or asks.

The term"trading system"as used herein will refer to a mathematical formula and/or logic that accepts market data as an input and, determines whether to generate a signal, such as a buy signal or a sell signal. In addition to market data, trading systems usually accept other inputs, such as, fixed parameters and/or processed

market data; the latter could, for example be output from another trading system. Almost all trading systems can output a buy signal and a sell signal; moreover, most trading systems can output a number of other quantities- quantities, for example, that can be used as input to a later execution of the same trading system, or that can be used as input to other trading systems. In its simplest form, a trading system could generate a buy signal if the price of a security falls below a set price and generate a sell signal if the price of that security exceeds another price. More often, a trading system relies upon the trade data subset of market data, and most trading systems require more trade data than the price of the last trade of that security.

Most trading systems do not use raw market data as input, but instead, require market data aggregated over a unit of time, also referred to herein as"interval data"or "unit data."Although any unit of time could be used, frequently used interval periods include: minute data, two-minute data, five-minute data, ten-minute data, fifteen-minute data, half-hour data, hour data and daily data.

It is well know to collect and aggregate raw market data into interval data. Today, interval data is available from many commercial sources. The aggregator of such information often transmits interval data to its customers on a subscription basis. Although interval data is computed for all of the transactions that occurred in a specific time period, a number of factors determine when the interval data is actually transmitted

and received. For example, any delay in receiving or aggregating the raw market data can cause a corresponding or even disproportionate delay in the transmission of interval data, and often, network congestion can delay its receipt.

Ideally, a trading system analyses data promptly after the relevant market data becomes available. Due to the unpredictable delay involved in receiving market data it is problematic to synchronise the execution of a trading system to the availability of the relevant market data.

Accordingly, when needed, trading systems are run continuously. This approach is wasteful of computer resources. Moreover, in an environment where numerous trading systems need to be run, memory and processor resources are rapidly exhausted. Despite the inefficiency, such a procedure is used due to the simplicity of its implementation, but it results in a relatively limited number of trading systems which may be executed on a computer, due primarily to computer resources and economic considerations.

Making the problem more complex, many trading systems are run with varying parameters. Take, for example, a simple trading system TS1 that, for a given security, generates a buy signal when the line representing an x day moving average crosses above the line representing a y day moving average, and generates a sell signal when the line representing the x day moving average crosses below the line representing the y day moving average. The parameters to the trading system are x and y. While one person may be interested in the results of TS1 for Intel

Corporation, with a three day moving average and a seven day moving average, another person may be interested in the results of TS1 for Intel Corporation, with a ten day moving average and a 100 day moving average.

Accordingly, even with the storage and processing power of today's computers, it is an enormous problem to operate a large number of trading systems, each having numerous parameter sets, on each of a number of securities, at all of the intervals that may be desired.

SUMMARY OF THE INVENTION It is an object of the present invention to provide a method and apparatus for efficiently operating a plurality of trading systems.

It is another object of the present invention to provide a method of fulfilling two or more periodic trading system requests, each of the trading system requests being associated with a data interval, a trading system, and an identifier representing a security, comprising the steps of: compiling a list of the trading system requests for each data interval contained in any of the two or more trading system requests; scheduling the lists for review after the associated data interval has elapsed; successively selecting the list scheduled for review at the present time having the smallest data interval associated therewith, and for that list, invoking the trading system associated with the trading system requests in connection with the identifier representing a security.

It is yet another object of the invention to provide an apparatus for fulfilling two or more periodic trading system requests, each of the trading system requests being associated with a data interval, a trading system, and an identifier representing a security, comprising the steps of: master data server for receiving raw market data and producing interval data therefrom, the master data server being adapted to transmit interval data relating to a security during a given time in response to a request therefore; client data server for receiving interval data for a security over a given time from the master data server, and adapted to provide aggregate interval data relating to integer multiples of the time period represented by the interval data; trading system scheduler for invoking enhanced trading systems at predetermined times, the trading system scheduler also for maintaining a last completion time for each of the two or more trading system requests; enhanced trading systems for requesting aggregate interval data necessary to run one of the trading systems associated with the two or more trading system requests, and for providing the aggregate interval data to the trading system; a trading system for initiating a buy or sell signal based upon the aggregate interval data supplied; and a customer notification module for notifying a customer of a buy or sell signal.

It is a further object of the invention to provide a novel method of notifying customers of a buy or sell signal, namely, via email.

It is a further object of the invention to provide a novel method of including data leading to the occurrence of a buy or sell signal in the notification of the buy or sell signal sent to the customer.

It is a further object of the invention to provide a method of charging customers for the operation of the customers trading system by billing the customer for each buy and/or sell signal generated by the trading system.

It is yet a further object of the invention to provide a method of charging customers for signals generated in connection with the execution of a trading system request on a security, comprising: scheduling the execution of the trading system at a predetermined time; retrieve the interval data related to the security required for the operation of the trading system at the predetermined time; executing the trading system on the retrieved interval data; determining whether the trading system generated a signal, and if so, notifying the customer; sending an indication that the customer has been notified to an accounting system; using the accounting system, creating a bill for the customer charging the customer for each notification sent to the customer; and sending the bill to the customer.

It is another object of this invention to provide a method of operating a first trading system that requires a first set of interval data and at least one output of a second trading system as input thereto, the second trading system requiring a second set of interval data as input, the method comprising: inspecting the first

trading system to determine the first set of intervals for which interval data is required as input to the first trading system; inspecting the second trading system to determine the second set of interval for which interval data is required to operate the second trading system; computing a third set of intervals as the union of the first set of intervals and the second set of ; obtaining the interval data corresponding to the third set of intervals and subsequently, passing to the second trading system the interval data corresponding to the second set of intervals, and operating the second trading system; and passing to the first trading system the interval data corresponding to the first set of intervals, and at least one output of the second trading system, and operating the first trading system.

It is another object of this invention to provide a method of operating a trading system which is based upon data corresponding to a first time-series, the trading system requiring for operation at least a portion of the output of the same trading system based upon data corresponding to a second time-series, the method comprising: obtaining the interval data corresponding to the first time-series and the second time-series; running the trading system based upon the interval data corresponding to the second time-series and generating a trading system output; running the trading system based upon the first time-series of data and at least a portion of the trading system output.

It is another object of this invention to provide a method of operating a trading system, the output of which

is based upon a first data set, and requires for its operation at least a portion of the output of a plurality of other trading systems, the method comprising: inspecting the first trading system to determine the other trading systems for which output is required for the operation of the first trading system; successively inspecting the other trading systems to determine any additional other trading systems for which output is required for the operation of the other trading systems; determining the data set representing the union of the data sets required for the operation of the first trading system and the other trading systems; obtaining the required data set, and subsequently: operating such other trading systems and retaining the output of such other trading systems as is required for the operation of any of the other trading systems or for the first trading system; and operating the first trading system, and supplying thereto the required output.

It is another object of this invention to provide a method of operating a trading system, the trading system requiring parameters and interval data as an input, the method comprising the steps of: obtaining the parameters required by the trading system; inspecting the trading system and the parameters to determine the minimum set of data required to operate the trading system with according to the parameters; obtaining the minimum set of data; and operating the trading system in connection with the parameters and the obtained minimum set of data.

These and other objects, features and advantages of the present invention will become more evident from the following discussion and examples.

BRIEF DESCRIPTION OF THE DRAWINS Figure 1 is a schematic representation of an apparatus that may be used for carrying out the present invention.

DETAILED DESCRIPTION OF THE INVENTION The present invention provides a method and apparatus for implementing multiple trading systems with varying parameter sets to operate on a plurality of securities.

Turning first to Figure 1, a master data server 1 is provided. The master data server 1 receives data from one or more sources 2,3, such as stock exchanges. The master data server 1 the stores the data or a derivative of the data on storage device 4.

In a preferred embodiment, the master data server 1 receives at least trade data from the sources 2,3, and from the trade data, aggregates and stores interval data on a master storage device 4. For each security, the interval data stored on the master storage device 4.

Interval data may contain any data related to a security during the interval, and typically includes the minimum price, the maximum price, the opening price, the closing price and the total volume of the trades, (hereafter "MMOCV data"for Minimum, Maximum, Opening, Closing and Volume). For efficiency, in a preferred embodiment, if a

security did not trade during the interval, no data is recorded for that interval for that security.

Although the basic time interval may be any unit of time, preferably, the basic time interval will be one minute; thus, the interval data will be minute data. The result of storing minute data, however, necessarily limits the remainder of the system, including the trading systems, to operating on data having resolution no finer than one minute. While it is believed that minute data is generally acceptable for modern trading systems, it is within the scope of the invention to increase or decrease the basic time interval depending on the needs of the individual trading systems that will require data and the economics of storing and processing the data.

The master data server 1 can additionally create MMOCV data for other units. Preferably, the master data server 1 creates and stores both minute data and daily data for each security. It is also possible, however, to create, for example, 5-minute data and store such data on the master storage device 4. Although inventor believes that, in actual operation, it will be more efficient for a generalised system to store only the minute and daily data, and to derive other data units on an ad hoc basis, it is within the scope of the invention to create and store only the interval data for the minimum interval, or to create and store additional MMOCV data; namely, interval data based on an interval other than the basic unit employed by the system.

A client data server 5 is also provided. The client data server 5 may have access to the master storage device 4 (not shown), however, in a preferred embodiment the master data server 1 sends MMOCV data to the client data server 5, and the client data server stores the received data on a client storage device 6. The master data server 1 sends MMOCV data to the client data server 5 as requested by the client data server 5. There are two main types of requests, a subscription data request, and a historical data request.

A client data server 5 may send to the master data server 1 a request for information about a security called a subscription. Once a client data server 5 has sent such a request to the master data server 1, the master data server 1 will transmit MMOCV data relating to that security to the client data server 5. In a preferred embodiment, the master data server 1 will transmit the MMOCV minute data and the MMOCV daily data to the client data server 5 at regular intervals specified by the subscription, after the close of the relevant market.

After receiving the data subscription, the master data server 1 will provide the subscribed data to the client data server 5 at the subscription interval until the client data server 5 cancels the subscription.

A client data server 5 may also send to the master data server 1 a request for information referred to herein as a historical data request. In this case interval data for a security over a given period is requested. For example, a data request may request minute data for a particular security during a particular fifteen minute

period earlier the same day. Although it is within the scope of the invention to permit the client data server 5 to request, for example five-minute data over the earlier fifteen minute period, the inventor believes that it is more efficient to provide that the requests are limited to the basic unit of data maintained by the master data sever 1 on the master storage device 4.

A trading system scheduler 7 and a plurality of enhanced trading systems 8-10 are also provided. Enhanced trading systems 8-10 each comprise trading systems 8a-10a.

Although Figure 1 shows only three enhanced trading systems 8-10, it is within the scope of the invention to have any number of enhanced trading systems, limited only by computer resources.

As discussed above, a trading system is mathematical formula and/or logic that accepts market data, processed market data and/or other parameters as input, and which may generate data representing a buy or sell signal, among other things, as output. A person that is interested in the buy or sell signal of a particular trading system wants the trading system to be run at some given interval, based upon some predetermined parameters, with respect to a particular security. Thus, as used herein"trading system request"refers to a request that a particular trading system be run with a particular set of parameters on data having a particular interval.

Accordingly, the trading system scheduler 7 maintains a list of the trading system requests that it must schedule, and for each, maintains the last interval for which the trading system request successfully ran. Since

multiple customers may make the same trading system request and there is no reasons to run the same trading system request more than once for a given interval, the trading system scheduler 7 maintains the list of customers that are interested in the results of the particular trading system request.

Consider the following example. Table 1 shows 11 trading system requests received from three different customers, relating to two different trading systems and three different securities. For simplicity, all of the trading system requests relate to daily data.

# Customer System Parameters Security Interval 1 Cl TS1 4,3 INTC daily 2 Cl TS1 3,7 INTC daily 3 C1 TS1 4,3 AMAT daily 4 Cl TS2 4,6,8 IBM daily 5 C2 TS1 4,3 INTC daily 6 C2 TS1 3,7 INTC daily 7 C2 TS2 4,7,9 IBM daily 8 C3 TS1 3,7 INTC daily 9 C3 TS1 4,3 AMAT daily 10 C3 TS2 4,6,8 AMAT daily 11 C3 TS2 4,6,8 IBM daily TABLE 1 Upon receiving these requests, in a preferred embodiment, the scheduler 7 would reorganise the requests and store them in its table of daily trading system requests: # System Parameters Security Last Customer 1 TS1 4,3 INTC Cl, C2 2 TS1 3,7 INTC Cl, C2, C3

3 TS1 4,3 AMAT Cl, C3 4 TS2 4,6,8 IBM Cl, C3 5 TS2 4,7,9 IBM C2 6 TS2 4,6,8 AMAT C3 TABLE 2 While the precise order of the trading system requests in Table 2 is less important, note that the redundant operations of the trading systems, namely where they were running for different customers on the same data, have been eliminated. Although the order is generally unimportant within the records of Table 2, it is important to note that all of the Table 2 trading system requests relate to daily data. In a preferred embodiment, the trading system requests relating to the smallest intervals are given priority over trading system requests for larger intervals. In other words, all trading system requests related to minute data will be performed ahead of any that relate to five minute data; similarly all of the five minute data executions should be completed before dealing with 10 or 20 minute data, or daily data, trading system requests.

In a preferred embodiment, the scheduler 7 maintains separate lists of enhanced trading systems based upon the frequency of operation, e. g., daily. In other words, the scheduler 7 would maintain a list of trading systems that would require invocation every minute, another list of trading systems that would require invocation every 5 minutes, and another for the enhanced trading systems that run daily, etc.

The scheduler 7 then invokes each of the enhanced trading systems 8-10, as appropriate to invoke trading systems 8a-10a. When the scheduler 7 invokes the enhanced trading system 8-10, it passes to the enhanced trading system 8-10 certain parameters and/or other variables.

The invocation of tasks by a scheduler is well know, as is the passing of variables to the tasks invoked.

In a preferred embodiment, the variables passed by the trading system scheduler 7 to the enhanced trading systems 8-10 including the period for which the trading system 8a-10a are to run. The period may be passed as a start and end time/date. In a simplified case, the end time/date is obtained by adding the interval period to the time/date of the last successful run, which is maintained by the trading system scheduler.

When called, the enhanced trading systems 8-10 determines what interval data is required for operation of the trading systems 8a-10a, respectively. The determination is made by reference to the start and end time/date passed thereto by the scheduler 7 and to the trading systems 8a-10a themselves. Once the required interval data is determined, the enhanced trading systems 8-10 request the required interval data.

In the case, for example, of a daily trading system 8a- l0a computing a five day moving average, the enhanced trading system 8-10 would determine that the required interval data runs from four days before the start date, through the end date. In the simplest case, where the daily trading system has successfully run on the

preceding day, the start date and end date passed to the enhanced trading system 8-10 will be equal, and only the preceding four days data (and the current days data) are required to compute the moving average.

In one embodiment, the request for the interval data can be made by the enhanced trading systems 8-10 to the trading system scheduler 7; in another embodiment, the request is made by the enhanced trading systems 8-10 directly to the client data server 5. In the former case, the scheduler then makes the request to the client data server 5. If the client data server 5 can fulfil the request from the data stored on client storage device 6, whether or not some aggregation of data is required, it does so. If the client data server 5 cannot fulfil the request from the data stored on client storage device 6, it makes a data request to the master data server 1.

The master data server 1 then fulfils the data request to the client data server 5 as described above.

In either event, if the required interval data is not available, the execution of the enhanced trading system 8-10 is rescheduled for a later time. In a preferred embodiment, the execution of the enhanced trading system 8-10 is rescheduled to await the attempted execution of the trading system requests for the same interval class (i. e., minute data). If there is any way to know when the data is reasonably expected to be available at the client data server, the execution of the enhanced trading system 8-10 can be rescheduled to run at that time.

As discussed above, one of the novel features of the present invention is the ability of an enhanced trading system 8-10 to determine the data that is required for the execution of the related trading system 8a-10a. The enhanced trading system 8-10 can determine the time- series data required to execute the trading system 8a-10a for a present time, as well as for a prior time. The time-series data required to execute the trading system 8a-10a is dependent on the history"length"that is required by a particular trading system. History "length"is the number of consecutive intervals backwards in time from a given time that are required in order to calculate the output values for the trading system at the given time.

The history"length"can and are determined in several ways.

In a preferred embodiment, the enhanced trading system 8- 10 automatically analyses the logic of the trading system 8a-10a and determines from such logic the history "length"that is applicable to the trading system 8a-10a.

This determination is made by finding the largest time unit contained in the logic of the trading system 8a-10a (in other words, the distance from the given time to the oldest data point required by the trading system 8a-10a), and using that as the"length". In another embodiment, the user override the programmed logic and input a value for the"length".

Alternatively, the user can input an expression, in terms of the parameters of the trading system 8a-10a, that is

evaluated when the trading system is called and which results in such a user-defined"length". When using such an alternative, the enhanced trading system 8-10 analyses the trading system 8a-10a for such an expression-if it is found, the expression results in the use of a user- defined"length" ; if such an expression is not found, the enhanced trading system 8-10 will automatically analyse the logic of the trading system 8a-10a and determine from such logic the history"length"that is applicable to the trading system 8a-10a.

Selecting or determining a history"length"that is too large results in requesting more data than necessary, and may also result in the calculation of each point taking more time than necessary. Selection of a"length"that is too small, however, will result in the an incorrect determination of the trading system output. Accordingly, in a preferred embodiment, where the enhanced trading system 8-10 automatically analyses the logic of the trading system 8a-10a, the determination of the history "length"should be err on the side of an over-inclusive "length,"rather than an under-inclusive"length."In other words, in a preferred embodiment, the tendency is to be generous with the calculation of"length." As an example of the determination of"length,"consider a trading system 8a-10a that determines whether a five day daily moving average crosses below a ten day daily moving average for the same security. To calculate a five and a ten day daily moving average requires data for the most recent ten periods, i. e., a history"length"of

ten periods. To determine whether the five day line crosses below the ten day line, however, requires, that, the prior daily results are also calculated or retrieved.

Accordingly, if the prior daily results are retrieved, the history"length"is ten periods, but if they cannot be retrieved, the history"length"is eleven periods.

One of the novel features of the present system is that the enhanced trading systems 8-10 determines the data required for the execution of the related trading systems 8a-10a (by determining the history"length"), and that data is made available to the trading systems 8a-10a when the trading systems 8a-10a are executed.

It is clear from the foregoing that a the execution of a trading system 8a-10a may require the re-calculation of data that had already been calculated by an earlier execution of the same trading system 8a-10a. Using the example above, and further assuming that the example referred to making the calculation on a given day, the execution of the trading system 8a-10a will necessarily calculate the five day and ten day daily moving averages for the given day, and for the prior day. Thus, assuming that the trading system request is ongoing, each day, a portion of the prior day's calculations are re-done.

While this causes re-calculations, it frees the system from the alternatives, namely, storage and retrieval of a large amount of data, or"continuous"running of a trading system 8a-10a. The latter fraught with resource management issues and problems and under the continuous spectre of power loss or system corruption.

While according to the present invention it is not necessary to store results from calculations relating to a relatively small amount of time-series data, it is intended that the calculation results based upon larger amounts of time-series data will be stored, preferably by the trading system scheduler 7. The trading system scheduler 7 would pass such stored calculation results to the enhanced trading systems 8-10 or to the trading systems 8a-10a themselves. The amount of data required for a calculation that would be considered large enough to store the calculation results will be implementation dependent, and relatively easy to determine for any given implementation.

Although the recalculation of results is appropriate for some finite data sets, the results of calculations for recursive data sets is preferably stored. That is, as a general rule, calculations that require recursive data calculations are stored rather than recalculated.

Accordingly, in a preferred embodiment, relevant recursive data computations are stored rather than discarded. In this manner, the prior results are available to the next execution of a trading system 8a- 10a requiring them. The trading system scheduler 7 can store the results and pass them to the enhanced trading systems 8-10 when they are invoked.

Note that some recursive calculations may result in a tail of ageing data that becomes increasingly irrelevant to the trading system 8a-10a calculation as it occurs further in the past, while other recursive calculations may cause very old data to be significant to the trading

system 8a-10a. Although it can vary from implementation to implementation, it would be desirable in implementing the present invention to discard the former, while storing and maintaining the latter.

As also discussed above, the variables passed by the trading system scheduler 7 to the enhanced trading systems 8-10 including the period for which the trading system 8a-10a is to be run in relation to, no additional modifications are necessary to use the enhanced trading systems 8-10 to back-test a trading system 8a-10a.

Once the enhanced trading system 8-10 receives the required interval data, it will successively call the respective trading system 8a-10a, and supply it with the interval data and the parameters requires for each successive execution. In the simplest case, where there have been no missing executions, the trading system 8a- 10a will only be called for one iteration. Note that the enhanced trading systems 8-10 can be passed any range of dates, and therefore, any enhanced trading system 8-10 according to the present invention can be used for back- testing the respective trading system 8a-10a.

When the trading system 8a-10a is called, it performs its logic to determine whether signal should be generated, or whether no signal should be generated, and the trading system 8a-10a so indicates upon return from each iteration to the enhanced trading system 8-10. In a preferred embodiment, where a trading system 8a-10a indicates to the respective enhanced trading system 8-10 that a buy or sell signal should be generated, the

enhanced trading system calls the trading system scheduler 7 with a similar notification. The trading system scheduler 7 then may either immediately deal with providing the signal, or in a preferred embodiment, schedule the signal to get provided shortly and return to control to the enhanced trading system 8-10.

Upon successful completion of the successive process, the enhanced trading system 8-10 returns an indication thereof to the trading system scheduler 7, which updates its records regarding the last successful execution of the trading system request.

When trading system scheduler 7 is notified that a buy or sell signal is to be generated, it must determine which customer or customers to notify. As shown in Table 2, the identify of the customers that created the trading system request are associated with the request. Once the customers are identified, the trading system scheduler will pass this information, along with other relevant information relating to the signal to be generated, to the customer notification module 11. In a preferred embodiment, the customer notification module will have access to the customers preferred method for contact, which may be stored on a customer storage device 12.

Any method can be used for contacting the customer 14, including, by way of example, without limitation, a text- to-speech voice call, a pager notification, facsimile and/or email. Moreover, the notification can contain simply the symbol and an indication for buy and sell, or alternatively, can contain any additional information relating to the signal. For. example, the use of email

presents a novel way of notifying customer 14 of buy/sell signals. In the email, in addition to the relevant stock symbol, and a buy or sell indication, there can be included a textual, or better yet, a graphical representation of the data that led to the signal. In a preferred embodiment, the email does not contain the actual graphical representation, but rather just the data necessary for an external program to recreate the graphical representation. Sending the data rather than the graphical representation, for example, saves significant resources.

Furthermore, in a preferred embodiment, the customer notification module 11 creates an output that is then delivered to an accounting system (not shown). The output can indicate to the accounting system the customer for whom a signal was generated; in addition, the output can indicate to the accounting system the symbol, the time and date of the signal, a description of the delivery method, and/or, an indication of whether the signal generated was a buy or sell signal. The generation of such an output permits a novel method of billing customers for the execution of trading systems, namely, billing customers based upon the notification to buy or sell. It is also possible to have the price charged depend upon the method or time of delivery.

In order to streamline the execution of the enhanced trading system 8-10, in a preferred embodiment, the trading system scheduler 7 can maintain, in addition to the information already discussed, the amount of history

required for the execution of the enhanced trading systems 8-10.

# System Parameters Security Last Hist Customer 1 TS1 4,3 INTC 10 C1, C2 2 TS1 3,7 INTC 12 C1, C2, C3 3 TS1 4,3 AMAT 13 C1, C3 4 TS2 4,6,8 IBM 5 C1, C3 5 TS2 4,7,9 IBM 19 C2 6 TS2 4,6,8 AMAT 22 C3 TABLE 3 Where the trading system scheduler 7 maintains this information, the trading system scheduler 7, itself, can make the data request to the client data server 5 to insure the availability of the appropriate data. In other words, using the sample daily trading system requests set out in Table 3, the trading system scheduler 7 would make a data request for 12 days of INTC data prior to executing trading system requests 1 and 2. In the event that the request was not fulfilled by the client data server 5, neither request 1 nor 2 could run, and both would therefore be rescheduled. Similarly, the trading system scheduler 7 would make a data request for 22 days of AMAT data and 19 days of IBM data prior to executing trading system requests 3 and 6, and 4 and 5, respectively. Where the data requests are fulfilled by the client data server 5, the trading system scheduler 7 can pass the appropriate data to the enhanced trading systems 8-10 ; alternatively, a special data request could be used that merely indicated whether the data was available, and in that case, the trading system scheduler 7 would be relieved of having to retrieve and manage the interval data.

While the trading systems are described herein in terms of requiring market data related only to a single security, it is within the scope of the invention, and will be apparent to a person of skill in the art, to schedule trading systems that require market data relating to multiple securities as input.

While the foregoing describes and illustrates the preferred embodiment of the present invention and suggests certain modifications thereto, those of ordinary skill in the art will recognize that still further changes and modifications may be made therein without departing from the spirit and scope of the invention.

Accordingly, the above description should be construed as illustrative and not in a limiting sense, the scope of the invention being defined by the following claims.