T 1251/08 (Serial bus simulation / TERADYNE) 29-06-2012

1. The admissibility of the appeal

In view of the facts set out at points I, III and IV above, the appeal is admissible, since it complies with the EPC formal admissibility requirements.

2. The appellant's request for a telephone interview with the rapporteur and an explanation of the board's provisional opinion

2.1 In the telephone call with the rapporteur on 8 June 2012 the appellant's representative essentially requested a telephone interview with the rapporteur to discuss the allowability of certain requests on file. Although the request for an interview was not allowed, the representative nevertheless requested in a further telephone call with the rapporteur on 20 June 2012 an explanation of the board's provisional opinion on the requests on file.

2.2 As established in the case law of the boards of appeal, as a matter of principle, the EPC foresees the absolute right to oral proceedings under Article 116(1) EPC 1973, but not the right to a telephone interview (cf. Case Law of the Boards of Appeal of the EPO, 6th edition, 2010, VII.B.2.7.2 concerning the department of first instance, in particular). As to appeal proceedings more specifically, Articles 4 and 5 RPBA (Rules of Procedure of the Boards of Appeal of the European Patent Office, OJ EPO 2007, 536, the wording of which remains unchanged after the entry into force of EPC 2000) provide that certain steps in the proceedings may be taken by the rapporteur. Where this is the case the rapporteur's duties consist of either ensuring, under the board's supervision, that the procedural rules or the directions of the board of appeal are complied with by the parties, or, where it comes to substantive matters (Article 5(3) RPBA), of acting on behalf of the board. This, in other words, implies that the other members of the board have been informed and put in the position to give an informed opinion on the action to be taken. To this end it is important that the same case is presented to all of the board's members. If one of the board's members were privy to evidence or arguments not available to the other members then this would be a breach of the principle of collective decision making and would be in conflict with Article 21 EPC 1973; see T 1109/02 (not published in OJ EPO, reasons, point 1) and T 0263/07 (not published in OJ EPO, reasons, point 2.1 to 2.3).

2.3 Since the requested telephone interview and the enquiry regarding the reasons for the board's provisional opinion on the requests could have led the rapporteur to take a position on an issue where a collective decision would have been required, or to commit the board without preliminary discussion, both requests were refused as not being compatible with the above mentioned principle and rules governing appeal proceedings.

3. A further communication by the board after the summons to oral proceedings was not necessary and had also not been requested by the appellant. Under Rule 100(2) EPC (corresponding to Article 110(2) EPC 1973 in conjunction with Rule 66 (1) EPC 1973) the board shall invite the parties "as often as necessary" to file observations. In the present case oral proceedings were arranged as requested by the appellant and because it was the most efficient procedural course of action to be taken at this stage.

4. The telephone call by the representative on the day before the oral proceedings

The board wishes to avoid giving the impression that it finds that it is never appropriate for parties in ex parte proceedings to telephone the rapporteur. Leaving aside the question of whether it is appropriate to file new requests on the day before an oral proceedings, the representative's telephone call on the day before the oral proceedings to advise the board that several late requests were being filed by fax assisted the board in conducting these proceedings in an orderly manner. The board was consequently at least in a position to ensure that the late submission was distributed to the whole board as soon as possible.

5. The context of the invention

The application relates to the testing of serial buses in which the communications protocol used on the bus is represented in the test equipment by a multi-layered generic bus model, the layers corresponding, for instance, to words, fields, symbols, sequences of symbols, encoding/decoding, timing and the wave shape. In particular, one layer concerns the physical layer, i.e. the bus hardware dealing with voltages and currents. The layers correspond to mirror-image temporal chains of data processing steps for the case of transmitting and receiving data; see figure 3. The model also includes non-data support signals, such as handshaking signals used when data transmission commences or ceases. The layers are processed in parallel by separate processors (termed "components" in the claims), whereby the processors may be hardware, software, or a combination of the two. For instance, each processor may be implemented as a separate thread in a multi-threaded computer system. The bus model may be set up to correspond to predefined bus standards, such as RS232, or may be user-defined. In the context of bus testing, faults may be injected into the model by varying an adjustable setting for configuring a processor, and faults may be detected by comparing the resulting input data to a processor with the expected input data. The processors may also contribute data to and access data from an event bus, an event being, for example, the beginning of a field or the end of a transmitted word.

6. The admittance of the second and third requests into the proceedings

