T 0359/03 (Computerized trading system/BELZBERG) of 19.7.2006

Summary of Facts and Submissions

I. This appeal is against the decision of the opposition division to revoke European patent No. 0 752 135.

II. The opposition division found that the opposition of opponent 01 was not admissible. On the basis of the admissible oppositions of opponents 02 and 03, the opposition division held that claim 1 of all requests was either not new or not inventive over the Mesa program, which was considered as being publicly available before the priority date of the patent in suit and which was described in the following documents:

D26: MESA User's Guide, Release 1.5, first edition printed 1993, Athena Design Inc., Boston, MA

D27: MESA Programmer's Guide, Release 1.5, first edition printed 1993, Athena Design Inc., Boston, MA

III. The proprietor lodged an appeal and, with the statement of grounds of appeal, filed a main and first to fifth auxiliary request (identical to those submitted at the oral proceedings before the opposition division), and sixth to tenth auxiliary request. Opponent 02 (respondent 02, hereafter merely "respondent") filed a response.

Both parties made an auxiliary request for oral proceedings.

Respondent 03 (opponent 03) made no submissions as to the merits of the present case.

IV. At the oral proceedings, which were attended by the appellant and the respondent, the appellant requested that the decision under appeal be set aside and that the patent be maintained on the basis of the main request or first or sixth auxiliary request, filed with the statement of grounds of appeal, or second to fifth or seventh to tenth auxiliary request filed during the oral proceedings.

The respondent requested that the appeal be dismissed.

At the end of the oral proceedings, the Chairman announced the decision.

V. Claim 1 of the main request (corresponding to claim 1 as granted) reads as follows:

"A computer system having means to receive data from a central computer (50) of a stock exchange on a spreadsheet (56);

display means and means to communicate orders to the order entry system (60) of the stock exchange computer,

a control system (58) comprising means to read selected groups of said data from said spreadsheet;

means (58) to format said selected groups of said data in a manner acceptable to the stock exchange computer order entry system;

means (46, 58) to launch said formatted data as orders to the stock exchange computer order entry system."

In claim 1 of the first auxiliary request, the last feature is modified to read "means (46, 58) to launch said formatted data as orders for trading a basket of shares to the stock exchange computer order entry system".

In claim 1 of the second auxiliary request, the penultimate feature of the first auxiliary request is modified to read "means (58) to format said selected groups of data for transmission to an order entry system of the exchange, the formatting involving converting each stock price and volume of the selected groups of data from the spreadsheet into a corresponding variable for insertion into a list of preprogrammed commands which is to be sent to the order entry system of the stock exchange".

Claim 1 of the third auxiliary request adds in substance to the end of claim 1 of the second auxiliary request the feature "wherein said means to read, means to format, and means to launch are operated by means of a graphic user interface with display means and a mouse adapted to communicate to selected controls on the graphic user interface".

Claim 1 of the fourth auxiliary request adds in substance to the end of claim 1 of the third auxiliary request the feature "in which said graphic user interface displays commands (34) which include share symbols (36), price selections (44), order size, and transaction types (38-42)".

Claim 1 of the fifth auxiliary request adds to the end of claim 1 of the fourth auxiliary request the feature "with a dynamic data link to the spreadsheet which causes the spreadsheet to read the list of stocks to the control system".

Claim 1 of the sixth to tenth auxiliary requests corresponds in substance to claim 1 of the first to fifth auxiliary requests, respectively, with the addition of the words "into which the user inputs trading data" at the end of the opening paragraph.

VI. The appellant argued as follows:

The invention was very advantageous even if only one kind of stock was to be traded. The trader simply inserted the required trading data, like sell when the price was 10% above a given value, into a spreadsheet using a few mouse clicks. The trading criteria could be a function of the contents of any cell or group of cells in the spreadsheet, and the system would perform the desired trade when the conditions were met. This insertion of the trading criteria could be done without using any further programming language. The trader could change any or all the trading data at any time, if desired, without having to communicate with the software company that programmed the custom application.

Mesa was not a trading system, but a spreadsheet program. The Mesa user manual, D26, was four hundred pages long and only page 275 mentioned trading in connection with the SIGNAL function. However, this function only allowed a single trade. There would have to be a custom application for each trade each involving two functions, a signal and an action programmed to respond to the signal.

