T 1430/11 (Virtual backup units/SAP) of 24.4.2013

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division, posted on 6 May 2011, refusing European patent application No. 07115417.3 on the grounds of lack of inventive step (Article 56 EPC) with respect to a main request, having regard to the disclosure of

D1: US-B-6 298 063,

added subject-matter (Article 123(2) EPC) with respect to a first, second, and seventh auxiliary request, and lack of novelty (Article 54 EPC) with respect to an eighth auxiliary request. Furthermore, the late-filed third to sixth and ninth auxiliary requests were not admitted into the examination proceedings under Rule 137(3) EPC, since they were considered not to be clearly allowable under Articles 123(2) and 56 EPC, respectively.

In an obiter dictum, the decision under appeal further stated that the first and second auxiliary requests also lacked sufficient disclosure (Article 83 EPC) and an inventive step (Article 56 EPC), having regard to

D1

and

D2: WO-A-02/15030.

II. Notice of appeal and the statement setting out the grounds of appeal were received on 26 May 2011. The appeal fee was paid on the same day. With the statement setting out the grounds of appeal, the claims according to the third to ninth auxiliary requests underlying the appealed decision were re-filed. The appellant requested that the decision of the examining division be set aside and that a patent be granted on the basis of the claims according to the third auxiliary request (claims 1 to 20) and, as a precautionary measure, requested oral proceedings in the event that the third auxiliary request was not granted. In addition, the appellant maintained "the Auxiliary Requests 3-9 and an Auxiliary request of sending the application back to the Examining Division for further prosecution".

III. A summons to oral proceedings scheduled for 25 April 2013 was issued on 5 February 2013 and - after receipt of a request for postponement - the oral proceedings were re-scheduled to 24 April 2013. In an annex to this summons, the board gave its preliminary opinion on the appeal pursuant to Article 15(1) RPBA. In particular, objections were raised under Articles 123(2), 84, 54 and 56 EPC, mainly in view of D1.

IV. With a letter of reply dated 28 February 2013, the appellant submitted amended claims according to a main request (claims 1 to 15) and a firstauxiliary request (claims 1 to 15) together with amended description pages, and stated that the former requests were replaced by those new requests provided that a new request was admitted into the procedure.

V. Oral proceedings were held on 24 April 2013, during which the former main request was replaced by a new main request (claims 1 to 15) in response to objections raised under Article 123(2) EPC by the board at those oral proceedings. All the pending requests were then discussed.

The appellant finally requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request, as filed during the oral proceedings before the board, or on the basis of the first auxiliary request, as filed with letter dated 28 February 2013.

At the end of the oral proceedings, the decision of the board was announced.

VI. Claim 1 of the main request reads as follows:

"A method for ensuring high availability in a software based contact centre (200) relaying at least phone calls, comprising at least one high availability control unit (220), the method comprising the following steps:

- analyzing at the at least one high availability control unit (220) the overall system status of the software based contact centre (200),

- controlling and monitoring at the at least one high availability control unit (220) virtual backup units (230, 240, 250), wherein the at least one high availability control unit (220) has logical connections to the virtual backup units (230, 240, 250) being distributed on several servers and wherein each of the virtual backup units (230, 240, 250) comprises a set of resources (231, 232, 233, 234, 235, 236) designed to replace failing resources in the software based contact centre (200) that are configured to relay phone calls, and

- if at least one of the resources, provided by the software based contact centre and configured to relay a phone call, fails,

initializing, at any of the servers, at least

one of the virtual backup units (230, 240, 250) to

take over the at least one failed resource by

allocating the IP address of the failed resource to

said at least one virtual back up unit,

replacing by at least one of the resources

(231, 232, 233, 234, 235, 236) of said at least one

virtual backup unit the at least one failed

resource, and

resuming the service to relay a phone call of

the at least one failed resource."

Claims 8 and 15 of the main request are directed towards a corresponding apparatus and computer program, respectively.

Claim 1 of the first auxiliary request reads as follows:

