T 1595/07 (Network node emulator/ITT) of 1.2.2011

Summary of Facts and Submissions

I. This appeal is against the decision in writing of the examining division to refuse the European patent application no. 01 127 051.9, publication no. EP 1 213 875. The decision was dispatched on 9 May 2007.

II. The decision under appeal was based on a request comprising a set of claims 1 to 8 filed with the letter dated 2 April 2007. The examining division found that claim 1 of said request lacked an inventive step over the following document:

D1: US 5 732 213 A.

III. Notice of appeal was received at the EPO on 6 July 2007 and the appeal fee was paid on the same date. The written statement setting out the grounds of appeal was received at the EPO on 10 September 2007. With said written statement the appellant filed a new request comprising claims 1 to 4.

Claim 1 of said request reads as follows:

"A computer implemented method for emulating traffic on a data network, comprising:

a. specifying a predetermined set of interactions (705) to be performed by at least one network node as a result of exchanging messages with another node on the data network, said set of interactions including a receive command (814), transmit command (807) and response command (818), protocol characteristics of a message exchange (709), and node interactions (712) necessary to exchange messages;

b. receiving an incoming message (502) at the at least one node from the data network and processing said incoming message according to said receive command;

c. generating an outgoing message (506) according to parameters of said transmit command and transmitting said outgoing message from the at least one node to another node in the data network or to a solitary node connected to the at least one node;

d. responding to an incoming message (509) at the at least one node by transmitting a response outgoing message according to parameters of a response command, wherein responding comprises evaluating payload data of an incoming message by opening a socket type that is dependent on the payload data to be evaluated in order to conduct performance testing of the data network

wherein said (b) receiving, (c) generating and transmitting and (d) responding being executed independently of each other at any time such that the node emulator may be transmitting a message while also receiving or responding to a message, and such that the node emulator may be receiving a first incoming message while responding to a second incoming message."

IV. In a communication accompanying a summons to oral proceedings to be held on 1 February 2011, the board gave its preliminary opinion that the appellant's request was not allowable. In particular, objections were noted under Articles 84 EPC, 123(2) and 52(1) EPC.

V. With respect to Articles 84 and 123(2) EPC, the board expressed doubts as to whether the following specification in step d. of claim 1 complied with the requirements of said Articles: "wherein responding comprises evaluating payload data of an incoming message by opening a socket type that is dependent on the payload data to be evaluated in order to conduct performance testing of the data network".

It was noted with respect to the expression "in order to conduct performance testing of the data network" that there was no apparent basis in the description for determining how evaluating the payload data of an incoming message contributed to performance testing of the data network nor was it evident which particular aspects of the network's performance were to be tested.

In support of the interpretation which it applied to the term "payload data", the board made reference to the following textbook extract:

D3: P. Loshin: "TCP/IP Clearly Explained",

p.3-29 and pp.479-499, 1999, Morgan Kaufmann, ISBN: 0-12-455826-7.

VI. The board further expressed the opinion that, insofar as it could be understood, the subject-matter of claim 1 lacked novelty, or at least an inventive step, over D1. In support of its observations in this regard, the board also made reference to the following textbook extract:

D4: A.S. Tanenbaum: "Modern Operating Systems", pp.27-31 and pp. 278-285, 1992, Prentice-Hall, Inc., ISBN 0-13-595752-4.

VII. The board further noted that it was not inclined to follow the appellant's submissions to the effect that the subject-matter of claim 1 was distinguished over D1 in that it specified the generation of specific network traffic patterns for interacting with real-time traffic loads on a network.

VIII. With a letter of reply dated 3 January 2011, the appellant filed an auxiliary request comprising claims 1 to 4 and referred to paragraphs [0019] and [0063] of the published application as providing support for the amendments to claim 1 of this request.

Claim 1 of said auxiliary request reads as follows:

"A computer implemented method for emulating traffic on a data network, comprising:

a.1 providing a storage being capable of storing network protocol information, storing a node emulator hardware configuration, storing a network hardware configuration, storing network addresses, storing payloads, storing transmit times of outgoing messages, storing outgoing message repetitions, storing outgoing message repetition times, storing outgoing message transmission periods, storing receive triggers, storing response destination addresses, and storing an emulation script;

a.2 specifying a predetermined set of interactions (705) to be performed by at least one network node as a result of exchanging messages with another node on the data network, said set of interactions including a receive command (814), transmit command (807) and response command (818), protocol characteristics of a message exchange (709), and node interactions (712) necessary to exchange messages;

