T 1301/07 (Communication technique for field devices/ROSEMOUNT) of 3.3.2010

Summary of Facts and Submissions

I. The present appeal arises from the decision of the opposition division posted on 30 May 2007 revoking European Patent No. 1023650 on the grounds of lack of novelty with respect to

M14: Knizak M. et al.: "Applying Internet Management Standards to Fieldbus Systems", Proceedings of the 1997 IEEE International Workshop on Factory Communication Systems, Barcelona, 1.-3.10.1997

II. An appeal was filed against this decision by the patentee (appellant) with letter received on 24 July 2007. The appropriate fee was paid on the same day. The corresponding statement of grounds was filed on 9 October 2007. It was requested that the board of appeal set aside the appealed decision and maintain the patent on the basis of claims 1-21 of the request submitted on 25 January 2007 on which revocation was ordered. Oral proceedings were requested as an auxiliary measure.

III. Opponent II (respondent II) replied with letter received on 8 February 2008 and further letters received on 2 April 2008 and 3 February 2010. Dismissal of the appeal was requested. As auxiliary measures remittal to the opposition division and oral proceedings were requested.

Respondent II inter alia maintained and argued lack of novelty or at least lack of inventive step with respect to the teaching of M14.

IV. Opponent I (respondent I) replied with letter of 26 February 2008. Dismissal of the appeal was requested. Respondent I inter alia referred to the arguments of Respondent II concerning objections as to a lack of novelty or at least lack of an inventive step.

V. In a communication of 13 November 2009 pursuant to Article 15(1) of the Rules of Procedure of the Boards of Appeal, accompanying a summons to oral proceedings, the board raised matters to be discussed at the oral proceedings, inter alia with respect to inventive step, and gave its preliminary opinion.

VI. At the oral proceedings, the parties confirmed their previous requests. At their end, the chairman announced the board's decision.

VII. Claim 1 in the version on which revocation was ordered reads as follows:

"A process device (74) adapted to couple to a process control loop, the device comprising:

loop interface circuitry (70) coupled to the process control loop to send and receive loop signals on the process control loop; and

a regulator circuit (68) which wholly powers the process device (74) with power received from the process control loop; and

characterised by further comprising:

processor circuitry (66) coupled to the loop interface circuitry and adapted to format sensor data in accordance with a public Internet protocol thereby producing public Internet-compatible data,

the processor circuitry (66) being further adapted to provide the public Internet-compatible data to the loop interface circuitry (70) for subsequent transmission upon the process control loop;

a memory (62) coupled to the processor circuitry

and adapted to store data related to public Internet communication and to contain an internet address of the process device formatted in accordance with a public Internet protocol; and

wherein the loop interface circuitry (70):

is adapted to format the public Internet-compatible data for transmission upon the process control loop

and to transmit the formatted public Internet-compatible data upon the process control loop; and

is configured to receive data packets from the process control loop which contain the internet address

and to transmit data packets on the process control loop which include the internet address."

Reasons for the Decision

1. Novelty and inventive step (Articles 54 and 56 EPC):

1.1 The patent in suit relates to industrial process control and in particular to field devices used for fluid control (paragraph [0001]). The invention is aimed at realising a field device with a network connection to the internet (paragraph [0008]) and which is powered from the network. As such, the field device is able to safely communicate over a field bus in an energy limited fashion, including data which represent the internet address of the device. The address is then directly available outside a protected area (column 7, lines 33-40 of the patent in suit).

1.2 It was common ground between the parties that document M14 represented the closest prior art. M14, as in the patent in suit, relates to the integration of a field bus into a management framework using the internet (see abstract).

The field bus systems considered in M14 (also denoted as field area networks or FANs) comprise a number of nodes (page 309, left column, "Introduction", first paragraph) which correspond to the process devices in the language of claim 1. These nodes are adapted to couple to a process control loop which corresponds to the field bus system lines 72 and 86 as shown in Figures 4 and 5 respectively. The nodes necessarily comprise loop interface circuitry coupled to the process control loop (the field bus system lines) in order to be able to send and receive loop signals on the process control loop. Sending and receiving messages on the field bus is also further discussed for example on page 313, right column under "IP Encapsulation".

It was not contested by the appellant that known field buses such as the "Profibus" mentioned in the abstract of M14 comprise a regulator circuit at their nodes (i.e. the process devices in the language of claim 1) which wholly powers the node with power received from the process control loop. The skilled person would therefore understand that this feature is part of the field bus system of M14.

According to page 313, right column under "IP Encapsulation", the nodes comprise an "agent" to run a "Simple Network Management Protocol" (SNMP) stack which, according to the text, requires additional computing power. The nodes thus necessarily comprise processor circuitry coupled to the loop interface circuitry for running the SNMP stack in order to provide the required computing power.