Mesa had a Mesa Object Library Interface (MOLI) that permitted writing custom applications in objective-C. Such a custom application read ticker data from the spreadsheet and put it somewhere in a format not disclosed in D26 or D27. The custom programmer was informed by the trader, in natural language, under which conditions and for what a price he wanted to buy or sell a stock. The programmer inputted this data somewhere into the custom application, not into the spreadsheet. The data did not have the format of the data in the Mesa spreadsheet. The C program generated a signal, which also did not have the format of a cell of the spreadsheet. Thus it was not the spreadsheet data that was sent to the entry system of the stock exchange computer, and D26 and D27 did not even suggest formatting the spreadsheet data directly as claimed in claim 1.

Mesa also required a C-compiler, which was not required in the patent.

In claim 1 of the first auxiliary request, the additional feature of trading a basket of shares was a technical difference because the number of shares affected how the trading system operated. When trading a basket of shares, an analysis was made for the composite group. Thus, in accordance with the invention, a single command could result in several orders.

Claim 1 of the second auxiliary request provided further technical features. Again the prior art did not disclose or suggest the special kind of conversion of the spreadsheet data into a corresponding variable for insertion into a list of pre-programmed commands.

The additional features of claim 1 of the third auxiliary request, namely using a graphic user interface with display means and a mouse, made the system easier to use.

The items displayed by the graphic user interface according to claim 1 of the fourth auxiliary request were originally present in claim 5. Original claim 1 covered both embodiments, so that the combination of claims 1 and 5 supported the amendment. These features improved the flexibility of the system.

The dynamic data link in claim 1 of the fifth auxiliary request enabled the system to work unattended.

The additional feature in claim 1 of the sixth to tenth auxiliary requests defined that the user inputted trading data into the spreadsheet. This was supported by the patent at column 2, lines 54 to 58, which stated that the computer could react to information or commands from the operator. Furthermore, Figures 3A and 3B showed that trading data could be entered into the spreadsheet. Also the patent stated at column 5, lines 21 to 23, that the computer captured all the data necessary to trade from the spreadsheet. The trading criteria had to be entered into the spreadsheet by the user since they could not come from the stock exchange computer.

This feature made the system more flexible because it was not necessary to have a dedicated data entry page.

In the Mesa system, the custom applications would have to be programmed individually by a programmer, so that the order was not entered by a user, as claimed.

VII. The respondent argued as follows:

A custom trading application for the Mesa spreadsheet would inevitably contain the control system, means to format the data, and means to launch the data as orders according to claim 1. The claim and indeed the patent gave no details of how the data was formatted so that this could not be used to justify a difference. In fact, the Mesa documents gave more detail than the patent about sending messages.

In particular, D27 disclosed at page 2 that the Mesa Object Library Interface (MOLI) allowed other programs to get values from Mesa worksheets and "execute a trade" in response to an event in the worksheet.

D26 disclosed the means to read selected groups of data at page 1, paragraph 1 and page 4, last paragraph and page 5, first full paragraph, by stating that Mesa allowed another application to "link right into the data in a worksheet".

D26 also disclosed at page 275 the "SIGNAL" function which "sends a range of cells" to the program when a particular condition was met, in order to "perform a securities trade", for example. The trading application would have to know the price and so this had to be sent from the spreadsheet. The data had to be in a form acceptable to the stock exchange computer order entry system, so the formatting means were implicit; correct message header, parity etc.

D27 gave an example, at pages 46 to 50, of using the "SIGNAL" function to send a range of cells and alert the user when particular conditions for trading were met. This was a simple example, like a "hello world" example used when explaining a programming language, but the technique could be applied to the trading situation.

The means to communicate orders was a duplication of other features.

In view of claim 2, which specified that the launch was responsive to conditions in the data read from the spreadsheet, the read function in claim 1 covered the case where data was read in order to check that these conditions were met. This was implicit in the Mesa "SIGNAL" function.

A Mesa custom application that executed a trade was a "means to launch" the data.

Although decision T 641/00 could be applicable to this case, the "normal approach" using Article 56 EPC was preferred for attacking the feature of "trading a basket of shares" in claim 1 of the first auxiliary request.