b. receiving an incoming message (502) at the at least one node from the data network and processing said incoming message according to said receive command;

c. generating an outgoing message (506) according to parameters of said transmit command and transmitting said outgoing message from the at least one node to another node in the data network or to a solitary node connected to the at least one node;

d. responding to an incoming message (509) at the at least one node by transmitting a response outgoing message according to parameters of a response command,

wherein responding comprises evaluating whether the incoming message meets the criteria specified in the response command (818) including payload data and packet characteristics of the incoming message

wherein said (b) receiving, (c) generating and transmitting and (d) responding being executed independently of each other at any time such that the node emulator may be transmitting a message while also receiving or responding to a message, and such that the node emulator may be receiving a first incoming message while responding to a second incoming message."

IX. At the oral proceedings held as scheduled on 1 February 2011, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request filed with the written statement setting out the grounds of appeal dated 10 September 2007, or on the basis of the auxiliary request filed with the letter dated 3 January 2011.

X. The further documents on which the appeal is based, i.e. the text of the description and the drawings, are as follows:

Description, pages:

1-3, 5, 6, 11-61 as filed with the letter dated 14 March 2002;

4 as filed with the letter dated 28 September 2006;

7-9 as filed with the letter dated 10 September 2007.

Drawings, sheets:

1/5-5/5 as filed with the letter dated 14 March 2002.

XI. During oral proceedings before the board, the representative made submissions on behalf of the appellant in support of the main and auxiliary requests.

XII. With respect to the board's observations concerning step d. of claim 1 of the main request (cf. item V. above), the representative referred to p.13 l.24-27 and to p.20 l.47-49 of the published application and argued to the effect that, in the given context, the term "payload" should be interpreted as denoting a short string specified in the response command syntax. It was further noted that in [0063] on p.7 of the published application reference was made to evaluating a payload in an incoming message.

It was additionally submitted that the expression "in order to conduct performance testing of the data network" was intended to be placed in the first line of claim 1 of the main request and that, consequently, the claim should be understood as seeking protection for a computer implemented method for emulating traffic on a data network in order to conduct performance testing of the data network.

XIII. Concerning the question of compliance with the inventive step requirement of the EPC, the representative submitted with respect to D1 that said document was primarily concerned with directly testing the software of a new target unit rather than a data network and merely disclosed the use of emulation equipment to validate the correct functioning of OSI software associated with a target node without actually having to use the target node hardware. Reference was also made to the submissions in the written statement setting out the grounds of appeal, according to which D1 did not address the generation of disparate network traffic or the performing of interactions in real-time.

XIV. In response to the appellant's submissions concerning D1, the board noted that according to an embodiment of the claimed invention illustrated in Fig. 4 and described in [0054] to [0056] of the application, a node emulator was connected to a node being tested and a network environment was emulated by creating virtual nodes thereby obviating the need to provide the hardware elements of the emulated environment in (cf. [0056]). An embodiment of D1 illustrated in Fig. 12 and described in col.10 l.43-58 appeared to disclose a substantially similar arrangement comprising a test node which could be a real target hardware system surrounded by a set of virtual nodes (termed "simulated nodes" in D1).

XV. At the end of the oral proceedings the chairperson announced the board's decision.

Reasons for the Decision

1. The appeal complies with the provisions of Articles 106 to 108 EPC 1973 which are applicable according to J 10/07, point 1 (cf. Facts and Submissions, item III. above) and is therefore admissible. However, the appeal is not allowable since the appellant's requests do not comply with the requirements of the EPC for the reasons which follow.

Main request

2. Article 123(2) EPC

2.1 Claim 1 of the main request contains the following specification (cf. step d.): "wherein responding comprises evaluating payload data of an incoming message by opening a socket type that is dependent on the payload data to be evaluated in order to conduct performance testing of the data network".

2.2 The board notes in this regard that the term "payload" is an established term of art which conventionally denotes the information content of a packet of data as opposed to the associated header information, e.g. routing and other control information. In support of this assertion, reference is made to D3, in particular p.17 l.5-10 thereof.

2.3 Referring to p.20 l.47-49 of the published application the appellant argued to the effect that, in the given context, the term "payload" should be interpreted as denoting a short string specified in the response command syntax. However, the aforementioned passage of the description relates to a keyword or parameter of the listen command (as opposed to the response command) which specifies a payload type, i.e. the type of data to be listened for such as TXT, DAT, BIN or VMF. The board does not accept that the cited passage of the disclosure provides a basis for interpreting the term "payload" in the manner proposed by the appellant.