6.1 The question of the admittance of these requests, received on 29 May 2012 and in the oral proceedings on 29 June 2012, respectively, turns on whether the board allows the corresponding amendments to the appellant's case, Article 13 RPBA. According to Article 13(1) RPBA, any amendment to a party's case after it has filed its grounds of appeal or reply may be admitted and considered at the board's discretion. The discretion shall be exercised in view of inter alia the complexity of the new subject-matter submitted, the current state of the proceedings and the need for procedural economy. Under Article 13(3) RPBA, amendments sought to be made after oral proceedings have been arranged shall not be admitted if they raise issues which the board cannot reasonably be expected to deal with without adjournment of the oral proceedings.

6.2 The claims according to the second auxiliary request are a clean copy of those previously on file with the claims renumbered to be consecutive and were filed in response to the board's request to do so. The amendments made the claims easier to understand.

6.3 The claims according to the third auxiliary request have been amended with respect to those of the second auxiliary request by deleting all the method claims, deleting the term "emulating" from claim 1 and adding features to restrict claim 1 based on original claim 28, page 13, lines 17 to 24, and figure 6 (event bus) and page 10, lines 18 to 19 (hardware processor). The board is satisfied that the amendments are directed to overcoming the doubts expressed by the board in the annex to the summons to oral proceedings regarding support by the description, Article 84 EPC 1973, and lack of inventive step, Article 56 EPC 1973. The limited extent of the amendments was such that the board was readily able to assess their effect without adjournment of the oral proceedings.

6.4 Hence the board admitted the second and third auxiliary requests into the procedure.

7. The allowability of the main and first and second auxiliary requests

7.1 Claim 1 of all these requests sets out inter alia a system for "emulating" different types of serial buses.

7.2 In the annex to the summons to oral proceedings the board stated inter alia that, according to the normal meaning of the word "emulation", a system which emulated a bus would have to reproduce the behaviour of a bus. In other words, it would have to transmit (or if "emulation" was taken loosely, simulate the transmission of) data from place to place, and emulate properties such as signal delay, degradation, echoes, noise, etc. This was not what was disclosed by the application. Rather it disclosed the emulation of a device which may be attached to a serial bus. Insofar as claims were directed to a system for emulating different types of serial buses, it appeared that they did not satisfy the requirements of Article 84 EPC 1973 regarding support by the description. The board noted that the statement of grounds of appeal also referred to the invention as being a "serial bus tester", which appeared to be a more appropriate designation.

7.3 The appellant has argued that the description disclosed the emulation and testing of serial buses, that emulation included a device attached to a bus and that a serial bus tester, in particular those parts which generated a "waveshape" (see page 8, lines 24 to 27), emulated the properties of the bus. Moreover the description mentioned the injection of errors into the chain of data processing steps; see page 11, lines 19 to 22, and page 14, lines 6 to 33. The bus was also a channel having a delay and could therefore emulate effects such as noise and Rayleigh fading.

7.4 The appellant's arguments have not convinced the board. While the multi-layer generic protocol model disclosed in the description and figures, in particular figure 3 and page 8, line 9, to page 10, line 8, can emulate the behaviour of a device attached to a serial bus, there is no disclosure of emulating the behaviour of the bus itself. The injection of faults in the communication protocol and the generation of the "waveshape" mentioned in the description are insufficient to disclose the emulation of bus behaviour such as, for instance, tolerances, overvoltages, overcurrents, channel fading and non-linear effects such as buffer saturation. Given a predefined bus input waveform, a bus emulator would yield the corresponding bus output waveform after the bus behaviours being emulated had taken their effect. Such an emulator is not disclosed in the application.

7.5 The board concludes that the term "emulating", applied to serial busses in claim 1 of all three requests, is not supported by the description, Article 84 EPC 1973, and that therefore none of the three requests is allowable.

8. Document D3

8.1 D3 concerns a digital testing device for testing or simulating communication systems involving a standard or a user-defined protocol; see page 3, lines 10 to 12. The device can also test the operation of a particular protocol; see page 9, lines 17 to 19. As shown in figure 1, the device is implemented on a computer (which can be a general-purpose computer or dedicated digital device; see page 4, lines 21 to 22) which can be connected by an interface cable to the system under test. As shown in figure 3, the system under test is linked to the "virtual protocol model core" by the "device interface object", which is "preferably hardware independent"; see page 6, lines 9 to 16. An output unit filters the output data for interpretation by the user, the system allowing the configuration of user-defined filters. The virtual protocol model core has three descendant objects - a protocol designer, a protocol simulator and a protocol analyzer - which will now be considered in turn.

