Method for Dynamically Creating a Receiver Definable Local Trading Instrument Displayable Record From a Remotely Transmitted Trading Instrument Common Data Stream

This application is related to the commonly owned copending U.S. patent application entitled METHOD AND SYSTEM FOR DYNAMICALLY CONTROLLING THE CONTENT OF A LOCAL RECEIVER DATA BASE FROM A TRANSMITTED DATA BASE IN AN INFORMATION RETRIEVAL COMMUNICATION NETWORK, naming Richard A. Willis, Alan Markham and Robert S. Genshaft as joint inventors thereof, bearing U.S. Ser. No. 813,703, filed Dec. 27, 1985, the contents of which is specifically incorporated by reference herein in their entirety.

The present invention relates to methods for dynamically creating a receiver definable local trading instrument displayable record from a remotely transmitted trading instrument common data stream, such as a transmitted trading instrument common data stream comprising a plurality of transmitted trading instrument data records which may be transmitted in a logical data format and/or in a page display format comprising a plurality of displayed rows for each page in which instance the page display format is initially converted to a logical data format before creating the receiver defined local trading instrument displayable record, which local trading instrument displayable record is a new local trading instrument displayable record which is a reconstituted data record different from the transmitted trading instrument data record.

High performance, real-time information retrieval networks are well known in the art, such as the REUTERS MONITOR system employed for transmitting financial transaction information such as stock market information and other trading instrument information to brokers, banks and other subscribers. Such information is normally transmitted in a trading instrument common data stream, such as the data stream commercially available under the designation "REUTERS MARKETSTREAM" described by way of example in the aforementioned commonly owned copending U.S. patent application No. 813,703, which is incorporated by reference herein in its entirety. Such a trading instrument common data stream normally contains a large of number of information categories which professional traders and financial planners use in order to evaluate what action to take in connection with a given financial transaction. However, different professional traders and different financial planners require only certain aspects of the vast number of information categories normally transmitted. Thus, for example, a given professional trader or financial planner might only be interested in the month, high, low and closing price for gold and not be interested in the various other categories associated with the transmission of a trading instrument relative to gold, or he might be interested only in price and volume if he were doing charting or only in closing price if he were doing portfolio evaluation. In such an instance, in conventional prior art systems and methods, the professional trader or financial planner receiving the common data stream must display all of the information relative to the trading instrument in the above example including considerable information which is extraneous to his purpose. This is undesirable, particularly in todays's environment involving the transmission of high volumes of financial instruments which normally undergo a high frequency of changes in price and other characteristics or information catagories including those that are of interest to only certain financial planners or professional traders. Just as was described in the aforementioned copending U.S. patent application with respect to the problems which were overcome by allowing the local user to create its own unique local data base from the pool of available transmitted information, since a local user or subscriber, such as a bank, may not be interested in the entire data base supplied by an information supplier such as Reuters which supplies worldwide information relating to a vast number of financial instruments, the local subscriber may not be interested in displaying all of the information categories relating to the trading instruments which make up its unique local subscriber data base.

In an effort to overcome some of these problems, Reuters developed a Monitor Manipulation Processor for extracting entire pages of data from its REUTERS MONITOR data stream; however, such a system does not readily allow for the creation at the receiver of unique new local trading instrument displayable records which are reconstituted data records different from the transmitted trading instrument data records and tailored to contain and display only the information categories desired by the local subscriber. Moreover, in accordance with the present invention, these new locally identifiable trading instrument displayable data records which are created at the receiving end from the common remotely transmitted trading instrument data stream in accordance with the displayable information needs of the user or local subscriber are dynamically updateable as if they were an originally transmitted data record thereby enabling the local subscriber to create and display his own locally defined trading instruments which are unique subsets of the transmitted trading instruments. This may be accomplished with received transmitted trading instrument data records in a logical data format and/or page display format in which instance they are initially converted to a logical data format through the use of locally created templates and filter sets.

