T 0751/13 (Interlinking communication mode with storage location/SAP) of 13.12.2018

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division, posted on 23 January 2013 refusing European patent application No. 04786215.6 pursuant to Article 97(2) EPC on the ground of lack of inventive step (Article 56 EPC) with regard to prior-art publications:

D1: WO 01/67348 A2 and

D4: US 2002/091533 A1.

II. In the statement setting out the grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the refused main or auxiliary request both filed with letter dated 19 March 2012. Oral proceedings were requested on an auxiliary basis.

III. In its communication accompanying the summons to oral proceedings, the Board expressed its preliminary opinion that both requests lacked inventive step (Article 56 EPC).

IV. In a reply, the appellant submitted its interpretation of D4 and further arguments in favour of inventive step.

V. At the oral proceedings on 13 December 2018, the appellant confirmed the requests submitted in writing.

VI. Independent claim 1 according to the main request reads as follows:

"1. A data processing system for processing a request (614), the data processing system comprising:

- means (610, 618) for selecting an asynchronous or a synchronous communication mode for communication with partner computer systems,

- means for splitting the request into a set of sub-requests (630),

- synchronous communication means (610, 613) being adapted to send a first one of the sub-requests of the set of sub-requests to one of the partner computer systems, wait for the respective sub-response from the one of the partner computer systems and send a second one of the sub-requests of the set of sub-requests to one of the partner computer systems after the sub-response has been received, wherein the sub-responses are stored in a random access memory (613),

- asynchronous communication means (610, 612) being adapted to send the sub-requests in parallel to the partner computer systems, store respective sub-responses of the partner computer systems in a database (612) on a non-volatile storage device,

- means (610) for combining the sub-responses to generate a response to the request,

- means (610, 619) for sending the response."

Claim 1 of the auxiliary essentially adds to the main request that "the means for selecting the asynchronous or synchronous communication mode comprises a set of rules (618) to be applied on the request, wherein the selection depends on preferences of a requestor, the preferences being given in the request (614) and wherein the selection depends on the partner computer systems' communication capabilities stored as the set of rules (618) in the data processing system."

VII. The appellant argued essentially that none of the prior art documents disclosed or taught in the direction of interlinking the communication mode with the storage location whereby the performance of the system could be increased by avoiding additional delays caused by accessing non-volatile storage media when in synchronous mode. The selection between random and non-volatile storage in dependence of the communication mode (synchronous or asynchronous) was not obvious.

An advantage of this was that it allowed a reduction in the number of write operations on the non-volatile storage which was typically slower than RAM, therefore speeding up the process. Thereby valuable resources were not blocked.

Furthermore, normal design practise of modularity and encapsulation led to decoupled functionality. By choosing the storage type in dependence of the communication mode, the present invention went contrary to these design principles.

Further details and arguments are dealt with in the reasons for the decision.

Reasons for the Decision

Main request

1. Article 56 EPC - Inventive step

The Board agrees with the decision under appeal that the subject-matter of independent claim 1 lacks an inventive step for essentially the same reasons.

1.1 Firstly, the Board agrees (see point 1.2 of the decision) that D4 discloses the following features of claim 1 (see in particular [0076, 0093] and figure 10):

A data processing system for processing a request, the data processing system comprising:

- means for selecting an asynchronous or a synchronous communication mode for communication with partner computer systems (paragraph [0076]),

- means for splitting the request into a set of sub-requests (paragraph [0068]; figure 4),

- synchronous communication means being adapted to send a first one of the sub-requests of the set of sub-requests to one of the partner computer systems, wait for the respective sub-response from the one of the partner computer systems and send a second one of the sub-requests of the set of sub-requests to one of the partner computer systems after the sub-response has been received (paragraphs [0076], [0093]; figure 10),

- asynchronous communication means being adapted to send the sub-requests in parallel to the partner computer systems, store respective sub-responses of the partner computer systems (paragraphs [0076], [0093], [0094]; figures 10, 11),

- means for combining the sub-responses to generate a response to the request (paragraph [0068]; figure 4),

- means for sending the response (paragraph [0068]; figure 4).

1.2 Claim 1 differs by explicitly stating that in the case of synchronous communication the sub-responses are stored in a random access memory (RAM) and in the case of asynchronous communication in a database on a non-volatile storage device.

1.3 The appellant argued that according to D4 when asynchronous communication mode was chosen, the XML data exchange engine would enforce a wait until the response was received (see page 3, paragraph 6 of the statement setting out the grounds of appeal). The Board does not agree. It is rather the contrary, that in synchronous communication mode a wait is enforced (see e.g. figure 10, elements 1015 and 1025).

1.4 The Board agrees with the appellant's interpretation of D4 that when asynchronous communication mode is chosen, the request would be put in a response wait queue (see e.g. figure 10, element 1020). D4 is not totally clear on whether responses of asynchronous requests put in a wait queue in D4 are stored in a non-volatile storage medium. The appellant's attention is however drawn to the fact that D4 (see [0081]) discloses that responses can either be "stored in persistent storage", i.e. non-volatile storage (see also figure 1 with volatile memory 28 and persistent storage 30; see [0057] referring to hard disk drives) or in a non-persistent way, i.e. in RAM. Appendix A.1 also discloses an attribute "persistent" with "yes/no" (see top of page 22 of the description) with regard to a target element triggering execution of Service Units (see bottom of page 21).