8.2 Using the protocol designer the user can define a new protocol by applying the object-oriented principles of inheritance and encapsulation based on the generic "virtual protocol model core"; see page 5, lines 3 to 9, 18 to 19 and 32 to 33. Figure 4 shows a multilayer protocol model based on the OSI's layered model represented as a tree structure. Figure 5 gives an example of the TCP/IP protocol in the "protocol designer". Figure 7 shows a physical interface being selected during protocol design, and figure 9 shows a logical channel having a protocol and a physical interface.

8.3 The protocol simulator allows for the simulation of any protocol or device. If simulation is being carried out then the data interface is not required; page 6, lines 31 to 32. According to page 9, lines 19 to 21, "In the testing object, data is obtained from the interface, however, in the simulation object, data is produced, either at random or in a predetermined manner. The remainder of the operation is identical."

8.4 The protocol analyzer allows for analysis of any protocol added to the protocol core. In an analysis mode real time data is captured by the interface; see page 8, lines 31 to 32. The capture filter only looks for certain key features of interest to the user; see page 9, lines 12 to 14.

8.5 The model core can be data frame orientated; see page 6, lines 11 to 13. The model also supports any field, this being defined as covering "a data pattern, ranging from a single bit to an endless chain of bit-data"; see page 7, lines 17 to 19. According to page 8, lines 13 to 15, "The protocol requires a definition of the data fields of a data packet and a series of nodes define open flag, message format connect, message format disconnect, data and close flag data fields." Figure 10 shows captured data bytes fitted into the fields of the protocol of figure 9; see page 9, lines 6 to 7.

8.6 The appellant has argued that D3 does not disclose a system for emulating different types of serial buses. The board is not convinced by the appellant's arguments. Firstly, in the board's view, D3 is concerned with emulating a bus to the same extent as the present application is, in that it discloses a system for emulating a device to be attached to a bus (see point 7, above). Secondly, the board agrees with the finding in the appealed decision that figure 7 and page 8, lines 17 to 24, disclose the user choosing between various serial bus interfaces so that the generic core model mentioned on page 5, lines 26 to 27, which is hardware independent and can be adapted to any bit orientated data pattern, can be considered as a generic serial bus model. Figure 7 shows a choice of interface objects: "Network", "Asynchronous serial", "E1/T1" and "Sync/HDLC". At least "Asynchronous serial" and "E1/T1" concern serial interfaces ("HDLC" is an OSI Link Layer protocol, frequently but not necessarily used over a serial bus). Figure 8 also mentions the RS232 series of standards for serial bus protocols; see directory name. RS232 is also referred to in the description of the application on page 4, lines 9 to 11. It follows that, contrary to the appellant's argument, the system known from D3 device can emulate different types of serial buses.

8.7 The appellant has also argued that D3 does not disclose separate components processing layers of the protocol model in parallel. The board does not agree. The application uses the term "parallel" functionally rather than merely structurally. In the application the protocol layers are implemented by independent processors working "in parallel" (see page 10, lines 32 to 33) which can be "a separate thread in a multi-threaded computer system"; see page 11, lines 24 to 25. In the same way the "Virtual protocol model" core 40 and the "CoMPA Device Interfaces" 48 constitute separate layers processed in parallel, it being implicit in D3 that, in order for the system shown in figure 3 to be capable of dealing with input and output signals continuously, the virtual protocol model 40 and the device interfaces 48 must work "in parallel", in a manner comparable to the protocol layers of the application. The appellant has argued that the virtual protocol model core and the device interface object in D3 are not threads, executables or processes, but merely objects. Whilst this may be so, the skilled person reading D3 would understand that these objects require processing, as set out in the claims, to implement the system.

8.8 The appellant has argued that D3 only uses its model for bus monitoring (receive-only) rather than for testing (transmit-receive), meaning that D3 does not disclose the digital testing device transmitting data. The board has not been convinced by this argument for two reasons. Firstly, page 9, lines 17 to 21, refers to entering the simulation mode to generate data before beginning the test of a particular protocol. It may be true that, as the appellant has argued, in D3 in the simulation mode itself no data are transmitted. Transmission does however occur subsequently in the testing mode so that the device known from D3 is capable of data transmission to the device under test. Secondly, the device interface not only obtains data from the equipment under test it also returns data to the equipment under test; see page 6, lines 26 to 28. The appellant has objected that this is the only mention in D3 of data transmission and that there is no further disclosure of its implementation and no way of confirming its intended meaning. The board takes the view that the meaning intended by the author of D3 is not decisive in this case, but rather the understanding of the skilled person reading D3. There is also more than one disclosure of data transmission in D3. Figure 3 shows arrows in both directions between the "system under test" and the "CoMPA Device Interfaces" which the skilled person would understand as disclosing inter alia the transmission of data from the interfaces to the system under test. This interpretation is confirmed by the reference on page 6, lines 26 to 28, to the interfaces returning data to the system under test. The appellant has argued that this expression is qualified by the expression "as part of a simulation" to exclude the transmission of data. The board disagrees, since it understands a "simulation" in this context to mean that the digital test device simulates a device on the serial bus, receiving data from the system under test and transmitting responses to the system under test, thus involving the transmission of data by the digital testing device.