Moreover, although templates per se have been used at a local receiver to match information by a comparison technique, such as disclosed in U.S. Pat. Nos. 4,530,095; 4,507,750; 4,504,735; 4,499,499; 4,488,005; 4,468,204; 4,463,386; 4,388,495; 4,383,135; and 4,336,810, none of these prior art systems known to applicant employs a locally created template to create a new locally identifiable trading instrument displayable data record from a page display format transmitted trading instrument displayable data record nor do they disclose the use of filter sets to create such locally identifiable trading instrument displayable data records comprising reconstituted data records which are different from the transmitted trading instrument data record, nor such newly created records which can be dynamically updated. Thus, the presently preferred method and system of the present invention enables unique user defined locally identifiable trading instrument displayable data records to be created at the receiving end from a common remotely transmitted trading instrument data stream dependent on the displayable information needs of the user or local subscriber. Accordingly, the disadvantages of the prior art are overcome by the system and method of the present invention.

The present invention relates to a method and system for dynamically creating a receiver definable local trading instrument displayable data record from a remotely transmitted trading instrument common data stream whereby unique user defined locally identifiable trading instrument displayable data records may be created at the receiving end from the common remotely transmitted trading instrument data stream dependent on the displayable information needs of the user or local subscriber. The transmitted trading instrument common data stream may be in the form of logical data records and/or in a page display format comprising a plurality of display rows, in which instance, the page display format is converted to a logical data format prior to the creation of the receiver definable local trading instrument displayable data records. In either instance, the transmitted trading instrument common data stream which is provided from a remote source comprises a plurality of transmitted trading instrument data records. When the transmitted data records are in a logical data format, each of the trading instrument data records comprises a plurality of different displayable information record fields with each of the displayable information record fields for a particular trading instrument data record comprising an information category for the particular trading instrument.

When the transmitted trading instrument data record is in a page display format, a local receiver template is defined at the receiving end in order to convert the page display format to a logical data format. In defining the local receiver template, data locations in a portion of the page display format are defined for defining relative positions of logical fields in the page display format for a given display row in the page display format for providing a local template defined set of displayable information record fields. Each of the defined data locations comprises a defined area of the page display format display row. Each of the defined areas comprises an individual displayable information record field in the received transmitted displayable page data record with the displayable page data record comprising a plurality of bytes. In such an instance, each field is defined by an offset from the beginning of the associated area and the number of bytes comprising the field.

In either instance, a desired filter set of displayable information record fields is defined at the receiving end with the defined desired filter set comprising a plurality of record field identifiers. Each of the record field identifiers is uniquely associated with a different one of the displayable information record fields, with the defined filter set comprising a receiver defined portion of the plurality of available displayable information record fields. In the instance when a local receiver template is employed for data in a page display format, the desired filter set is defined in the local receiver template and is extracted from the local receiver template with the extracted filter set comprising a plurality of record field identifiers.

When the transmitted trading instrument data record is in the form of logical data, it is tagged in the received transmitted trading instrument common data stream with the desired receiver defined filter set for defining a new receiver defined local trading instrument displayable data record for each of the tagged transmitted trading instruments with the new local trading instrument displayable data record comprising only the portion of the information categories corresponding to the receiver defined portion of displayable information record fields. Thus, a new user defined local trading instrument is created which provides a display of only the information desired by the local subscriber. Moreover, this new user defined local trading instrument may be dynamically updated as the particular categories defined in this new local trading instrument are dynamically updated in the transmitted common data stream so that from the local subscriber's point of view it appears as if he is dynamically receiving his uniquely tailored local trading instruments such as stocks, bonds or other financial instruments. When the particular transmitted trading instrument data record is in a page display format, this record is tagged in the common data stream with the associated local receiver template for defining a new receiver defined local trading instrument displayable data record for each of the tagged transmitted trading instrument displayable page data records, with the extracted filter set displayable information record fields defining the new receiver defined local trading instrument displayable data record which comprises a reconstituted data record different from the transmitted trading instrument displayable page data record. This is also true for data in the logical data format wherein the extracted filter set displayable information fields comprise a reconstituted data record for each of the created new local trading instrument displayable data records which reconstituted data record is different from the transmitted trading instrument data record.

In accordance with the presently preferred method of the present invention, the filter set and/or the template may be varied or a common filter set and/or template may be used for a plurality of different transmitted trading instrument data records so as to provide a plurality of receiver defined new local instrument trading instrument displayable data records having a common set of information categories, such as for all NYSE stocks or for the stocks in the Dow Jones Average. Moreover, in the instance of data transmitted in a page display format, the user created local template may be repetitively used on different rows of a given page display and/or on different page displays to provide a plurality of receiver defined new local trading instrument displayable data records.