1.5 According to D4 the asynchronous communication mode is the default communication mode. However (see D4, [0076]) "Synchronous processing may be provided by having the XML data exchange engine wait for the response to arrive before returning to the script processing").

In the Board's view waiting for the response implicitly links the use of non-persistent storage to the synchronous communication mode. This is an indication that the focus is on a fast processing. D4 hence hints at coupling of the two functions "synchronous communication" and "non-persistent storage", which points towards the claimed solution.

1.6 The Board concurs with the decision under appeal that the skilled person would have learnt from the disclosure of D4 that there are two ways of handling and storing the requests depending on the communication mode. When faced with the actual implementations of how the responses are stored, the person skilled in the art would consider the need for persistence or for speed based on the actual circumstances, i.e. in one case long running processes (order of weeks) which require the ability to retrieve the request when the response is received therefore setting the attribute "persistent" to "yes".

In the other case of short running processes, the skilled person would consider interactive processes which stop the execution of the script until the response is received. The person skilled in the art would choose whether persistence or speed is needed in order to minimise interruptions.

The choice between a random access memory or a non-volatile storage device for storing data represents an obvious implementation detail which does not involve an inventive step. Both techniques are part of the common general knowledge in data processing with the obvious well-known advantages and disadvantages. The person skilled in the art would choose one or the other based on the implementation circumstances (such as need for speed, or data persistence, etc.) without the exercise of an inventive activity (Article 56 EPC). Moreover, as mentioned above, D4 already suggests coupling synchronous communication with non-persistent storage.

1.7 In the Board's view Appendix A.1 of D4 is not to be understood that both elements, "suspend" and "send", can be combined freely. The appellant's argument does not convince. While the "send" element is said to be "by default asynchronous" (see page 22 of D4), the "suspend" parameter set to zero means no wait and, hence, also asynchronous communication mode. This is a combination, which points to asynchronous communication mode.

1.8 The Board is not convinced by the appellant's argument that the coupling of the functions of communication mode and storage mode violates common software design principles like decoupling and modularity (see page 4 of the statement setting out the grounds of appeal). In view of the disclosure of D4, the same coupling is suggested for asynchronous mode. Furthermore, the Board again agrees with the contested decision that modularisation and encapsulation refer to the actual implementations of functions at a programming level, which is not the case with the claimed subject-matter which is limited from a technical point of view to generic "communication means". Having both functions coupled does not necessarily mean that the implementation cannot be object oriented.

1.9 The Board further agrees with the contested decision that the "coupled" features represent a mere juxtaposition of features rather than a synergy. The use of both synchronous and asynchronous communication is disclosed in D4 and storing data in random access memory or in non-volatile memory is regarded to be within the common general knowledge and therefore an obvious design choice. The Board does not see any technical effect that goes beyond the sum of the individual effects of synchronous and asynchronous communication on the one hand, and of storing data in random access memory or in non volatile memory on the other hand.

1.10 Accordingly, the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC) over D4 combined with the skilled person's common general knowledge.

1.11 The same objections apply, mutatis mutandis, to corresponding independent claims 6 and 10.

Auxiliary request

2. Claim 1 of this request essentially specifies preferences in the request of a requestor, which specify for each single request if it should be processed asynchronously with sub-responses stored in non-volatile storage.

2.1 The contested decision argued that in D4, as in the present invention, rules stored in the central processing unit were checked and a synchronous or asynchronous communication mode was selected dynamically at run-time, hence in a request dependent way. Those rules were defined by the "send element" of an XML document. D4 does not explicitly disclose that the rules for selecting depend on preferences of the user, which however only relates to the content of a particular rule without further specifying technical information in this regard (in accordance with point 2.2.2 of the decision).

2.2 The appellant argued that the communication mode according to D4 was not specified in the request and thus not specified by the requester on a per-request basis, because the "send element" of an XML service definition script was not a request and was not received from the requestor (see page 9 of the statement setting out the grounds of appeal).

2.3 According to D4 (see Appendix A.1, pages 21 and 22), a target element can define a hand off process to synchronise or route multiple XML documents to various destinations, keeping the transformation result of an actual request. Hence, the target element is not a service definition script, but changes with each request. The target element, inter alia, comprises the attributes "persistent" and "send element" (see discussion above). The appellant's arguments therefore do not convince the Board.

2.4 The Board, hence, maintains the objection of the contested decision based on D4, where an XML document is received and based on its contents a service unit is matched and selected, the service unit specifying the communication mode. The additional feature is therefore considered to be an obvious implementation detail within the skilled person's common general knowledge in the light of the general disclosure of D4.

2.5 In the absence of an inventive technical contribution, the subject-matter of claim 1 of this request therefore does not involve an inventive step (Article 56 EPC) either.

2.6 The same objection apply, mutatis mutandis, to corresponding independent claims 5 and 9.

3. Thus, the Board cannot identify an inventive step in respect of either the main or the auxiliary request.

Order

For these reasons it is decided that:

The appeal is dismissed.