T 1059/92 21-09-1993

1. The Appeal complies with Articles 106 to 108 and Rule 68 EPC and is, therefore, admissible.

2. At the commencement of the Oral Proceedings the Board exercised its discretion - under Rule 86(3) by way of Article 111(1) and Rule 66(1) EPC - to admit to the proceedings a new main request containing revised Claims 1 and 2 and to permit amendment of the previous main request, amended Claims 1 and 2 of this request forming an auxiliary request. The discretion was exercised in favour of the Appellant, despite the lateness of the request, because the amendments were at least partly occasioned by comments made by the Rapporteur in the communication dated 16 July 1993. The Board accepted the Appellant's arguments to the effect that although the claims of 18 August 1993 were filed as a response to the Rapporteur's communication, on further consideration it was realised that more extensive amendment was required and that as worded the main claim did not, as regards the derivation of status data, cover all the disclosed embodiments.

3. The only issue in the present appeal is whether the subject-matter of the claims of the main request or of the auxiliary request involves an inventive step.

4. Main request

4.1. The present application is concerned with the control of a collective wiring system, the described embodiment being a multiplexed wiring system for a motor vehicle. Traditionally, electrical and electronic devices used in motor vehicles have been connected by a wiring loom, which is however labour-intensive to produce and of considerable weight. The problem has become more acute with the increasing complexity of electronics in motor vehicles.

4.2. A known solution to the above-mentioned problem is the use of multiplexing; in such a system the various electrical and electronic devices are all connected to either a single pair of cables or to an optical fibre by way of local control units, each device having an address stored in its local control unit. A central control unit receives inputs from the various devices and via the cable or fibre causes other devices to be actuated in response. One example of such a system is known from published Japanese patent application 106666/83, acknowledged in the introduction to the description and published in the English language as GB- A-2 142 175 before either of the priority dates claimed for the application in suit.

4.3. The application is concerned with a problem arising in multiplexing systems from the increasing complexity of automotive electronics, namely ensuring the speedy processing of information to or from the individual devices; in other words, the processing capacity of the central control unit must be sufficient to avoid delayed control action. A further, related, aim concerns the need to ensure that particular control functions operate in response to predetermined logic conditions; an example of such a condition, given in the application as filed, is when actuation of a rear window defroster switch does not cause the defroster to be turned on unless the ignition key switch is also on, an AND function thereby being involved. On the other hand, operation of the interior lamp of a motor vehicle is usually an OR-related function, the lamp being turned on when any door is opened.

4.4. Claim 1 of the main request is directed to a method of control of a collective wiring system and acknowledges as known the use of a central control unit receiving input data from a plurality of local control units by means of which vehicle devices are monitored and controlled. The Claim includes, in essence, the following characterising features:

(a) Communication interface modules (CIMs) which are part of the central and local control units and which control the transmission and reception of data independently of the actual workload of the central control unit CPU;

(b) The central control unit controls the addresses of input and output devices "in a software fashion in a repetitive manner"; this is an indirect reference to the use of a wiring logic table to determine the relationship between the input and output devices;

(c) The order in which data is transmitted from the central control unit via the communication interface modules to the local control units is stored in the scan table in a first memory;

(d) Data from the local control units is stored in a second memory in a status table (referred to in the description as a monitor table);

(e) The CIMs are scanned cyclically, status data being stored in the status table [see (d)] and output data in the form of control commands being supplied from a control table in the second memory.