Objects managed by the field bus comprise for example temperature and light sensors, see Table 1 on page 314. The processor circuit is thus adapted to format sensor data.

Implicitly the nodes (the process devices in the language of the claim) must comprise a memory coupled to the processor circuitry and adapted to store the device's address data, in order to combine it with the sensor data sent over the field bus (see point 1.7 below).

1.3 The remaining features of claim 1 are not explicitly disclosed in M14.

They relate to what is commonly understood as "encapsulation" of internet compatible data for transmission on the field bus, the term "encapsulation" normally being used by the skilled person in the sense that the internet packets remain intact for transmission over the field bus and are preceded by a process control loop header (see Figure 7 and paragraph [0059] of the patent in suit).

It was however argued by the appellant that the term "encapsulation" encompassed a protocol conversion at a proxy at the internet/process control loop connection, e.g. replacement of the TCP/IP packet headers by a process control loop header, and that this understanding of "encapsulation" would be understood by the skilled person as what is meant in M14.

1.4 M14 discloses encapsulation of internet data (page 313, right column, paragraph "IP Encapsulation"), but does not however state explicitly how the term "encapsulation" is to be understood.

On the one hand, encapsulating data packets of one system within the packets of the other is said to amount to using the foreign (i.e. internet) protocol only as a transport medium (page 313, left column, paragraph "3.2 Proxy Levels", second sentence). Furthermore, IP messages encapsulated into packets of the field bus are said to be unpacked at the field device (page 313, right column, first sentence). Both passages thus suggest that "encapsulation" is to be understood as simply adding a header to the internet protocol.

On the other hand, the encapsulation process shown in Figure 7 on page 313 does not explain in detail what actually happens at the proxy where IP encapsulation takes place and could be interpreted as replacing the IP headers with control loop headers. Moreover, the more detailed description of the similar Figure 3 shows the conversion of all layers of a protocol stack at a proxy (page 311, left column, last sentence) and the skilled person could deduce from this that IP encapsulation as shown in Figure 7 should be understood as implying conversion of the lowest three layers of the protocol stack.

1.5 In the absence of an unambiguous teaching as to how "encapsulation" as used in M14 is to be understood, the board concludes that the features relating to encapsulation by adding, rather than replacing, one or more headers are not explicitly disclosed in M14.

The subject-matter of claim 1 is thus new with respect to the teaching of M14 (Article 54 EPC).

1.6 Be it as it may, the board considers that it would have been obvious to the skilled person that in the field devices of M14 encapsulation could equally be effected by adding a header. It follows from the passages from M14 quoted at point 1.4 above that the skilled person could have understood the "encapsulation" process described at paragraph "IP Encapsulation" on page 313, right column, to refer to encapsulation in this sense. He would also have been aware of the trade-off between partial protocol conversion at a proxy (i.e. encapsulation by header replacement) and a mere adding or stripping of an appropriate header (i.e. encapsulation by header addition), in the transfer of computing power from the field device to the proxy, and would have chosen the appropriate form of encapsulation according to the requirements. Such a choice does not require the exercise of inventive skill.

1.7 If the encapsulation process described in M14 is understood in this sense, it follows that the data to be sent from the process device must be formatted in accordance with the (public) Internet protocol thereby producing (public) Internet-compatible data which are subsequently adapted for transmission over the process control loop by "encapsulating" them with a header appropriate for transmission upon the process control loop, this header eventually being stripped by a proxy at the internet/process control loop connection.

In order to effect encapsulation, the field device would require a memory to store address data relating to (public) Internet communication and in particular to contain an internet address of the process device formatted in accordance with a (public) Internet protocol.

Similarly, the loop interface circuitry would be adapted to format the (public) Internet-compatible data for transmission upon the process control loop

and to transmit the formatted (public) Internet-compatible data upon the process control loop; and

would be configured to receive data packets from the process control loop which contain the internet address and to transmit data packets on the process control loop which include the internet address.

Thus, the remaining features of claim 1 follow from the above interpretation of the term "encapsulation".

This finding is valid irrespective of the fact that IP encapsulation is only explicitly described in M14 for the direction from the internet to the field bus, whereas the claim relates to the opposite direction; any practical system must be bidirectional. In any case, the FAN-encapsulation shown in Figure 6 of M14 implies bidirectionality.

1.8 The subject-matter of claim 1 does not therefore involve an inventive step as required by Article 56 EPC.

The appellant's sole request is therefore not

allowable.

2. Since the subject-matter of claim 1 does not comply with the requirements of Article 56 EPC it is not necessary to consider any further objections which have been raised by the respondents in respect of the appellant's sole request.

3. The appellant's sole request not being allowable, the appeal is dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.