This feature did not imply a single command, but it meant simply that the system generated multiple orders. This was obvious from the possibility of maintaining a stock portfolio in the Mesa system, mentioned in D26, page 4, last paragraph and D27, page 47, last paragraph.

Any other details of basket trading were well known and the patent disclosed this at paragraphs [0006] to [0008], and gave no further details.

The patent did not disclose any details of the "list of preprogrammed commands" in claim 1 of the second auxiliary request, and the associated features were implicit from the Mesa system.

The additional features of claim 1 of the third auxiliary request, namely using a graphic user interface with display means and a mouse, were either implicit from the Mesa system, e.g. D26 page 23, penultimate paragraph, or obvious.

The share symbols in claim 1 of the fourth auxiliary request had not been disclosed in combination with trading a basket of shares. In the claim, the reference 36 to the share symbols was wrong and it should have been 12. This was only in Figure 2, which related to the first embodiment, whereas the idea of trading a basket of shares was in the second embodiment, represented by Figure 3, which did not show share symbols. Although these features were in original claim 5, the original claims did not contain the feature of trading a basket of shares.

The use of a dynamic data link in claim 1 of the fifth auxiliary request to read data from the spreadsheet was a well known measure, e.g. the Dynamic Data Exchange (DDE) described in D17 (Reuter Terminal Dynamic Data Exchange, Reference Guide, Version 2.15, 1993, Reuters Ltd., London) at page 2-1. In particular, the "WM_DDE_ADVISE" command described at page 2-4 requested a server to supply updates for monitored data whenever it changed.

The patent did not support the feature that the user entered data into the spreadsheet, as added to claim 1 of the sixth to tenth auxiliary requests. Figure 3A only showed commands that controlled the system, but not the spreadsheet. Figure 3B showed a spreadsheet, but not that any data was entered. The patent at column 2, line 39 stated that prices were recorded on the spreadsheet. It was not inevitable that data could be entered by the user because the spreadsheet could have been locked.

Since this feature was not disclosed, it did not have any link with the other features. Moreover, user data entry was an obvious function of a spreadsheet, e.g. as described in D26 at page 3.

Reasons for the Decision

1. The appeal complies with the requirements referred to in Rule 65 (1) EPC and is, therefore, admissible.

2. The opposition division found that the opposition of opponent 01 was not admissible. Since opponent 01 did not file an appeal, this decision took legal effect and opponent 01 ceased to be a party to the present appeal proceedings (see decision T 898/91, not published in OJ EPO, point 1.2 of the reasons).

The patent

3. The patent concerns a system for automating the buying of shares having an interface running on a user's PC connected to a stock exchange mainframe computer (Figure 1). A first embodiment, shown in Figure 2, has a graphical user interface that enables transaction data, such as share symbols (12), price selections (14), order size (16), transaction type (22), etc., to be entered. A second embodiment, shown in Figure 3, has an interface in which data about multiple shares to be traded (so-called "basket of shares" - see paragraphs [0006] to [0008]) transferred from the stock exchange mainframe computer is displayed in a spreadsheet. The shares can be processed in a single transaction.

The Mesa spreadsheet

4. It is common ground that a custom application can be written in objective-C for the Mesa spreadsheet program that performs a single securities trade. D26 discloses at page 275 a "SIGNAL" function that performs such a trade by sending a range of cells from the spreadsheet to the "BUY_GOLD" object when certain conditions are met. The object that would respond to the function would be a MesaListen object, such as that disclosed in D27 at pages 48 to 50, from the Mesa Object Library Interface (MOLI).

Main request

5. The appellant's arguments essentially only relate to whether the above-mentioned trading example also discloses means to format selected groups of data read from the spreadsheet in a manner acceptable to the stock exchange computer order entry system as in the third and fourth features of claim 1. The argument is essentially that the example does not specify the format or the destination of the data from the spreadsheet, and that the custom program, not the spreadsheet would specify the trading conditions, so that the data sent to the stock exchange computer is not formatted spreadsheet data as required by the claim.