By employing the method and system of the present invention an efficient system for dynamically creating receiver definable or locally identifiable dynamically updateable local trading instrument displayable data records at the receiver end or local subscriber so that only the information desired by the local subscriber is displayed on his screen as user defined local trading instruments is achieved.

FIG. 1 is a diagrammatic logic flow diagram illustrating the presently preferred method of the present invention for dynamically creating locally identifiable receiver defined dynamically updateable local trading instrument displayable data records at the receiver end from a remotely transmitted common trading instrument data stream;

FIG. 2 is a diagrammatic logic flow diagram of the presently preferred method of the present invention illustrated in FIG. 1, illustrating the presently preferred method for treating the logical data and/or page data feed illustrated in FIG. 1;

FIGS. 3-8 are diagrammatic illustrations relating to the creation of local templates for the treatment of data transmitted in a page display format in accordance with the presently preferred method of the present invention illustrated in FIG. 1;

FIG. 9 is a diagrammatic illustration of the presently preferred method of creating fields in converting page data to logical data in accordance with the presently preferred method of the present invention illustrated in FIG. 1;

FIG. 10 is a diagrammatic illustration of a typical data record in accordance with the presently preferred method of the present invention; and

FIG. 11 is a diagrammatic illustration, similar to FIG. 10, of a typical update data record for price in accordance with the presently preferred method of the present invention.

For purposes of illustration, the presently preferred method of the present invention shall be described in terms of an information retrieval system for trading instrument data, such as stock market data and money market information and particularly in terms of use with a high speed remotely transmitted data feed or common data stream of such trading instrument data records such as the data stream which is described in the aforementioned commonly owned U.S. patent application Ser. No. 813,703, commercially available under the designation "REUTERS MARKETSTREAM" and specifically incorporated by reference herein in its entirety, and which is a protocol used for long distance transmission of logical data which is ISO compatible. As shown and preferred in FIG. 1, and as will be described in greater detail hereinafter, the presently preferred method of the present invention is also usable with trading instrument data records which are transmitted in a page display format as opposed to a logical data feed, such as illustrated in FIG. 3, wherein the page display data is preferably converted to logical data in accordance with the presently preferred method of the present invention prior to treating the data to provide a locally identifiable or receiver defined local trading instrument displayable data record in accordance with the presently preferred method of the present invention.

For purposes of the following description of the presently preferred method of the present invention, it is assumed that the system employed transmits and receives standard 8 bit ASC11 characters and that there is a perfect transmission link in keeping with an ISO OSI model.

Referring initially to FIG. 1, the general approach to the presently preferred method of the present invention is shown. A common remotely transmitted trading instrument data stream, such as the data stream described in the U.S. patent application Ser. No. 813,703, is transmitted from the remotely located transmitter data base 20 to the various local receiver data bases located at a plurality of local subscribers, with only one such typical subscriber data base 22 being illustrated in FIG. 1. At the local receiver data base 22, the local subscriber may create its own local data base as a subset from the overall transmitted data base 20, such as in accordance with the method described in the aforementioned U.S. patent application Ser. No. 813,703 incorporated by reference herein. The transmitted common data stream may contain trading instrument displayable data records which are in a page display format as represented by reference numeral 24, such as illustrated in FIG. 3, and/or in the presently preferred logical data format, represented by reference numeral 26, which is the format of the REUTER MARKETSTREAM data feed, such as described in the aforementioned U.S. patent application Ser. No. 813,703. These transmitted trading instrument data records are preferably identified by unique codes or RICs. As shown and preferred in FIG. 1, and as previously referred to, trading instrument displayable data records which are desired or requested by the local subscriber and which are transmitted and received in a page display format are first preferably converted to a logical data feed format such as employed for the REUTER MARKETSTREAM data feed, as represented by reference numeral 28, and then treated as a logical data feed in the same manner as the transmitted and received logical data feed data, as represented by reference numeral 30. Thereafter, the local receiver processes the receiver defined locally identifiable trading instrument displayable data records, as represented by reference numeral 32, to provide a tailored display of these unique user defined or local trading instruments, as represented by reference numeral 34.