"A method for ensuring high availability in a software based contact centre (200) relaying at least phone calls, comprising a plurality of high availability control units (220), the method comprising the following steps:

- reading, using one of the high availability control units (220), configuration data from a local file (810);

- creating, using the at least one high availability control unit (220), a system model (830) from the configuration data;

- analyzing at the at least one high availability control unit (220) the overall system status of the software based contact centre (200),

- controlling and monitoring at the at least one high availability control unit (220) using the system model (830) virtual backup units (230, 240, 250), wherein the at least one high availability control unit (220) has logical connections to the virtual backup units (230, 240, 250) being distributed on several servers and wherein each of the virtual backup units (230, 240, 250) comprises a set of resources (231, 232, 233, 234, 235, 236) designed to replace failing resources in the software based contact centre (200) that are configured to relay phone calls,

- if at least one of the resources, provided by the software based contact centre and configured to relay a phone call, fails,

initializing, at any of the servers, at least one of the virtual backup units (230, 240, 250) to take over the at least one failed resource by transferring and allocating the IP address of the failed resource to said at least one virtual back up unit,

replacing by at least one of the resources (231, 232, 233, 234, 235, 236) of said at least one virtual backup unit the at least one failed resource, and

resuming the service to relay a phone call of the at least one failed resource; and

- relaying, by the at least one high availability control unit (220) using a high availability controller protocol over a TCP/IP network, changes in the system model (830) to others of the plurality of high availability control units (220) in the software based contact centre (200), thereby automatically propagating the changes in the system model (830) to the others of the plurality of high availability control units (220)."

Reasons for the Decision

1. Admissibility of the appeal

The appeal complies with the provisions of Articles 106 to 108 EPC (cf. point II above) and is therefore admissible.

2. MAIN REQUEST

This request differs from the third auxiliary request underlying the appealed decision basically in that independent claims 1 and 8 as amended, apart from minor rewordings, further specify that

a) phone calls are relayed in the software-based contact centre;

b) virtual backup units are distributed on several servers;

c) the at least one high-availability control unit has logical connections to the virtual backup units;

d) the virtual backup units comprise a set of resources designed to replace failing resources in the software-based contact centre;

e) initializing, at any of the servers, at least one of the virtual backup units to take over the at least one failed resource by allocating the IP address of the failed resource to said at least one virtual backup unit.

Feature a) is based on claim 1 as filed while features b) to d) are, in particular, supported by the disclosure of page 4, lines 11-13 and page 7, lines 17-20 of the application as filed. Feature e) is based on page 4, lines 15-17 and claim 2 of the application as filed.

2.1 Article 123(2) EPC

The examining division considered that the feature "at least one virtual unit is distributed on multiple server devices" of former claims 1 and 8 infringed Article 123(2) EPC, since the virtual unit was not "splitable" according to the original disclosure (cf. appealed decision, section 2.3).

As a result of the amendments made in response to that objection (see feature b) above), the board is satisfied that the corresponding objection is overcome and that the amendments are now admissible under Article 123(2) EPC.

2.2 Article 84 EPC: Clarity

The examining division also held that it was not clear in former claims 1 and 8 whether "virtual unit" was a "virtual backup unit" or not (cf. appealed decision, section 2.3).

Following the amendments made in response to that clarity objection (see feature b) above), the board is satisfied that this objection also no longer applies. For these reasons, the board concludes that the present claims are now clear under Article 84 EPC.

2.3 Article 52(1) EPC: Novelty and inventive step

In the board's judgment, independent claims 1 and 8 do not meet the requirements of Articles 52(1) and 56 EPC, for the following reasons:

2.3.1 The board concurs with the examining division and the appellant in considering D1 as the closest prior art, since it is also related to fault management in software-based contact centres.