6. The Board agrees that it is true that in the Mesa spreadsheet somebody, e.g. a programmer, must write a program in order to perform the trade in the "BUY_GOLD" example. However, the user interface of the patent is also a custom program that has to be written. This user interface allows the trader to enter trading conditions, apparently via custom controls and/or via equations in a Microsoft Excel spreadsheet (Figure 3B). In principle, Mesa could also be programmed to allow this. However, neither the manner of programming, nor the manner of entering the trade are claimed, and the result of any such program must be data in a manner acceptable to the order entry system of the stock exchange computer, or else the program could not perform the trade at all. It is also implicit that in the above-mentioned "BUY_GOLD" example, the range of cells in the "SIGNAL" function includes price data. Thus, the example implies that at least some of the data sent to the stock exchange computer is read from the spreadsheet. The Board agrees with the opposition division that the formatting means must also be implicit in order that this data is acceptable to the stock exchange computer order entry system. Thus, the Board judges that, in the Mesa system, formatted spreadsheet data is in fact sent to the stock exchange computer.

7. As with the manner in which the trade is entered, the other aspects that the appellant discusses, such as formatting the spreadsheet data "directly", and not requiring a C-compiler, are not differences reflected in claim 1.

8. Accordingly, the subject-matter of claim 1 of the main request is not new (Article 54(2) EPC).

First and second auxiliary request

9. Claim 1 of the first auxiliary request adds to the main request that the orders are "for trading a basket of shares". The claim thus differs from the Mesa system by this feature. The opposition division and opponent 02 were of the opinion that this feature did not make a technical contribution and could not involve an inventive step. The Board also has doubts that the feature contributes to the technical character of the claimed system. However, in appeal oral proceedings, the respondent switched to what he called the "normal approach" to this feature, namely that it was obvious in any case. In view of this and the fact that the second auxiliary request does add technical details concerning trading a basket of shares, the Board prefers to start with the inventive step of the second auxiliary request.

10. This request further specifies that the formatting involves converting each stock price and volume of the selected groups of data from the spreadsheet into a corresponding variable for insertion into a list of pre-programmed commands which is to be sent to the order entry system of the stock exchange.

11. It is effectively common ground that the object of the additional features of the first and second auxiliary requests is to enable trading a basket of shares. However, as the respondent points out, the Mesa documents mention, in D26 at page 4, last paragraph and D27 at page 47, last paragraph, the possibility of maintaining a stock portfolio. The Board considers that given that the requirement to trade a range of shares in a basket was known, it would be obvious to consider trading the known portfolio as a basket, i.e. to consider solving the above-mentioned problem.

12. With respect to the claimed implementation of basket trading, the Board agrees with the opposition division and respondent that it is also obvious to arrive at a system that falls under the claimed solution. Firstly, the "BUY_GOLD" object in the above-mentioned example must issue a "command" in order to perform a trade. Secondly, this command must contain stock price and volume data as "variables", at least the stock price being read from the spreadsheet as described above. Thirdly, as also mentioned above, the "variables" must be in a form acceptable to the stock exchange computer order entry system, so the formatting means are implicit. Finally, in order to solve the problem of performing multiple trades, it would be obvious to issue a sequence of such "commands". In the Board's view, this would fall under the claimed "list of preprogrammed commands" because there is no basis in the patent for a more detailed interpretation of the list of pre-programmed commands. The description is vague on this point and merely states at column 4, line 48 that the data is extracted from the spreadsheet and "inserted in a list of preprogrammed commands", without further explanation.

13. The appellant argues that the invention allows a trader to enter the desired trading data directly into the spreadsheet. However, the details of how the data relating to the basket trading is entered are neither claimed, nor disclosed (see point 23, below). In any case, the Board considers that it would be an obvious possibility, in order to increase the flexibility of the system, to provide an order entry mask or user interface such as that the appellant refers to, so that trading criteria can be entered without any further programming.

14. Accordingly, the subject-matter of claim 1 of the second auxiliary request, and thus that of claim 1 of the less limited first auxiliary request, does not involve an inventive step (Article 56 EPC).

Third auxiliary request

15. Claim 1 of the third auxiliary request essentially adds to the preceding request the features of controlling the system using a graphic user interface with display means and a mouse. The Board agrees with the opposition division at point 8 of the decision that such control means are well known and disclosed, e.g. in D26 page 23, penultimate paragraph, and that it would be obvious to use them to control the custom application.

16. Accordingly, the subject-matter of claim 1 of the third auxiliary request does not involve an inventive step (Article 56 EPC).

Fourth auxiliary request