Trading instrument data records, such as illustrated in FIG. 10, normally contain a plurality of fields or information categories relating to the particular trading instrument which fields in a logical data record such as REUTER MARKETSTREAM are each identified by a unique field identifier or FID which is preferably a numeric identifier. By way of example, the below table illustrates a typical group of fields and corresponding unique numeric field identifiers which could be employed with a logical data feed common data stream to be treated in accordance with the presently preferred method of the present invention to provide uniquely tailored locally identifiable receiver defined updateable trading instrument displayable data records employing one or more of these fields for any given trading instrument or RIC dependent on the needs and desires of the local subscriber, with the local subscriber using a filter set, which is a subset of fields, to define those particular fields which are relevant to his interest, in accordance with the presently preferred method of the present invention. These filter sets are, in turn, preferably uniquely defined by filter set identifiers which are unique numeric identifiers of the filter sets.

It should be noted that the above exemplary fields are preferably variable length with a typical data record being illustrated in FIG. 10, using ASCII data separators, with the symbol "IS" representing an information separator. The ASCII information separators, such as file separator (FS), group separator (GS), record separator (RS) and unit separator (US), are used in a hierarchial manner, i.e. when they are used as parenthenses the lower level separator has the effect of closing the parentheses for that level and all higher ones, as illustrated in FIG. 11. For example, in REUTER MARKETSTREAM there in a hierarchy of fields and groups of fields which is supported by the presently preferred method of the present invention; e.g., the fields of an update FID and Data, are separated from each other by the ASCII separator <US>, and the pair FID <US> <DATA>, are separated from additional pairs by the ASCII separator <RS> in the conventional BNF type of notation employed hereinafter in describing the presently preferred method of the present invention. In employing this exemplary BNF notation herein, the following definitions are employed: <. . . > is used to enclose a named thing; <Alpha name> represents any RIC; <Application specific field> indicates a field of characters sent, unique to an implementation; <Filter set> represents a subset of fields relevant to a host which is a computer, such as an IBM PC operating in accordance with the presently preferred method of the present invention, for receiving the processed logical data feed or contributed data provided as opposed to a TC or terminal controller which transmits the processed logical data feed or receiver contributed data; <Filter Set ID> represents the numeric identifier of a filter set; <Field ID> represents a numeric identifier of a data feed field such as illustrated above in the typical field list; <Local field ID> is the same as a field ID but defined by the host; <Field Data> represents the ASCII equivalent of an update and allows for partial field data; <Source Logical address> represents the logical address, such as 24 bits expressed as six hexidecimal characters; CIP represents the contributor interface processor; <RTL> represents the transaction level which is incremented each time an update or correction is received for a record; <DATA Partition> which represent the field which denotes the database partition which has this RIC, <RIC> which represents the unique code for a transmitted record; <Template number> which represents the number indicating the template associated with a record which template, in accordance with the presently preferred method of the present invention, enumerates the fields of a record and associates the field IDs with that template and is used in connection with a page display data feed; <Parse Method> which is the method used to extract logical data from page data; <Presentation Method> which is the method used to convey a logical field derived by parsing. The ASCII or ISO separators FS, GS, RS, US, referred to above, are enclosed in < > as well.

In addition to the above notation, the following notation is also employed herein: 1{ . . . }m indicates that the enclosed structure may occur 1 to m times; () encloses optional structures; COMMAND represents a host-to-TC communication; TRANSMISSION represents a TC-to-host communication; MESSAGE represents either a command or transmission; Filter set 0 by convention means all fields; Port represents the circuit (physical/virtual). With respect to the presentation syntax employed, objects are named and used in < > while literals are not contained in < >; items that can occur a variable number of times are presented as m{ . . . }n indicating that the named structure can occur from m to n times; and optional fields are enclosed by (). With respect to the control codes employed, CSI is the ISO control sequence introducer; REP is an ISO control sequence represented by CSI n b and indicates that the prior graphic character is to be repeated n times; CUF is the ISO editor function Cursor Forward represented by CSI n C, where n is the number of character positions forward the cursor is moved; CAN is an ISO control used to indicate that the data since the prior <FS> is in error and should be discarded; and EM which is the ISO end of medium character received for use by the packet layer-presentation layer interface. It should be further noted that field contents are represented in a display compatible form with members preferably being represented by a sequence of ASCII characters and with any offset into a field being indicated by the ISO editor function CUF cursor forward which is represented by CSI n C where n is the offset value.