2.3.2 D1 discloses, with regard to the terminology of claim 1, a software-based contact centre (see Fig. 1), comprising a high-availability control unit ("Local Director 200") which analyses the overall system status of the software-based contact centre (see e.g. column 6, lines 34-38: "... Local Director 200 monitors the number of connections ditched by each machine and changes the status of a machine to failed when a certain number of connections are ditched ..."). The high-availability control unit further controls and monitors virtual backup units ("virtual machines") having logical connections to the high-availability control unit (see column 4, lines 43-46: "Requests to a virtual machine from external sites ... are routed through Local Director 200 ..."; column 4, line 62 to column 5, line 6: "Local Director 200 effectively simulates communication inbound to ... outbound from one or more virtual machines ..."). Also, the virtual backup units are distributed on several servers and comprise a set of resources designed to replace failing resources in the software-based contact centre (see column 4, lines 55-61: "... virtual machines may be implemented ... on certain of the real or physical machines ..." in connection with Fig. 7).

In the event that any unit (i.e. resource) of the software-based contact centre fails, the high-availability control unit initialises a virtual backup unit to take over a failed resource (see e.g. column 5, line 63 to column 6, line 15 and Fig. 6). According to an embodiment of D1, in the event of a failed unit, the "Local Director" is supposed to select a backup unit, and the respective SYN packets sent by the client are automatically transferred to the corresponding backup machine without the respective client noticing any network failure or switch-over (see column 6, lines 21-31). Since IP addresses are used for transferring data packets in the underlying TCP/IP network of D1, the above embodiment at least implicitly teaches that the "Local Director" has to allocate the IP address of the failed unit to the selected backup unit such that the client may still send its packets to the selected IP address in a client-transparent manner, i.e. without necessitating any modification of the respective destination IP address at the client's end. In other words, the teaching of D1 implies that the "Local Director" inherently maps the incoming destination IP address corresponding to the failed unit to the IP address of the backup unit (e.g. via an internal mapping table), thereby "allocating" the IP address of the failed resource to the virtual backup unit as claimed. In this regard, the appellant argued that D1 taught that the IP address of the selected backup unit, i.e. the "new" unit, was used for the corresponding switch-over rather than the IP address of the failed unit, i.e. the "old" unit, as claimed. However, since D1 intends to ensure client-transparency in the failure case, the clients in D1 may still send their packets using the IP address of the failed unit as destination addresses. That palpably implies that the "Local Director" has to use the failed unit's IP address and map it to the IP address of the backup unit replacing the failed unit, contrary to the above assumption of the appellant.

Finally, the failed resource is replaced by the initialised virtual backup unit and the service of the failed resource is resumed (see e.g. column 15, lines 49-51: "... If physical machine 1.1 is failed, then virtual machine 2 which is defined as a backup machine for physical machine 1.1 is used in place of physical machine 1.1 ..." in connection with Fig. 7).

2.3.3 Hence, the only difference between the subject-matter of claim 1 and the disclosure of D1 is seen to be that the software-based contact centre under consideration relays phone calls (i.e. feature as given above). Consequently, the subject-matter of claim 1 is novel over the cited prior art (Article 54 EPC).

2.3.4 The board considers the analogous use of the above fault management method with regard to different network services as the objective problem to be solved by claim 1.

2.3.5 D1 teaches the use of the underlying fault management approach particularly in environments such as web, FTP, mail, and telnet services. Based on that, the person skilled in the art would be aware from his common general knowledge of the fact that this scheme could also be extended to other services like e.g. VoIP calls using VoIP servers. According to the board, such a minor adaptation of the system of D1 would not produce any unexpected synergetic technical effect, since relaying phone calls such as VoIP data packets is commonly associated with a well-known effect and benefit in the respective technical field (see e.g. D2) and merely depends on the practical needs of the network engineer. That was, moreover, not contested by the appellant.

2.3.6 The appellant advanced the argument that D1 adopted a session distribution scheme according to which the best matching backup machine was searched in the event of a failed unit (by referring, in particular, to column 14, lines 54-61 of D1) whereas, according to claim 1, the virtual backup unit was already designated.