2.4 According to p.20 l.26 - p.21 l.12 of the published application, a socket may be opened for listening to (i.e. receiving) incoming data. However, this disclosure pertaining to the opening of sockets relates specifically to the context of a receive ("listen") command and not to the context of a respond command as specified in claim 1. Moreover, according to the disclosure, the type of socket opened to receive data is dependent on a specification of a network protocol type, e.g. "udp", "tcp" or "mcast", and does not depend either directly or indirectly on the data content of the incoming packet (i.e. "the payload data to be evaluated") as implied by the wording of the claim.

2.5 It is further noted in this regard that even if the interpretation of the term "payload" proposed by the appellant were to be accepted (cf. 2.3 above), there is no identifiable disclosure to the effect that the socket type is dependent on a command parameter which specifies a payload type.

2.6 The appellant's submissions also refer to [0063] on p.7 of the published application where it is stated that "[a] response command may also specify a data payload" and that a payload in an incoming message is evaluated based on such a specification. However, there is no disclosure in this passage of the disclosure to the effect that the evaluation of the payload entails "opening a socket type that is dependent on the payload data to be evaluated in order to conduct performance testing of the data network" as recited in claim 1.

2.7 The board therefore concludes that the disputed specification of step d. of claim 1 (cf. 2.1 above) is not directly and unambiguously derivable from the application as originally filed.

3. In view of the foregoing, the board finds that claim 1 of the main request does not comply with the requirements of Article 123(2) EPC. Consequently, the main request is not allowable.

Auxiliary request

4. Preliminary observations

4.1 Claim 1 of the auxiliary request, differs from the corresponding claim of the main request in the following respects:

(i) A new step a.1 specifying the provision of computer memory means ("a storage") has been added to the claim and step a. of claim 1 of the main request has been designated as step a.2.

(ii) The specification of step d. of the claim which is the subject of the objection discussed under 2. above has been amended to read as follows:

"wherein responding comprises evaluating whether the incoming message meets the criteria specified in the response command (818) including payload data and packet characteristics of the incoming message".

4.2 The board accepts the appellant's submissions to the effect that the introduction of step a.1 into said claim is supported by [0019] of the published application and that, likewise, the amendment to step d. of said claim is supported by [0063] of the published application (cf. Facts and Submissions, item VIII. above).

4.3 In the board's judgement, the amendment to step d. of claim 1 of the auxiliary request overcomes the objection against claim 1 of the main request under Article 123(2) EPC (cf. 2. and 3. above). Given that the passages of the description which provide support for this amendment and for the introduction of step a.1 form part of the originally filed application documents, no additional objections under Article 123(2) EPC are found to arise.

5. Inventive step

5.1 D1 discloses a telecommunication diagnostics system in which network nodes can exchange messages with other nodes on a data network (cf. for example Figs. 3, 5 and 9; col.6 l.9-37). One of said nodes is a protocol simulator referred to as a Message Generator Traffic Simulator (cf. col.8 l.18-25) which, in the board's judgement, implies that it generates messages emulating data network traffic. On this basis, D1 is found to disclose a computer implemented method for emulating traffic on a data network as recited in the preamble of claim 1 of the auxiliary request.

5.2 With respect to step a.1 of said claim, it is noted that the node emulator of the present invention is preferably a conventional general purpose computing device which executes an emulation script (cf. application: for example [0028], [0051], [0070]).

On this basis, said step a.1 is found to specify the provision of a conventional computer memory means which is suitable for storing the various enumerated categories of data ("network protocol information", "a node emulator hardware configuration", etc.) and instructions ("an emulation script") to be used in carrying out the claimed method. In the given context, the board judges that the expression "being capable of" is to be interpreted as "being suitable for".

D1 does not explicitly disclose the provision of computer memory means (i.e. "storage") as recited in step a.1 of claim 1. However, the system of D1 is evidently based on the use of conventional data processing devices, e.g. UNIX processors, which execute test scripts (cf. D1: col.6 l.16-20 and l.57-61; col.7 l.17-20) which are conventionally provided with such means. Under the given circumstances, the board judges that the provision of a storage as claimed is implicit in the disclosure of D1.

5.3 D1 further discloses the use of pre-programmed test scripts designed to send and receive protocol messages and also to send responses to anticipated messages (cf. D1: col.6 l.16-20; col.7 l.17-20; col.8 l.5-17). On this basis, D1 is found to disclose "specifying a predetermined set of interactions to be performed by at least one network node as a result of exchanging messages with another node on the data network, said set of interactions including a receive command, transmit command and response command, protocol characteristics of a message exchange, and node interactions necessary to exchange messages" as recited in step a.2 of claim 1.