Now that the basic notation to be used herein in descrbing the presently preferred method of the present invention has been defined, the various steps employed herein will be described in greater detail hereinafter using thus notation. However, before doing this, the method of the present invention shall generally be described with reference to FIG. 2. The host computer at the local subscriber which processes the incoming common data stream and creates the locally defined local trading instrument displayable date records dependent on the user's needs, may preferably be any conventional microcomputer capable of sending and receiving standard 8 bit ASCII characters, such as and IBM PC or IBM compatible computer, by way of example, capable of operating, by way of example, under a PL/M-86 compiler for C code, such as available from Lattice Inc. The host computer preferably determines whether the remotely transmitted common trading instrument data stream data record being received is a logical data feed such as the data feed described in the aforementioned U.S. patent application Ser. No. 813,703, or a page display data format, as represented by reference numeral 50 in FIG. 2. If the received record is a logical data feed, then the request list is examined by the host computer to determine if this logical instrument record has been requested, as represented by reference numerals 52 and 54 in FIG. 2. Prior to this, it is assumed that the local subscriber has created and indicated to the host computer a definition of the relevant filter set to be employed for a particular trading instrument or instruments of interest and has related each selected trading instrument to a user defined filter set. In addition, the user will have indicated whether a snapshot or one time request is desired or whether an updateable request is desired. Thereafter, if the host computer determines that the received logical trading instrument is one which has been requested by the user or local subscriber, it looks up the relevant field set definition which has been tagged to that record or RIC and determines the particular fields selected by the local subscriber, as represented by reference numerals 56 and 58 in FIG. 2. This information is then used to reformat the received tagged transmitted trading instrument data record into a new receiver defined local trading instrument displayable data record which is a reconstituted data record which comprises only the portion of the fields or information categories corresponding to the user defined filter set as opposed to all of the various fields contained in the remotely transmitted trading instrument data record as represented by reference numeral 60 in FIG. 2, with the reconstituted data record being illustrated in FIG. 10. This reconstituted data record or locally identifiable trading instrument is then processed and displayed at the local subscriber terminal by the terminal controller or TC, as represented by reference numeral 62 and 64 in FIG. 2, which display contains only the selected information categories desired by the local subscriber. Moreover, this new local trading instrument may be dynamically updated in real time as the received transmitted trading instrument data record is updated in the common data stream so that to the user it is as if his unique user defined local trading instrument had been transmitted as such from the source of the common data stream. A typical update data message for price in accordance with the presently preferred method of the present invention is shown in FIG. 11 which employs the aforementioned hierarchial ASCII information separators.

As was previously mentioned, the transmitted original data records received by the host computer may be in the form of page display data as opposed to a logical data feed, such as illustrated in FIGS. 3 and 9, in which instance the received record is preferably first converted to the same type of format as the logical data feed so as to preferably make the record independent of the display. Again referring to FIG. 2, if the received record is in a page display format, the local ID for the page is looked up by the host computer in order to determine if this page has been requested, as represented by reference numerals 66 and 68 in FIG. 2. The desired page display data is then preferably converted to logical data, as will be described in greater detail with reference to FIGS. 3-9, as represented by reference numeral 70 in FIG. 2. As will be described in greater detail hereinafter, the local subscriber preferably creates local template definitions in accordance with the presently preferred method of the present invention. The user created local template definition defines the fields to be used in extracting data in the manner of the aforementioned field sets, but which are preferably used in the page-to-logical data conversion process as shown in FIG. 9. The page display data record is tagged with the local template whose definition is then looked up by the host computer and the relevant fields defined by the local template are then extracted from the local template, as represented by reference numerals 72 and 74 in FIG. 2. Thereafter, since the page display data record has been converted to a logical data record, it is then preferably processed in the previously described manner used for a logical data feed.