4.5. Turning now to the prior art, D1 discloses in accordance with the preamble of Claim 1 a method of control of a collective wiring system in which a central control unit (see Figure 2) receives input data by way of a common data transmission system ("data bus", Figure 2) from a plurality of local control units (Figure 4) and generates the appropriate output data. From Figures 2 to 4 and the associated text it can be seen that both the central and local control units comprise a microcomputer connected to the data bus by a serial input/output buffer; the central control unit is said at page 224, right hand column to comprise a 2k byte EPROM and a 256 byte static RAM. There are said to be five interrupt levels, although their function is not explained; Figure 3 shows that control of data on the data bus is interrupt-driven. An interrupt routine is said to be invoked by the timer every 750µ seconds, the text stating that this routine "effectively runs in parallel to the main program". In the Board's opinion this reference indicates that the transmission and reception of data is controlled independently of the actual workload of the central processing unit. It is observed that in communication applications - of which the present application is an example - interrupt routines are standard and indeed essential to efficient operation. The transmission and reception of data is by way of a serial input/output buffer which, as noted above, acts as an interface between the central control unit microprocessor and the data bus. The Board accordingly considers that this buffer, shown as a separate unit in Figure 2 of the drawings of D1, constitutes a communication interface module in the same sense as used in Claim 1 and that the data handling involves interrupt routines such that the transmission and reception of data is independent of the actual workload of the CCU CPU; feature (a) of Claim 1 is accordingly known from D1.

4.6. Feature (b) refers to sensor and output addresses being "controlled in a software fashion in a repetitive manner" in the central control unit. The meaning of this expression is not wholly clear to the Board but it is noted that it replaces the reference to a "connection table" in Claim 1 of the previous main request and is said to be supported by the paragraph bridging pages 5 and 6 of the originally filed description. This paragraph refers to the relationship between input and output devices being "controlled in a software fashion from time to time, especially, by the use of a table of data stored in memory". The Board therefore understands feature (b) to mean that a relationship exists between the input and output devices which is determined by unspecified software: in the preferred embodiment this is a ROM look-up table referred to as the "wiring logic table" which is periodically scanned.

4.7. D1 states at page 225, left hand column, that one of the tasks of the main program loop is to provide "formatting commands for control of peripherals according to systems input status and the logic functions that govern each peripheral ... commands associated with each peripheral are stored in ROM". Examples of AND and OR functions are given. D1 thus clearly provides software which relates input to output devices. In D1 the devices are polled cyclically, i.e. called up in a repetitive manner, the interrupt routine being invoked by the timer every 750µ seconds. The Board considers that this implies that the addresses of the input devices are polled in turn, one of the task of the main program loop being to provide driving displays based on information from analogue sensors and in the event of a peripheral fault to display the fault. The Board accordingly considers that the skilled man would appreciate that the disclosure of D1 requires an arrangement as specified in feature (b) of the Claim.

4.8. Furthermore, a polling mode requires separate addresses to be scanned in turn. One simple manner of doing this would be to provide a counter and to count up in sequence; this has the disadvantage of requiring all devices to have consecutive addresses. The method provided in accordance with feature (c), the use of a scan table containing the addresses and counting consecutive scan table locations to provide the count, is an obvious alternative; it was at the claimed priority date well known in the art that arithmetic functions could be carried out by means of ROM look-up tables and the use of a ROM to provide addresses is merely an example of such a look-up table which the skilled man would make use of if he were faced with the problem of non-consecutive addressing of peripheral devices.

4.9. According to page 225, left-hand column, of D1 processing data returned to the central control unit from local control units is stored ready for processing in RAM. Feature (d) is thus known from D1.

4.10. As noted at paragraphs 4.7 and 4.8 above the system of D1 requires periodic polling of the local control units by the central control unit. The first part of feature (e), the updating of the status table, is implicit in feature (d). As regards the supply of control commands to control the operation of output devices on the basis of data stored in a control table in the same memory as the status table, it is noted that page 225, left-hand column, of D1 states that "Once the desired state of a peripheral is determined, the appropriate command is stored in RAM prior to transmission". This feature is accordingly known from D1.

4.11. Accordingly, it follows that the subject-matter of Claim 1 of the main request does not involve an inventive step having regard to the disclosure of D1.

4.12. D1 refers to "logic functions that govern each peripheral" and gives as examples the AND and OR functions. The commands associated with each peripheral are said to be stored in ROM. It therefore follows that the logical relation between source and destination peripherals, the first feature of Claim 2 must be stored in ROM; whether this storage is in memory areas corresponding to individual devices or to logical functions such as AND and OR functions, the second feature of Claim 2 has no effect on the operation of the system and is merely a matter of choice on the part of the skilled man which does not involve the exercise of invention. The subject-matter of Claim 2 of the main request accordingly also lacks an inventive step having regard to the disclosure of D1.