The board notes however that neither the claims nor the description provide any detailed information on how the respective virtual backup units are actually selected in a failure case, let alone that the virtual backup units are predetermined by the high-availability controller. As a consequence, no substantial difference between claim 1 and D1 can be discerned in this respect.

2.3.7 The above reasoning also applies to the corresponding apparatus claim 8.

2.3.8 For these reasons, the subject-matter of claims 1 and 8 of this request does not involve an inventive step having regard to D1 and the skilled person's common general knowledge.

2.4 In conclusion, this request is not allowable under Article 56 EPC.

3. FIRST AUXILIARY REQUEST

This request differs from the main request essentially in that independent claims 1 and 8 as amended further specify that

f) the software-based contact centre comprises a plurality of high-availability control units;

g) configuration data from a local file is read using one of the control units;

h) a system model is created from the configuration data using the at least one high-availability control unit;

i) the virtual backup units are controlled and monitored at the at least one high-availability control unit using the system model;

j) changes in the system model are relayed, by the one high-availability control unit, using a controller protocol over a TCP/IP network, to others of the plurality of high-availability control units in the software-based contact centre, thereby automatically propagating the changes in the system model to the others of the plurality of high-availability control units.

3.1 Admission into the appeal proceedings

The board decided not to admit this request into the appeal proceedings in the exercise of its discretionary power under Articles 12(4) and 13(1) RPBA, for the following reasons:

3.1.1 This request was submitted in response to the summons to oral proceedings before the board (cf. point IV above), i.e. at a relatively late stage of the procedure. The added features to relate to embodiments (i.e. "network of high-availability controllers" according to Fig. 7 in connection with page 12, line 25 to page 13, line 19 and "controlling the configuration of a high-availability controller" based on Fig. 8 in connection with page 13, line 20 to page 14, line 11 of the application as filed) which had never been discussed or examined before in the first-instance proceedings.

3.1.2 The request therefore comprises substantial amendments to the claims, taken from the original description, which diverge from the requests and facts on file. It thus shifts the focus to a different subject-matter (i.e. ensuring high availability in a software-based contact centre via a plurality of interconnected high-availability controllers using controlled configuration) and a different technical problem to be solved (i.e. synchronisation of configuration data among a plurality of high-availability controllers) which had not been addressed in the first-instance proceedings, and therefore adds new complex issues to the case. Consequently, this request cannot be objectively considered as an adequate attempt at this stage of the proceedings to overcome the outstanding objections previously raised.

3.1.3 Admitting this request into the appeal proceedings at such a late stage would therefore make further investigations, an additional search and/or a remittal to the department of first instance necessary. That, however, would run counter to the principle of procedural economy.

3.1.4 Furthermore, the added features to of independent claims 1 and 8, prima facie, give rise to further objections under Article 123(2) EPC. In particular, those features imply that a system model created from configuration data by one high-availability controller is distributed across a plurality of high-availability controllers, whereas the application as filed fails to provide any explicit statement or unambiguous implication that the embodiment which is related to several interconnected high-availability controllers based on Fig. 7 could be combined with the embodiment related to the configuration control of a single high-availability controller according to Fig. 8.

In this context, the appellant submitted that the embodiments based on Figures 7 and 8 were linked via the fact that the term "high availability controller instances" (as referred to on page 14, lines 5-11 of the application as filed), and the term "high availability controllers" (as referred to on page 12, lines 25-26) were used synonymously throughout the original application. The board is however not convinced, since the embodiment based on Fig. 5 evidences that "high availability controller instances" are used (cf. page 9, lines 23-26 of the application as filed) despite the fact that only one controller (i.e. "high availability controller 530") is under consideration according to Fig. 5, thereby implying that the terms "controllers" and "controller instances" cannot be considered as conterminous according to the original application. Consequently, this request is not clearly allowable under Article 123(2) EPC.

3.2 In view of the above, this request was not admitted into the appeal proceedings under Articles 12(4) and 13(1) RPBA.

Order

For these reasons it is decided that:

The appeal is dismissed.