17. Claim 1 of the fourth auxiliary request adds to the preceding request that the graphic user interface displays commands which include share symbols, price selections, order size and transaction types.

18. The addition of these features is an attempt to define the nature of the user interface, found missing in the previous requests. However, the Board agrees with the respondent that the features are not directly and unambiguously derivable in connection with trading a basket of shares as now claimed. Firstly, although these features were in original claim 5, the original claims did not contain the feature of trading a basket of shares, so that the combination was not originally claimed. Furthermore, although original claim 1 may have covered both embodiments, it does not support the specific combination of the features of the user interface and trading a basket of shares. Concerning the description and drawings, as mentioned above (see point 3), the claimed commands are displayed in the first embodiment shown in Figure 2, which does not relate to trading a basket of shares. However, the second embodiment shown in Figure 3, which does relate to trading a basket of shares, only shows commands for price selections (44) and transaction types (38-42). The Board cannot find any disclosure of a "command" for the share symbols or the order size. Paragraph [0027] describes a command (36) for identifying the basket of shares to be traded, but not for the share symbols or the order size themselves. Similarly, although in the spreadsheet 30 in Figure 3B, the columns "A" and "B" have the name "SYM" and "SHS", respectively, presumably referring to share symbol and order size, there is no disclosure of any related commands. The same goes for the passage at column 4, lines 37 and 38 that describes displaying share symbol and volume as "information", but not as "commands".

19. Accordingly, the subject-matter of claim 1 of the fourth auxiliary request extends beyond the content of the original application (Article 123(2) EPC).

20. In any case, the Board agrees with the opposition division at point 9 of the decision that these features would not involve an inventive step because it is a matter of routine design to program a graphic user interface according to the specific user's needs, namely those of a stock exchange trading system. Share symbol, price selection, order size and transaction type are all obvious aspects of trade transactions.

Fifth auxiliary request

21. Claim 1 of the fifth auxiliary request essentially adds to the preceding request that the information about the stocks to be traded is represented as a "dynamic data link". Since this request also contains the undisclosed feature of the fourth auxiliary request, it is also not allowable (Article 123(2) EPC).

22. In any case, again the Board agrees with the opposition division at point 10 of the decision that it would be obvious. The description at column 4, lines 42 to 46 states only that the link "causes the spreadsheet to read the list of stocks to the multiple order trading system of the present invention". The Board considers that this can be interpreted to be the same as the function of the Mesa system allowing the custom application to "link right into the data in a worksheet" as disclosed in D26 at page 5, second paragraph. The Board agrees with the opposition division and respondent that dynamic data links are well known, e.g. from D17 at pages 2-1 and 2-4, and that it would be obvious to use them to read data either to or from the spreadsheet, without user intervention, as in the trading examples in the Mesa system.

Sixth to tenth auxiliary requests

23. Claim 1 of the sixth to tenth auxiliary request adds the feature that the user inputs trading data into the spreadsheet. The Board again agrees with the respondent that this feature was not originally disclosed. As discussed in connection with the fourth auxiliary request, only the embodiment shown in Figure 3 is considered to relate to multiple order trading. However, Figure 3A only shows commands that control the system, but not the possibility of entering data into a spreadsheet. Figure 3B shows a spreadsheet with standard spreadsheet functions, but not that any data is actually entered by the user. As mentioned above, the description gives very few details of how the user would enter a trade and nothing about how the user would enter trades into the spreadsheet. The passage at column 2, line 39 states that prices are recorded on the spreadsheet, but not that this is done by the user. Similarly, although the patent states at column 5, lines 21 to 23, that the computer captures all the data necessary to trade from the spreadsheet, there is no unambiguous disclosure that the trading data comes from the user. In fact, the description rather gives the impression at paragraph [0025] that individual data entry is eliminated according to the claimed system. It might therefore be that the trading data comes from somewhere else, such as another program or interface. Consequently, the Board judges that this feature is not directly and ambiguously derivable from the original application.

24. Accordingly, the subject-matter of claim 1 of the sixth to tenth auxiliary requests extends beyond the content of the original application (Article 123(2) EPC).

25. In any case, the Board considers that faced with the problem of increasing the flexibility of the system, it would obvious to program a custom application to enable the user to enter the trading criteria into the spreadsheet.

26. There being no further requests, it follows that the appeal must be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.