5.4 D1 discloses that messages can be received via a protocol gateway using sockets and unpacked and processed (cf. D1: col.6 l.29-32). On this basis, D1 is found to disclose "receiving an incoming message at the at least one node from the data network and processing said incoming message according to said receive command" as recited in step b. of claim 1.

5.5 According to D1, messages can be generated and sent from one node to another (cf. D1: col.7 l.17-20; col. 8 l.5-8 and col.8 l.61 - col.9 l.4). On this basis, D1 is found to disclose "generating an outgoing message according to parameters of said transmit command and transmitting said outgoing message from the at least one node to another node in the data network or to a solitary node connected to the at least one node", as recited in step c. of claim 1.

5.6 D1 further discloses that responses can be generated and sent in response to received messages (cf. for example col.6 l.16-17; col.8 l.12-17; col.9 l.10-13; col.11 l.25-31) and on this basis is found to disclose "responding to an incoming message at the at least one node by transmitting a response outgoing message according to parameters of a response command" as recited in step d. of claim 1.

5.7 In view of the foregoing, the board finds that claim 1 is distinguished over D1 in the following respects:

(i) D1 does not directly and unambiguously disclose that responding to an incoming message "comprises evaluating whether the incoming message meets the criteria specified in the response command ... including payload data and packet characteristics of the incoming message" as specified in step d. of claim 1.

(ii) D1 does not directly and unambiguously disclose that receiving, generating and transmitting and responding are executed independently of each other at any time as specified in the concluding part of claim 1.

However, the feature groups associated with the aforementioned differences do not provide an inventive contribution over D1 for the reasons which follow.

5.8 The feature group of claim 1 associated with difference (i) identified in 5.7 above addresses the partial technical problem of generating responses to incoming messages. The board notes that whereas D1 does not directly and unambiguously disclose that a responding interaction comprises specifying criteria based on payload data and packet characteristics of an incoming message and evaluating whether the incoming message meets these criteria, it discloses receiving and processing incoming messages (cf. D1: col.6 l.29-32) and generating responses to incoming messages (cf. for example col.6 l.16-17; col.8 l.12-17; col.9 l.10-13; col.11 l.25-31). Referring in particular to col.11 l.30-31, a received message may be a "request" requiring the generation of a response.

In the board's judgement, the processing of incoming messages (requests) and generating responses thereto, as disclosed in D1 leads to an implicit requirement for some kind of analysis or evaluation of the characteristics of the incoming messages (requests). Given that a response constitutes a message generated in reply to an incoming message (request), it is reasonable to infer that the characteristics of the response will depend on the characteristics of the incoming message (request). Under these circumstances, the board judges that it would be obvious for the processing of the incoming message (request) to comprise an evaluation against predetermined criteria in order to determine the appropriate response to be generated.

It is further noted in this regard that according to the description of the present application (p.6 l.55 - 58), the payload and packet characteristics recited in step d. of claim 1 are optional parameters associated with a response command. The originally filed application contains no identifiable disclosure which would indicate that any particular technical significance is attributable to using these specific parameters for evaluating an incoming message.

In the given context, the feature group relating to the aforementioned difference (i) is thus found to represent an obvious design choice in order to ensure that an appropriate response is generated in reply to an incoming message. Hence, the board judges that the provision of said feature group does not involve the exercise of inventive skill.

5.9 Concerning the difference (ii) identified in 5.7 above, the associated feature group specified in the concluding part of claim 1 is understood to define an arrangement according to which the processes corresponding to the specified "interactions", i.e. receiving, generating and transmitting and responding, may be executed concurrently by the underlying system hardware and software. Said feature group thus addresses the partial technical problem of how to arrange the processing of the specified interactions.

In a preferred embodiment, the node emulator of the present invention is a conventional general purpose computing device which executes an emulation script, (cf. application: for example [0028], [0051], [0070]). In [0065] of the application it is merely indicated in a cursory manner that concurrent processing of receiving, transmitting and responding interactions may occur. There is, however, no identifiable disclosure of any specific technical measures which would be required to support such processing. In the absence of such a disclosure, the board takes the view that the general purpose computing device on which the claimed invention is based is inherently capable of supporting such concurrent functionality and that no non-obvious technical modifications to the aforementioned device are required in this regard.