8.9 The appellant has argued that D3 does not disclose a programmable physical layer. The board disagrees. Figure 3 shows that the virtual protocol model 48 sits on top of the device interface 48, this being considered to be a physical layer even if the device interface object is not included in the layer model. It is common ground between the appellant and the board that D3 does not explicitly mention operating on voltages, currents and wave shapes. The board however regards such operations as implicit in the protocol designer allowing the user to choose between different predefined interface standards, shown in figure 7. According to page 6, lines 10 to 11, "a specific interface object appropriate to the system under test ... is selected". This amounts to programming the physical layer. Hence the skilled person reading D3 would understand that the intention is to adapt the "general-purpose computer" or "dedicated digital device" (see page 4, lines 21 to 22) to analyze the extracted data, implying, contrary to the appellant's argument, that the D3 device can manipulate physical layer data elements such as voltage levels and waveform shape. This is also necessary in order for the digital testing device, even if implemented using a general purpose digital computer, to interface with the "physical layer" of the system under test.

8.10 The appellant has also argued that the device known from D3 is limited to predetermined protocols. The board disagrees in view of the protocol designer shown in figures 5 and 6 and described on page 8, lines 11 to 16, which allows a user to define a new protocol.

8.11 The appellant has argued that the device known from D3 cannot construct and analyze a protocol in real time, particularly in view of the reference to returning data to the system under test as part of a simulation; see page 6, lines 26 to 28. The board does not accept these arguments. Firstly, as set out above, the board understands "simulation" in this context to mean that the digital test device simulates a device on the serial bus, receiving data from the system under test (implying protocol analysis) and transmitting responses to the system under test (implying protocol construction). Secondly, the board finds that the skilled person, reading the references in D3 (see page 6, lines 26 to 28) to obtaining data from and returning data to the system under test, would understand these references to imply real time communication with the system under test, in other words real time protocol analysis and construction.

8.12 It is common ground between the board and the appellant that D3 does not disclose handshaking, clock, sync or envelope signals. While some implementations of the UART protocol commonly associated with RS232 do use handshaking, other implementations do not. It is thus not directly and unambiguously derivable from D3 that the protocols involve handshaking.

8.13 The appellant has also argued that D3 does not mention injecting a fault or signalling a failure. The board agrees with the appellant regarding injecting a fault, but disagrees regarding signalling a failure. The reasons for the appealed decision cited the configuration of the protocol and physical interface (see D3, page 8, lines 13 to 16 and 19 to 21) as disclosing the claimed "adjustable setting". There is however no disclosure in D3 of continuously reselecting the protocol or physical interface to inject a signal into the bus data. Turning to the feature of "signalling a failure", the reasons for the appealed decision argued that D3 disclosed means for signalling a failure, as it was used for testing. The board is not convinced by this argument, since testing can be understood as merely measuring values, whilst signalling a failure requires the comparison of the measured performance with criteria defining a "failure". This however raises the question of what is, technically speaking, a "failure" in this context. This term can be understood to mean a predetermined output, the detection of which is known from the capture filters in D3; see page 9, lines 12 to 14. In this sense D3 does disclose signalling a failure.

8.14 The board does not accept the appellant's argument that D3 only allows variation in the data field and only foresees triggering or filtering based on data. It is common ground between the board and the appellant that the generic protocol models used in the application and D3 both imply a limitation of the protocols which may be implemented to those which comply with the respective model. However the board does not accept the appellant's argument that in D3 only the data field can be varied and triggering or filtering can only be based on data. The protocol designer in D3 allows a user to vary numerous parameters of the protocol other than the data field (see figures 4 and 5) and to define filters and triggers to respond to any user-defined aspect of the protocol; see page 5, lines 11 to 14.

9. Document D1