As shown and preferred in FIGS. 3-9, in converting page data to logical data in accordance with the presently preferred method of the present invention, a local template is first defined by the user and an area of a page is named and associated with that local template. The local template preferably assumes a continuous string of bytes to be a record with areas of that record then being chosen to be individual fields as illustrated by way of example in FIG. 9 which shows seven fields comprising exemplary template #1, which fields are defined by areas of the record, which record is illustratively shown as comprising one display row on the page, such as for DMK in the example of FIG. 9. These areas chosen to be individual fields are preferably chosen by specifying the offset from the beginning of the area and the number of bytes that make up that field. Preferably, as shown by way of example in FIG. 9, the area is chosen by specifying an upper left corner and a lower right corner of a rectangle, with the area then being considered to be a continuous string with no breaks. Of course, the user could reasonably restrict the area to be the entire page by not allowing the start and end to be specified and, in the same way, fields could be restricted so that they do not cross display rows. FIG. 9 also illustrates a typical filter set definition which can be extracted from the local template defined therein as well as a typical snapshot request based thereon.

FIGS. 3-8 illustrate another example, in simpler form, for converting page data to logical data and ultimately to the user defined local trading instrument. Thus, FIG. 3 illustrates a typical page display for an exemplary trading instrument for gold by way of example. FIG. 4 illustrates the user defined local template for a single display row which covers the particular categories or fields of interest for that user defined by areas in the page display of FIG. 3 which template is logically overlayed on the page display to create the local template defined local trading instrument, which is given a new logical instrument name, such as represented by JG1 in FIG. 5, with the template being represented in FIG. 6. FIG. 7 illustrates the repetitive use of this same local template definition for a different display row in the page display format of FIG. 3 to create a different local trading instrument represented by APG1 in FIG. 8. Thus, in converting page data to logical data, the page must be defined, the local template defined, the "position" of the template in the page display defined and the new local trading instrument be given a local ID or logical instrument name, whereby it can then preferably be treated in the same manner as transmitted logical data.

It should be noted, however, that in accordance with the presently preferred method of the present invention, a single or common user created local template can be repetitively employed for different display rows of a given page display, as illustrated in FIGS. 3-8, and/or for different page displays. In this regard, it should be noted that preferably all database items are conceived as records and fields of those records, with each record having a unique record name. In the instances where templates are employed, record formats are preferably defined by their template which is a list of the fields within a record. Thus, records which have the same format have the same template. For example, as previously mentioned, all NYSE stocks could have the same template in accordance with the presently preferred method of the present invention. With respect to field ID's for a given page display, they may preferably be arbitrary, with lines or half lines usually comprising fields.

Various ISO type control commands are preferably employed with the host computer to enable the host computer to act as a keystation as well as a computer in accordance with the presently preferred method of the present invention. By way of example, and using the aforementioned BNF type notation, these exemplary ISO type control commands are as follows, assuming the protocol employed in accordance with the presently preferred method of the present invention is the aforementioned U.S. patent application Ser. No. 813,703.

The Set Marketfeed Mode command establishes Marketfeed as the protocol. The format is: <CSI>?100h,

The Reset from Marketfeed Mode command returns the TC to normal mode. The format is: <CSI>?100m.

The Reset to Initial State may be used as a command or transmission and causes intialization. It is a complete reset. The format is: <ESC>c

The Soft Reset clears the output queue and stops all update traffic. The format is: CSI ! p.

The Set Port On command which will enable the port. It is assumed that some other port will be disabled by this command. The format is: CSI? 103h.

The Reset Port Off command which will disable the port. The only command that will be seen by the port is Set Port On. If a TC can only support a limited number of ports it needs these commands. The format is: CSI? 103m.

As was previously mentioned, an important aspect of the presently preferred method of the present invention relates to the ability of the user or local subscriber to define filter sets, which may be added or deleted as desired by the user to provide the desired user defined locally identifiable trading instrument display records at the receiver. These filter set definitions, as previously described, are preferably used by the host computer to select a particular user defined collection of fields to be passed from a terminal controller or TC, with the filter sets controlling the data the host computer receives. For example, one filter set may be defined to contain price and volume by a host doing charting and another filter set may be defined to contain closing price only for a host computer that may be doing portfolio analysis. By way of example, it is assumed that filter set 0 is defined to mean all fields, exclusive of permissions if they are employed. The record of interest is preferably tagged by the host with the relevant filter set number in accordance with the presently preferred method of the present invention, thereby eliminating the need to tag individual fields within the record. In the maintenance of filter sets in accordance with the presently preferred method of the present invention, various commands are employed by way of example. These exemplary commands are as follows, using illustrative message numbers which correspond to these exemplary commands.

