T 0474/14 (Event distribution in messaging systems/ERICSSON) of 29.10.2019

European Case Law Identifier: ECLI:EP:BA:2019:T047414.20191029
Date of decision: 29 October 2019
Case number: T 0474/14
Application number: 08867678.8
IPC class: G06F9/50
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 345 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: METHODS AND APPARATUS FOR EVENT DISTRIBUTION IN MESSAGING SYSTEMS
Applicant name: Telefonaktiebolaget LM Ericsson (publ)
Opponent name: -
Board: 3.5.06
Headnote: -
Relevant legal provisions:
European Patent Convention Art 56 (2007)
European Patent Convention R 111(2) (2007)
Keywords: Inventive step - (no)
Form of decision - decision sufficiently reasoned (yes)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. This is an appeal against the decision, dispatched with reasons on 4 October 2013, to refuse European patent application No. 08 867 678.8 on the basis that claim 1 of the main request, filed in the oral proceedings before the examining division, lacked inventive step, Article 56 EPC, in view of the following document:

D1: US 4 577 272 A.

II. A notice of appeal and the appeal fee were received on 4 December 2013. The appellant requested that the decision be set aside.

III. With a statement of grounds of appeal received on 4 February 2014 the appellant submitted claims according to a main and an auxiliary request. The appellant requested that the decision be set aside and that a patent be granted on the basis of said main and said auxiliary request. The appellant also made an auxiliary request for oral proceedings. The appellant stated inter alia that the decision was not "sufficiently substantiated"; see page 7, section 5.

IV. In an annex to a summons to oral proceedings the board set out its provisional opinion that the decision appeared to be sufficiently reasoned, Rule 111(2) EPC. The board had doubts regarding the clarity, Article 84 EPC, of the feature in both independent claims and claims 4 and 9 of both requests "retrieving a time slot table". The board also had doubts as to the clarity of the expressions "current traffic load", "optimal traffic load" and "maximum event queue length" in the independent claims of both requests. The question also arose of whether the subject-matter of the independent claims of both requests involved an inventive step, Article 56 EPC, in view of D1.

V. In a letter received on 7 October 2019 the appellant withdrew its auxiliary request for oral proceedings and did not file any amendments or arguments. The board then cancelled the oral proceedings.

VI. The application is thus being considered in the following form:

Description (both requests):

pages 1 to 13, as originally filed.

Claims (both requests received with the grounds of appeal):

Main request: 1 to 19.

Auxiliary request: 1 to 18.

Drawings (both requests):

Pages 1/9 to 9/9, as originally filed.

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

"A method for distributing event delivery for a set of traffic processors in a telecommunication network, the method comprising the steps of:

- obtaining a status for each active traffic processors (24) of the set of processors in the telecommunication network, the status comprising a current traffic load (25, 306) of a traffic processor (24) and an event queue length (41, 308) associated to a traffic processor (24);

- determining a traffic processor from the set of traffic processors with the lowest traffic load, the traffic load is determined for each traffic processor of the set of traffic processors based on a weighting factor, the event queue length of a traffic processor and the current traffic load;

- sorting each traffic processor from the set of traffic processors from the traffic processor having the lowest traffic load to the traffic processor having the heaviest traffic load;

- selecting an event group manager, the event group manager is an event scheduler that manages the traffic processor of the set of traffic processors with the lowest traffic load;

- retrieving a time slot table for each traffic processor of the set of traffic processors;

- determining an allowable event queue length for each traffic processor of the set of traffic processors, the event queue length being a determined threshold for redistributing event delivery, wherein the allowable event queue length [is] based on the current traffic load, an optimal traffic load and a maximum event queue length; and

- re-distributing the events of a failed traffic processor among the sorted set of traffic processors starting with the traffic processor having the lowest traffic load until the allowable event queue length of the respective traffic processor is reached."

VIII. Claim 1 of the auxiliary request differs from that of the main request in the inclusion of the formula defining the event queue length set out in claim 13 of the main request. In view of the complexity of the formula, reference is made to the online case file.

Reasons for the Decision

1. The admissibility of the appeal

In view of the facts set out at points I to III above, the appeal fulfills the admissibility requirements under the EPC and is consequently admissible.

2. A summary of the invention