9.1 The 2108 device described in D1 is a serial bus emulator comprising preprogrammed standard serial bus protocols, but also allowing new protocols to be defined; see page 1-1, paragraph 1. The device comprises a VXI controller (running on a PC; see page 1-1, paragraph 1.2) connected via UUT (Unit Under Test) interconnect modules to transmit-receive modules; see figure 3-6 on page 3-6 and figure 4-1 on page 4-1. The device also comprises a serial logic analyzer application; see page 1-1, paragraph 1.2. It can also generate and record serial data; see page 4-1, paragraph 4. The 2108Tx transmitter can be used to inject errors; see page 1-1, paragraph 1.3. Variable voltage drivers in the transmitter interconnect modules can be programmed for a wide range of signal levels; see the sentence bridging pages 1-1 and 1-2 and the reference signals CnREF0-8 on page 4-2, first two lines.

9.2 The board finds that at the priority date the injection of faults to test a serial bus was, as the decision argues, a matter of common general knowledge in the art of protocol testing devices, D3 lying in this field, and is known, for example, from D1; see page 1-1, paragraph 1.3, lines 3 to 4.

10. The third auxiliary request

10.1 The technical character of the protocol stack layer definitions set out in claim 1.

According to the appealed decision, the elements of the generic communication protocol stack, for instance the terms in the claims "communication layer", "process" and "component", were abstract concepts having no impact on the technical effect of the product implemented by means of the protocol stack and thus lacked technical character, since there was no interrelation with concrete technical features of the invention. The board is not convinced that the features of the protocol stack, or means for implementing them, at least insofar as they relate to separate processes running in parallel, can be dismissed as lacking technical character. As the description states (see page 8, lines 2 to 3), the layers form a somewhat arbitrary division between tasks. However the organisation of tasks in a bus communication protocol relates to solving the technical problem of data communication over a bus. The board finds that in this context each such "task" has technical character.

10.2 Novelty, Article 54(1,2) EPC 1973, in view of D3

10.2.1 In view of the above analysis of D3, the board regards the "Virtual protocol model" core 40 and "CoMPA Device Interfaces" 48 shown in figure 3 as the claimed separate components. Hence, in terms of claim 1 of the third auxiliary request, D3 discloses:

a system for testing different types of serial busses, comprising: a plurality of separate components for parallel processing different communication layers of a generic serial bus model, wherein the generic serial bus model breaks down a serial bus into the different communication layers, the communication layers being chained in a sequence, wherein each of the plurality of components handles a different communication layer, wherein at least one component is adapted to process a physical layer, wherein at least one component is adapted to process voltage or current levels, wherein said components being connected according to said sequence, each of the plurality of separate components is arranged to receive data at a data input, perform processing steps on the data, and output data at a data output, and wherein each of the plurality of separate components has at least one adjustable setting for configuring the component for interacting with different types of serial busses to control individual characteristics without affecting other characteristics, wherein at least one of the plurality of components further comprises a record of at least one expected behavior of data received at its data input, and means for signaling a failure responsive to actual behavior of its input data not matching expected behavior of its input data.

10.2.2 Hence the subject-matter of claim 1 differs from the disclosure of D3 in the following features:

- means for injecting a fault by varying the at least one adjustable setting,

- the communication layers comprising at least some of the following layers: word layer, field layer, symbol layer, sequence of symbols layer, encoding/decoding layer, timing layer and wave shape layer;

- further comprising a plurality of hardware processors, wherein one processor of the plurality of hardware processors is used for one of the components; - an event bus for communicating events among different ones of the plurality of processors, wherein each of the plurality of processors is adapted to contribute one or more of its outputs to the event bus and each of the plurality of processors having access to the entire event bus.

10.2.3 The subject-matter of claim 1 is consequently novel with respect to the disclosure of D3, Article 54(1,2) EPC 1973.

10.3 Inventive step, Article 56 EPC 1973

10.3.1 The appellant has argued that the advantages listed on pages 10 and 11 of the description could only be achieved with hardware processors. Moreover the event bus had the advantage that if one of the processors detected a fault this was put on the bus so that other devices could be controlled. Furthermore none of the prior art documents on file disclosed an event bus or its advantages. For instance, D3 dealt with testing a communications protocol, rather than testing a serial bus. The appellant maintained that D3 did not disclose parallel processors.

10.3.2 The board notes that it is not immediately clear from the documents on file that the subject-matter set out in claim 1 does not involve an inventive step, Article 56 EPC 1973, in particular since claim 1 now sets out an event bus receiving contributions from and being accessed by the plurality of processors. However it is equally not immediately clear that there is an inventive step, since resolution of this issue might require, for example, further search. This being the case, remittal for further examination would appear to be appropriate. The appellant has stated that it regards remittal as an acceptable outcome.