The Add Filter Set Definition (message #303) message defines a filter set. This definition associates a filter set number with a list of field IDs and provides a way for the host computer to define a collection of fields of interest.

The format is:

The drop Filter Set Definition (message #311) command deletes filter set definition. It is an error in accordance with the presently preferred method of the present invention to delete a filter set while data requests using that filter set are active.

The format is:

The Drop all Filter Set Definitions (messages #406) command deletes all filter set definitions. It is an error in accordance with the presently preferred method of the present invention to delete all filter sets while any request using a filter set is outstanding.

The format is:

Apart from the above Filter Set maintenance message, two type of data requests are also preferably employed in accodance with the presently preferred method of the present invention. These are a request for data (snapshot) and a request for data to be followed by updates.

The Data and Update Request (message #332) command requests the present values of the data selected by the filter set and enables updates of those fields for the named instrument to follow.

The format is:

Other examples of possible commands employed in accordance with the presently preferred method of the present invention are as follows. The Cache Request (message #336) command requests the controller to cache the data.

The format is:

As was previously mentioned, the default filter set is 0, all fields.

The Cache Release (message #337) command requests the controller to unlock the data from cache.

The format is:

The Cache Delete (message #387) command requests the controller to delete the data from cache.

The format is:

The Halt Updates (message #348) command is used to halt updates on a given trading instrument or RIC.

The format is:

The Host Identify (message #371) command allows a host to establish its logical address so the TC can get permissions.

The format is:

The Time Request (message #372) command requests the TC's time of day.

The format is:

By way of example, if the Request type is 0 then time is to be sent once, if the request type is 1 the time is to be sent each time the TC receives it, and if the request type is 2 the time transmission should be stopped. The default request type is 0.

Now that some typical messages and commands have been discussed, some typical responses, such as data responses, sync responses, status responses, etc. will be discussed by way of example. The Data Response (message #340) transmission is preferably issued by the TC in response to a request. It is transmitted before any updates. Included updates should not be duplicated and no subsequent update should be lost. It can be used to determine the template of an instrument. The template may be required so the receiving program can allocate data storage for the instrument. The class of a local ID is 255.

The format is:

The Verify or sync (message #318) transmission is preferably issued by a DATAFEED ONLY. It reflects a copy of the central data base and is synchronous with the updates.

The format is:

The Status Response (message #407) transmission is preferably used to communicate status to the host.

The format is:

Status=1=Negative for technical reasons

Status=2=Negative--no such name, variable=name

Status=3=Not permissioned, variable=name

Status=4=Looking, wait. (MS type system), variable=name

Status=5=Port not available

Status=6=No such filterset number, variable=filterset number

Status=7=Invalid Local Template Definition, variable=Local Template ID

Status=8=Invalid Local ID Definition, variable=Local RIC

Status=10=Too many names, variable=name

Status=11=Too many filter sets, variable=filterset ID

Status=12=Too many Private templates, variable=template no

Status=13=Too many Local IDs, Variable=Local ID

Status=20=Communication accepted (can be used if a positive acknowledge scheme is required)

Status=21=Queue overflow

STATUS=22=Invalid Host logical address, Variable=Logical address

Another type of exemplary transmission used to communicate status to the host is the Asynchronous Status Response (message #408). It is useful for broadcast devices which may encounter error conditions some time after the request is made.

The format is:

The field Update (message #316) transmssion is used to provide updates. The fields are preferably limited to those listed in the Filter Set Definition.

The format is:

Other exemplary responses are correction, database add, database drop and time response. These are as follows.

Correction (message #317) is transmitted as a consequence of the controller receiving a correction.

The format is:

Database Add (message #301) is transmitted as a consequence of the controller receiving a database add. This indicates that a new name has been added to the database.

The format is:

Database Drop (message #308) is transmitted as a consequence of the controller receiving a correction. This indicates that a name has been dropped from the database.

The format is:

Time Response (message #367) is the time and date message.

The format is:

Some typical commands which may be employed by way of example, in accordance with the presently preferred method of the present invention in converting page to logical data are to add or drop a local ID definition, add or drop a local template definition, drop all local IDs or drop all local templates. These exemplary commands are defined as follows.

The Add Local ID Definition (message #400) command names an area of a page and relates a local template to that area. The local template will be used to find individual fields within that area.

The format is:

It should be noted that if the beginning and ending positions are omitted they are assumed to be the entire extent of the page.

The Add Local Template Definitions (message #401) command defines a local template which gives the length and offset of fields within an area. It is used for extracting fields from an area of a page. The parse method denotes how the data is to be extracted from the string and the presentation method indicates how it is to be transmitted. A local template is preferably given a negative number to distinguish from the templates employed in connection with MARKETSTREAM by way of example.

The format is:

The Drop Local ID (message #402) command will delete a local ID.

The format is:

The Drop Local Template (message #403) command is used to delete a local template definition.

The format is:

The Drop All Local IDs (message #404) command is used to delete all local IDs.

The format is:

The Drop All Local Templates (message #405) command is used to delete all local templates.

The format is:

An exemplary program listing for achieving the various functions of the host computer described above in accordance with the presently preferred method of the present invention is annexed hereto as Tables A-G which may be run on an IBM PC and is in the format of PL/M-86 compiler written in C code such as available from Lattice Inc. ##SPC1##

Summarizing the presently preferred method of the present invention, when the transmitted trading instrument data record is in a page display format, a local receiver template is defined at the receiving end in order to convert the page display format to a logical data format. In defining the local receiver template, data locations in a portion of the page display format are defined for defining relative positions of logical fields in the page display format for a given display row in the page display format for providing a local template defined set of displayable information record fields. Each of the defined data locations comprises a defined area of the page display format display row. Each of the defined areas comprises an individual displayable information record field in the received transmitted displayable page data record with the displayable page data record comprising a plurality of bytes. In such an instance, each field is defined by an offset from the beginning of the associated area and the number of bytes comprising the field.

In either instance, that is whether the transmitted record is originally in a logical data format or a page display format, a desired filter set of displayable information record fields is defined at the receiving end with the defined desired filter set comprising a plurality of record field identifiers. Each of the record field identifiers is uniquely associated with a different one of the displayable information record fields, with the defined filter set comprising a receiver defined portion of the plurality of available displayable information record fields. In the instance when a local receiver template is employed for data in a page display format, the desired filter set is defined in the local receiver template and is extracted from the local receiver template with the extracted filter set comprising a plurality of record field identifiers.

When the transmitted trading instrument data record is in the form of logical data, it is tagged in the received transmitted trading instrument common data stream with the desired receiver defined filter set for defining a new receiver defined local trading instrument displayable data record for each of the tagged transmitted trading instruments with the new local trading instrument displayable data record comprising only the portion of the information categories corresponding to the receiver defined portion of displayable information record fields. Thus, a new user defined local trading instrument is created which provides a display of only the information desired by the local subscriber. Moreover, this new user defined local trading instrument may be dynamically updated as the particular categories defined in this new local trading instrument are dynamically updated in the transmitted common data stream so that from the local subscriber's point of view it appears as if he is dynamically receiving his uniquely tailored local trading instruments such as stocks, bonds or other financial instruments. When the particular transmitted trading instrument data record is in a page display format, this record is tagged in the common data stream with the associated local receiver template for defining a new receiver defined local trading instrument displayable data record for each of the tagged transmitted trading instrument displayable page data records, with the extracted filter set displayable information record fields defining the new receiver defined local trading instrument displayable data record which comprises a reconstituted data record different from the transmitted trading instrument displayable page data record. This is also true for data in the logical data format wherein the extracted filter set displayable information fields comprise a reconstituted data record for each of the created new local trading instrument displayable data records which reconstituted data record is different from the transmitted trading instrument data record.

By employing the method and system of the present invention an efficient system for dynamically creating receiver definable or locally identifiable dynamically updateable local trading instrument displayable data records at the receiver end or local subscriber so that only the information desired by the local subscriber is displayed on his screen as user defined local trading instruments is achieved.