With regard to D1, it is noted that the system disclosed therein is preferably UNIX-based (cf. D1: for example, col.1 l.20-23; col.6 l.57-61). UNIX is a multiprogramming operating system in which multiple, independent processes may be running concurrently. In support of this assertion, reference is made to the textbook extract D4, in particular section 7.3.1 (cf. second paragraph thereof), where the following is stated: "UNIX is a multiprogramming system, so multiple independent processes may be running at the same time". Whereas D1 does not directly and unambiguously disclose concurrent processing identical to that specified in the concluding part of claim 1, it does contain a disclosure which suggests that the system of D1 is inherently capable of supporting such processing. Reference is made in this regard to col.12 l.31-33 of D1 which refers to a node (i.e. the "PIG-tool") sending messages at the same time that it is receiving messages. The board therefore judges, that similar to the aforementioned general purpose computing device of the present application, the UNIX-based system of D1 is inherently capable of supporting the concurrent execution of a plurality of interaction processes and that the provision of the claimed functionality in the context of the system of D1 would lie within the routine competence of the skilled person. Hence, the board finds that the provision of the feature group associated with the aforementioned difference (ii) does not involve the exercise of inventive skill.

5.10 Referring to its findings under 5.8 and 5.9 above, the board concludes that the differences identified in 5.7 above do not entail an inventive contribution over D1. It is additionally noted in this regard that the feature groups discussed under 5.8 and 5.9 are independent of each other as regards both the problems they address and their functions or effects and, hence, they may be considered independently for the purposes of assessing inventive step.

6. Further observations relating to inventive step

6.1 Referring to step a.1 of claim 1 as discussed in 5.2 above, the board additionally notes in this regard that no specific technical interrelationship between the storage recited in said claim step and the remaining claim features is apparent from the wording of the claim, nor is it evident what technical function said storage is intended to fulfil beyond that of a conventional computer memory means attached to a processor device. Hence, even if for the sake of argument, this feature were not judged to be implicit in the disclosure of D1, no potentially non-obvious technical contribution to the claimed subject-matter can be identified in respect thereof.

6.2 Referring to the concurrent processing arrangement specified in the concluding part of claim 1 (cf. 5.9 above), the appellant acknowledged that UNIX as disclosed in D1 was a multitasking and multithreaded operating system but questioned whether it would be capable of performing interactions in real-time (cf. written statement dated 10 September 2007: p.1, final sentence). Claim 1 does not, however, specify any requirement to perform interactions in real-time. Neither does the present application contain any identifiable disclosure relating to such a requirement or to any specific technical measures which would be required in order to comply with it. Hence, the appellant's submissions on this point are found to lack relevance in relation to the assessment of the inventive step of the claimed method.

7. Appellant's submissions relating to D1

7.1 The appellant made submissions contesting the relevance of D1 and alleging its remoteness from the claimed invention (cf. Facts and Submissions, item XIII. above).

7.2 The board notes in this regard that claim 1, which is directed towards "a method for emulating traffic on a data network", does not define any specific technical characteristics concerning the network traffic to be emulated. In particular, claim 1 does not contain any identifiable specification relating to the generation of disparate network traffic or to performing interactions in real-time.

7.3 As acknowledged by the appellant, D1 relates to the testing of a target unit within a simulated communication environment. The board judges that it is implicit that such testing comprises the emulation of network traffic (cf. observations under 5.1 above) as it would appear to be otherwise impossible to carry out satisfactory testing. Likewise, the reference to "telecommunication signaling" and "signaling information" in D1 (cf. D1: col.6 l.57-61) is found to imply the generation of network traffic.

7.4 The board further notes in this regard that the embodiment of D1 illustrated in Fig. 12 and described in col.10 l.43-58 discloses a substantially similar arrangement to the embodiment of the claimed invention illustrated in Fig. 4 and described in [0054] to [0056] of the present application according to which a node emulator is connected to a node being tested and a network environment is emulated by creating virtual nodes, (cf. Facts and Submissions, item XIV. above).

7.5 In view of the foregoing, the board does not accept the merits of the appellant's submissions contesting the relevance of D1 with respect to the claimed invention.

8. Referring to the observations set forth under item 5. to 7. above, in particular those under item 5., the board finds that claim 1 of the auxiliary request lacks an inventive step over D1. The auxiliary request is therefore not allowable.

Conclusions

9. Neither the main request nor the auxiliary request is allowable. In the absence of an allowable request the appeal must be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.