2.1 The invention relates to a communication node, illustrated in figures 1 and 2 (200), for transmitting messages, such as SMS or instant messages (IM) in a telecommunications network. The handling of messages involves "delivery" and "expiry" events; see page 5, lines 21 to 22. The node comprises a plurality of traffic processors (TP, 22) and a plurality of event schedulers (20, 21), managed by an event scheduler group manager (205). Each traffic processor (TP) is fed with events by an event queue in a respective event scheduler (ES); see page 9, lines 27 to 28.

2.2 The problem arises of load-balancing between the traffic processors, for instance when one fails or is shut down temporarily for maintenance purposes (see page 10, lines 18 to 20), or when one is added; see page 3, lines 11 to 13, and page 4, lines 1 to 3.

2.3 Event redistribution occurs on the basis of two parameters which are determined separately for each traffic processor: the traffic load (TL)(see figure 6a) and, based on this, the allowable event queue length (EQ)(see figure 6b). The redistribution method of figure 4a after a traffic processor failure involves obtaining the status of each remaining traffic processor in terms of its traffic load (TL) and event queue length (EQ); see step 404. The traffic processors are then sorted in order of increasing total traffic load (see page 8, lines 21 to 23, the sentence bridging pages 8 and 9 and figure 6a, step 712), a combination of traffic load (TL), event queue length (EQ) and weighting factor (delta). The least-loaded traffic processor is then identified; see steps 408 and 412. Events in the queue of the failed traffic processor are then redistributed to the remaining active traffic processors, starting with the least-loaded traffic processor and progressing to the increasingly loaded traffic processors, all the while ensuring that the queue of each active traffic processor does not exceed a determined allowable length (419); see page 9, lines 8 to 12.

2.4 Figure 6b illustrates the algorithm for calculating the allowable queue length as a function of a calculated current traffic load (Lc)(801)(step 800) of each traffic processor, a calculated optimal/design traffic load (Lo)(803)(step 802) and a calculated maximum event queue length (805)(step 804). The formula is shown in step 808 and page 10, lines 5 to 10.

3. Clarity, Article 84 EPC

3.1 In its preliminary opinion the board pointed out that the feature in inter alia claim 1 of both requests "retrieving a time slot table for each traffic processor of the set of traffic processors" was not connected to the other features of the claim. The appealed decision found this to be a "dangling feature" providing "results which are not made use of"; see point 5.2. The board noted that, although figure 5 illustrated a "time slot" 305, the associated description (see paragraph bridging pages 9 and 10) did not explain how the traffic load or the queue length, mentioned later in the claim, were derived from the time slot table shown in figure 5. Hence the role played by the above feature in the claimed method and apparatus was unclear. The board also expressed doubts as to the clarity of the expressions "current traffic load", "optimal traffic load" and "maximum event queue length", used in inter alia claim 1 of both requests, the description giving no definition of these terms. The appellant had argued that the "current traffic load" of a processor meant the number of events assigned to and which may already be in processing (emphasis added by the board). The board was unable to derive this definition from the application. The term "may" also begged the question whether there was some overlap between events in an input queue and events being processed. Moreover, although inter alia claim 1 of both requests set out sorting the traffic processors from lowest to highest traffic load, the claim only specified that redistribution "among the sorted set" started with the processor with the lowest traffic load until its allowable event queue length was reached. It was unclear whether the claims were to be understood as being restricted in the sense that redistribution continued in the order of increasing processor traffic load.

3.2 In the present case, there is no need to decide whether these doubts regarding clarity amount to a violation of Article 84 EPC, since the board finds that the claims of both requests, understood in the light of the application as a whole, are sufficiently clear for the assessment of inventive step and, as will be shown, this finding alone is decisive for both requests.

4. Document D1

4.1 D1 relates to a fault-tolerant load-sharing system for processing messages; see figure 1. The system comprises a plurality of channels (10, 12, 14), each comprising an input queue feeding a processor (34, 36, 38). Incoming messages are added to the shortest input queue; see column 3, lines 37 to 41, column 4, lines 58 to 62, and figure 4; step 73, in particular "queue entries".