5. Auxiliary request

5.1. Claim 1 of the auxiliary request differs in substance from that of the main request only as regards feature (b), which in the auxiliary request explicitly refers to the addresses of the input and output devices being "stored and logically related in a connection table". As noted at paragraph 4.6 above the use of such a table is implicit in the D1 arrangement. The subject-matter of Claim 1 of the main request having been shown to lack an inventive step, the arguments at part 4 above apply mutatis mutandis to Claim 1 of the auxiliary request.

5.2. Claim 2 of the auxiliary request is in substance the same as Claim 2 of the main request and is open to the same objection of lack of inventive step as Claim 2 of the main request.

6.1. Turning now to the arguments advanced by the Appellant in support of patentability, the use of tables for storing data is as noted above clearly known from D1. At the oral proceedings much stress was laid on the use of the communication interface modules in order to reduce the load on the central control unit CPU. However, the nature of these devices was not made clear. The reference to a "communication interface" suggests a buffer is being claimed. Mere input/output buffering - whether in the form of a UART or a dedicated buffer designed to operate with a specific microprocessor, often referred to as a "versatile interface adaptor" or "peripheral interface adapter" - was common general knowledge at the claimed priority dates. The preferred embodiment of the communication interface module shown at Figure 5 of the application appears to be an input/output buffer combined with a serial to parallel converter. Such combined devices were also known in the art at the claimed priority dates. Indeed, one example of such a device is given in the Appellant's own prior art, Japanese application No. 106666/83, referred to at paragraph 4.2 above. Reference was made in the oral proceedings to the English language equivalent, GB-A- 2 142 175, in which use is made of communication interface modules in a multiplexed wiring system for a motor vehicle; the communication interface modules of this document apparently operate in the same manner and serve the same function as those of the present invention, thus making clear that the principle of their use was known before the claimed priority dates.

6.2. It was also argued that the serial input/output buffer of D1 did not constitute a communication interface module since it merely passed serial data to and from the microprocessor, only a single wire connecting the buffer with the microprocessor in Figure 2 rather than a data bus. Reference was directed to page 226, right-hand column, which states that "Throughput of the system is limited by program execution speed, since all serial I/O functions are performed by software". The Board accepts that this passage indicates a serial output from the microprocessor, slowing down the system considerably. However, neither Claim 1 of the main request nor that of the auxiliary request include any feature which can be taken to limit either the operation of the central control unit or that of the communication interface modules exclusively to a parallel data bus. Even had such a limitation been included the Board would not have changed its view, given that at the claimed priority dates parallel data buses were the norm and were known to be faster than serial data buses. The skilled man, were speed a problem in the system of D1, would appreciate that it could be speeded up by the use of a parallel data bus and corresponding buffer.

6.3. A further, related, point raised by the Appellant concerned the question of whether in D1 transmission and reception of data is controlled independently of the workload of the central processing unit. It was asserted that Figure 3 of D1 showed that the interrupt function involved the use of main program segments since control was not returned to the same program block as at the start of the interrupt. It was moreover stated that since the interrupt was driven by a clock it was not a true interrupt. The reference in D1 to five interrupt levels was also taken as an indication that D1 did not provide what the Appellant referred to in the oral proceedings as "parallel processing", but that it regarded different data inputs as having different levels of importance. The Board is unable to agree with these assertions. The text of D1 makes clear that the interrupt "runs in parallel to the main program" (page 225, left-hand column), the local control units similarly having "a main program loop and a parallel interrupt routine" (page 225, right-hand column). Nowhere does D1 suggest that different inputs are processed in different ways. Secondly, in any multiplexing system of the kind used by both the application and D1 a clock is essential and indeed it is noted that the application also causes interrupts to take place under the control of a timer at pre- determined times. Finally, neither the application nor D1 discloses what is normally understood by "parallel processing". Although the Appellant provided information purporting to show machine states for the CPU of the application and that of D1, the former apparently taking up much less time for I/O processing than the latter, it was not possible to relate this information to any claimed feature or indeed to any described feature.