4.2 If a processor fails then the "backup channel" (see column 6, lines 26 to 29) reassigns messages in the input queue of the failed processor to the remaining active channels, starting with the channel with the shortest input queue; see abstract, last sentence, column 6, lines 2 to 43, and figure 7; step 118. Reassignment occurs based on the same criterion as the original message assignment, namely starting with the channel having the shortest input queue; see column 6, lines 40 to 43.

4.3 The appellant has argued that D1 does not disclose an input buffer or an event queue length. The board disagrees in view of the references in D1 to the number of queue entries waiting to be processed by each processor; see figure 4; step 73 and figure 7; step 118. These steps refer to assigning a message to the processor with the "smallest number of queue entries waiting to be processed". The board understands this number to be the event queue length.

4.4 The disclosure in D1 of how messages are redistributed when a processor fails (see figure 7 and column 6, lines 15 to 43) comes closest to the subject-matter of claim 1 of the main request. The process in D1 of finding the traffic processor with the smallest number of queue entries (steps 73 and 118) does not go as far as disclosing the sorting of processors into ascending order of queue length.

4.5 The following comparison of claim 1 and D1 uses the term "traffic parameter" to cover both queue length and (total) traffic load.

4.6 D1 discloses a method for distributing event delivery to a set of traffic processors (34, 36, 38) in a telecommunication network, the method comprising the steps of:

- obtaining a status for each active traffic processor of the set of processors in the telecommunication network, the status comprising an event queue length associated with a traffic processor (see figure 7; step 118);

- determining a traffic processor from the set of traffic processors with the lowest traffic parameter (event queue length; see figure 7; step 118);

- selecting an event group manager (see figure 1; disk controller 24 and disk drive 22 of channel 10), the event group manager is an event scheduler that manages the traffic processor (34) of the set of traffic processors with the lowest traffic parameter (implicit in redistributing messages to processor 34) and

- re-distributing the events of a failed traffic processor among the traffic processors starting with the traffic processor having the lowest traffic parameter; see figure 7; step 118.

5. Inventive step, Article 56 EPC

5.1 The appealed decision

5.1.1 Claim 1 of the present main request is the same as that in the decision. According to the decision, the following features, termed "dangling features", yielded results which were not then used in the method of distributing event delivery, thus having no technical effect and not contributing to the solution of a technical problem:

a. obtaining a status for each active traffic processor of the set of processors in the telecommunication network, the status comprising the current traffic load of a traffic processor and the event queue length of a traffic processor;

b. selecting an event scheduler group manager, the event scheduler group manager being an event scheduler that manages the traffic processor of the set of traffic processors with the lowest traffic load and

c. retrieving a time slot table for each traffic processor of the set of traffic processors.

5.1.2 These features were consequently not taken into consideration in the analysis of inventive step.

5.2 The appeal

Features "a" and "b", defined in the decision, had the technical effect that the order of increasing traffic processor loading could be more accurately determined, whilst features "b" and "c" had the technical effect of more controlled, balanced redistribution among the remaining active traffic processors, avoiding the overloading of individual processors. Features "a", "b" and "c" had a synergistic effect, together improving load re-balancing, failure tolerance and system efficiency.

5.2.1 As to inventive step, D1 and the invention lay in different technical fields, since D1 did not use an input buffer. Moreover the skilled person, starting from D1 and faced with the above problem, would have realized that D1 did not mention a need to improve its method of re-assignment, in particular by taking into account future events waiting in an incoming buffer in determining the real total traffic load. D1 also did not hint at dynamically determining an event queue length threshold, or redistributing events to processors in a certain order. Thus there was no reason for the skilled person to add the above difference features.

5.2.2 The appealed decision was insufficiently reasoned as to why the following feature (the appellant dividing the feature into three partial-features) produced a result which was not subsequently used:

"obtaining [partial feature d.1:] a status for each active traffic processor of the set of processors in the telecommunication network, the status comprising [partial feature d.2:] the current traffic load of a traffic processor and [partial feature d.3:] the event queue length of a traffic processor".

On the contrary, the current traffic load (d.2) and the current queue length (d.3) were used to determine the total traffic load and the allowable event queue, both being used to sort the traffic processors.

5.2.3 The decision also did not explain what was meant by construing the redistribution of events to the remaining traffic processors "until the allowable event queue length of the respective traffic processor is reached" in "very general terms". It was not clear why the feature had to be construed in this way or what the result of this construction was. The appellant argued that claim 1 set out determining an allowable queue length for each remaining traffic processor and only redistributing events to a processor up to its respective allowable queue length.

5.2.4 The appellant also contested the finding in the decision (reasons, point 7.1) that the "the proposed redistribution algorithm proceeded traffic processor by traffic processor, filling up each event queue up to the allowable queue length" could not be construed from the claims. The appellant pointed to inter alia the sorting step and the redistribution step "until the allowable event queue length of the respective traffic processor is reached".

5.2.5 Regarding the auxiliary request, the appellant argued that, compared to claim 1 of the main request, claim 1 now also set out the formula used to calculate the maximum event queue length for each processor. D1 was not concerned with redistributing events based on allowable event queue lengths and gave no hint in the direction of such a formula.

6. The sufficiency of reasoning in the decision, Rule 111(2) EPC

On page 7 of the grounds of appeal the appellant states that the decision was not "sufficiently substantiated", but makes no reference to Rule 111(2) EPC. Rather, the appellant argues why the examining division's interpretation of the claims was inaccurate and led to the wrong conclusion. The reasons given in the decision are at times brief, but the appellant has not pointed to a link in the chain of argument that is missing, and the board is also unaware of any. The board concludes that the decision complies with Rule 111(2) EPC.

7. The board's finding on inventive step, Article 56 EPC

7.1 The following reasoning was set out in the board's provisional opinion. The appellant has not filed any counter-arguments.

7.2 In view of the above, the subject-matter of claim 1 of the main request differs from the disclosure of D1 in that:

a. said status also comprises the current traffic load of the traffic processor;

b. the traffic parameter is the traffic load determined for each of the set of traffic processors based on a weighting factor, the event queue length of a traffic processor and the current traffic load;

c. sorting the set of traffic processors from the traffic processor having the lowest to that with the highest traffic parameter;

d. retrieving a time slot table for each of the set of traffic processors;

e. determining an allowable event queue length for each of the set of traffic processors, the event queue length being a determined threshold for redistributing event delivery, wherein the allowable event queue length is based on the current traffic load, an optimal traffic load and a maximum event queue length and

f. said messages are re-distributed to each remaining processor until the allowable event queue length of the respective traffic processor is reached.

7.3 D1 teaches the skilled person to redistribute the tasks of a failed processor to the remaining traffic processor with the shortest input queue. The board however takes the view that the skilled person would not continue to apply this teaching in an unmodified fashion if there were so many events to redistribute that the processor with the shortest queue would become overloaded. The skilled person starting from D1 would consider some form of maximum queue length to avoid such overloading. Hence difference "f" follows from D1 as a usual matter of design by the skilled person. The board also shares the conclusion reached in the decision (point 5.2), and the reasons leading to it, that difference "d" (retrieving a time slot table) has no technical effect and thus cannot contribute to inventive step. Difference "a" (obtaining the current traffic load) is inevitably present if feature "b" (using current traffic load) is. Hence inventive step depends on features "b" (determination of traffic load), "c" (sorting processors by order of traffic load) and "e" (determination of an allowable event queue length). These features are technically linked in that they all depend on the current traffic load of a processor.

7.4 The formulae for the "traffic load" (difference "b") and the "allowable event queue length" (difference "e") are expressed so broadly that they do not restrict the subject-matter of the claims to one having a technical effect over D1. The appellant has not shown that these features have a technical effect. Without a technical effect, these features are unable to contribute to inventive step. This objection also applies to the independent claims of the auxiliary request in which the detailed formula for the maximum event queue length does not limit the claim to cases where a technical effect accrues. Again, the appellant has not shown that a technical effect accrues in this case either.

7.5 The sorting step "c" seems to address the obvious problem of redistributing events in the minimum number of steps by filling up the queues of the processors in order of decreasing queue length. This is a usual redistribution strategy for the skilled person.

7.6 Contrary to the appellant's arguments, there is no disclosure that considering traffic load as well as event queue length allows traffic processors to be allocated "more accurately" or that an "optimal" distribution is achieved.

7.7 Hence the board finds that the subject-matter of claim 1 of both requests does not involve an inventive step, Article 56 EPC, in view of D1.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation