T 0729/21 (Handling data requests/AMADEUS) of 2.5.2023

Summary of Facts and Submissions

I. The applicant appealed against the decision of the examining division refusing European patent application No. 18175669.3, which is a divisional application of European patent application No. 15290199.7 (parent application, granted as EP 3 128 441 B1).

II. The following documents were cited in the first-instance proceedings:

D1:|US 2009/0228446 A1, 10 September 2009; |

D2:|C. Junghoo and H. Garcia-Molina: "Synchronizing a database to Improve Freshness", Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data, 16 May 2000, pp. 117-128;|

D3:|WO 99/22315 A1, 6 May 1999; |

D4:|D. Steiner et al.: "Oracle Web Cache Administration and Deployment Guide, Release 1.0.2.3", 2 March 2001.|

The examining division decided that the subject-matter of claims 1 to 8 and 11 to 14 lacked inventive step over document D1.

III. In its statement of grounds of appeal, the appellant maintained the claims considered in the contested decision.

IV. In a communication accompanying a summons to oral proceedings, the board introduced the following document:

D5:|WO 01/33472 A2, 10 May 2001.|

The board raised objections of double patenting and lack of clarity and expressed the view that the subject-matter of claim 1 lacked an inventive step over document D5.

V. With its written submission in preparation for the oral proceedings, the appellant replaced the claims on file with sets of claims according to a main request and auxiliary requests 1, 2 and 3.

VI. During the oral proceedings, which were held as scheduled, the appellant replaced its requests with a new sole request (filed as "Auxiliary request 0"). At the end of the oral proceedings, the Chair announced the board's decision.

VII. The appellant's final requests were that the decision under appeal be set aside and that a patent be granted on the basis of the sole request on file.

VIII. Independent claim 1 of the sole request reads as follows:

"A method for handling data requests directed to a database environment, the database environment comprising a least one first platform providing original results to be stored in a second platform as prepared results, the second platform maintaining a pool of the prepared results in order to be returned to data requests, and a control unit for processing the data requests directed to the database environment, wherein each prepared result maintained in the pool of the second platform is associated with an update indicator being a measure that the associated prepared result kept in the pool of the second platform is to be updated, the method comprising:

- receiving, by the control unit, a data request;

- determining, by the control unit, at least one prepared result corresponding to the data request;

- comparing, by the control unit, the update indicator of the determined prepared result corresponding to the data request with a threshold value;

- in response to the control unit determining that the comparison indicates a requirement to update the prepared result,

- retrieving, by the control unit from the first platform, an updated version of the at least one prepared result;

- updating, by the control unit, the prepared result in the pool of the second platform and the associated update indicator based on the updated version of the at least one prepared result by storing a new timestamp of the update of the at least one prepared result; and

- returning, by the control unit, the updated version of the at least one result,

- in response to the control unit determining that the comparison does not indicate a requirement to update the at least one prepared result,

- the control unit returning the at least one determined prepared result;

wherein the update indicator is defined by (1 - acc) · t, wherein acc is a probability that the associated prepared result is valid and t as [sic] an age of the associated prepared result, wherein acc = e**(-lambdat), wherein the validity rate lambda is an indicator of how frequently the prepared result changes."

Claims 2 to 5 are, directly or indirectly, dependent on claim 1.

Independent claim 6 reads as follows:

"A control unit for handling data requests directed to a database environment, the control unit being coupled to a first platform providing original results to be stored in a second platform as prepared results, the second platform maintaining a pool of the prepared re-sults in order to be returned to data requests, wherein each prepared result maintained by the second platform is associated with an update indicator being a measure that the associated prepared result kept in the second platform is to be updated, the control unit being arranged to:

- receive a data request;

- determine at least one prepared result corresponding to the data request;

- compare the update indicator of the determined prepared result corresponding to the data request with a threshold value;

- in response to determining that the comparison indicates a requirement to update the prepared result; [sic]

- retrieve an updated version of the at least one prepared result based on the original response data from the first platform;

- update the prepared result in the pool of the second platform and the associated update indicator based on the updated version of the at least one prepared result by storing a new timestamp of the update of the at least one prepared result; and

- return the updated version of the at least one result;

- in response to determining that the comparison does not indicate a requirement to update the at least one prepared result,

- return the determined at least one prepared result;

wherein the update indicator is defined by (1 - acc) · t, wherein acc is a probability that the associated prepared result is valid and t as [sic] an age of the associated prepared result, wherein acc = e**(-lambdat), wherein the validity rate lambda is an indicator of how frequently the prepared result changes."

Claim 7 is dependent on claim 6.

Independent claim 8 reads as follows:

"A computer program for execution by a control unit for handling data requests directed to a database environment, the control unit being coupled to a first platform providing original results to be stored in a second platform as prepared results, the second platform maintaining a pool of the prepared results in order to be returned to data requests, wherein each prepared result maintained by the second platform is associated with an update indicator being a measure that the associated prepared result kept in the second platform is to be updated, the computer program being configured to - when executed by the control unit - to cause the control unit to:

- receive a data request;

- determine at least one prepared result corresponding to the data request;

- compare the update indicator of the determined prepared result corresponding to the data request with a threshold value;

- in response to determining that the comparison indicates a requirement to update the prepared result; [sic]

- retrieve an updated version of the at least one prepared result based on the original response data from the first platform;

- update the prepared result in the pool of the second platform and the associated update indicator based on the updated version of the at least one prepared result by storing a new timestamp of the update of the at least one prepared result; and

- return the updated version of the at least one result;

- in response to determining that the comparison does not indicate a requirement to update the at least one prepared result,

- return the determined at least one prepared result;

wherein the update indicator is defined by (1 - acc) · t, wherein acc is a probability that the associated prepared result is valid and t as [sic] an age of the associated prepared result, wherein acc = e**(-lambdat), wherein the validity rate lambda is an indicator of how frequently the prepared result changes."

Claim 9 is dependent on claim 8.

Reasons for the Decision

1. The application relates to a mechanism for handling incoming data requests.

2. Admission into the appeal proceedings

2.1 The present sole request is based on the claims on which the contested decision was based, with amendments addressing the objections of double patenting and lack of clarity raised for the first time in the board's communication.

2.2 Two of the amendments were made not at the earliest opportunity, i.e. before the final date set by the board for making written submissions, but only during the oral proceedings before the board.

One of these amendments concerns the deletion of dependent claims 2 to 4. This amendment overcomes the board's clarity objection against these claims in a straightforward manner without raising any new issues.

The other amendment concerns the addition of the feature "wherein acc = e**(-lambdat), wherein the validity rate lambda is an indicator of how frequently the prepared result changes". On the one hand, this amendment overcomes the board's objection regarding the clarity of the feature "wherein acc is a probability that the associated prepared result is valid" in a straightforward manner and as anticipated by the board. On the other hand, the board has some understanding for the appellant's initial difficulty in appreciating the board's objection.

2.3 For these reasons, the board considers that there are exceptional circumstances which justify the admittance into the appeal proceedings of the present sole request (Article 13(2) RPBA 2020).

3. Double patenting

The board's objection of double patenting no longer applies to the present sole request, since the combination of claims directed to the same subject-matter as that of claim 1 of the patent granted on the parent application is no longer present.

4. Clarity

The board's objections of lack of clarity (Article 84 EPC) likewise no longer apply to the amended claims of the present sole request.

5. Added subject-matter

5.1 Independent claim 1 is based on claim 1 as filed with the following amendments taken from the description as originally filed:

- the update indicator is updated "by storing a new timestamp of the update of the at least one prepared result" (page 14, lines 14 to 16);

- "wherein acc = e**(-lambdat), wherein the validity rate lambda is an indicator of how frequently the prepared result changes" (page 10, lines 5 to 10 and 21 to 24).

5.2 Independent claims 6 and 8 were obtained by making the same amendments to originally filed independent claims 11 and 13.

5.3 The claims of the application as filed are identical to the originally filed claims of the parent application, except for the deletion of the feature "(the method) providing long-term accuracy of the prepared results" from independent claim 1. Since this feature is not present in independent claims 11 and 13 of the parent application as filed, which otherwise correspond to claim 1, this deletion does not introduce matter going beyond the content of the parent application as filed.

5.4 Hence, the subject-matter of the independent claims of the sole request does not extend beyond the content of the application as filed (Article 123(2) EPC) or of the parent application as filed (Article 76(1) EPC).

6. The invention as defined by claim 1

6.1 Claim 1 is directed to a method for handling data requests directed to a database environment.

6.2 The database environment comprises a first platform, a second platform and a control unit.

The control unit processes data requests.

The first platform provides "original results".

The second platform maintains a pool of "prepared results".

Original results provided by the first platform are to be stored as prepared results in the second platform. The prepared results maintained in the second platform are to be returned in response to data requests.

Each prepared result is associated with an "update indicator", which is a measure indicating whether the prepared result is to be updated.

6.3 When the control unit receives a data request, it determines a prepared result corresponding to the data request.

The control unit compares the update indicator associated with the prepared result with a threshold value to determine whether the prepared result is to be updated.

If the prepared result is to be updated, the control unit retrieves an updated version of the prepared result from the first platform, updates the prepared result and its update indicator, and returns the updated version of the prepared result. The update indicator is updated by storing a new timestamp of the update.

If the prepared result is not to be updated, the control unit returns the (non-updated) prepared result.

6.4 The update indicator "is defined by (1 - acc) · t, wherein acc is a probability that the associated prepared result is valid and t [is] an age of the associated prepared result". The probability "acc" is defined as "e**(-lambdat), wherein the validity rate lambda is an indicator of how frequently the prepared result changes", i.e. it is modelled as a Poisson process with a rate lambda which is dependent on the prepared result.

7. Document D5

7.1 Document D5, which was cited on page 2 of the description as filed, discloses a system for determining airline seat availability information (page 1, lines 5 to 7).

7.2 The system comprises a first platform in the form of a yield management system coupled to an airline availability system 66, which provides answers, i.e. "original results", to availability queries (Figures 1, 2 and 6; page 5, lines 29 to 33; page 7, line 29, to page 8, line 1; page 10, lines 14 to 19).

It comprises a second platform in the form of database 70, which maintains a pool of answers to queries, i.e. "prepared results" (page 8, lines 8 to 14; Figure 3).

The original results provided by the first platform are stored in the second platform as prepared results (page 12, lines 15 to 18).

Each prepared result in the database 70 is associated with an update indicator in the form of the time that has passed since the prepared result was stored, received or generated (page 10, lines 12 to 15; page 11, line 28, to page 12, line 1).

7.3 When a look-up and retrieval process 94 receives a query, it determines a prepared result corresponding to the query (page 11, lines 20 to 28).

The process then compares the prepared result's update indicator, i.e. the time that has passed since the result was stored, received or generated, with a threshold value to determine whether the result is "stale", i.e. whether it is to be updated (page 11, line 28, to page 12, line 1).

If the prepared result is to be updated, the process retrieves an updated version of the result from the first platform 66 (page 12, lines 5 to 15). The updated version is stored in the database 70 together with a timestamp and also returned as a response to the query (page 12, lines 15 to 18; page 9, lines 12 to 15).

If the prepared result is not to be updated, it is returned as a response (page 12, lines 1 to 4).

8. Document D2

8.1 Document D2 is concerned with the problem of keeping a database of cached/prepared results fresh, i.e. accurate (see sections 2 and 2.1).

Document D2 considers both a "uniform change-frequency model", in which prepared results all become outdated/inaccurate at the same rate lambda, and a "non-uniform change-frequency model", in which prepared results i change at different rates lambdai (section 2.3).

As update/synchronisation policies, document D2 considers a "uniform allocation policy", in which all elements are updated at the same rate, and a "proportional allocation policy", in which results i are updated at a frequency fi proportional to their rate of change lambdai (section 3, point 2).

Document D2 discloses that prepared results can be updated in various orders (section 3, point 3). In particular, prepared results can be updated "on demand, as they are requested" (page 121, left-hand column, third paragraph). This corresponds to how updates are performed in the present invention and in document D5.

8.2 According to section 5.1 of document D2, the uniform allocation policy performs better in terms of "freshness" than the proportional allocation policy when prepared results become inaccurate at different rates. (If prepared results all become inaccurate at the same rate, the uniform and proportional allocation policies coincide.)

According to the experimental results discussed in section 6.3 and shown in Table 6, the uniform allocation policy is not optimal but significantly better than the proportional allocation policy.

9. Inventive step

9.1 The board considers document D5 to be a suitable starting point for assessing inventive step.

In view of the analysis presented in point 7. above, the subject-matter of claim 1 differs from the disclosure of document D5 in that the update indicator is defined as "(1 - acc) · t", i.e. the prepared result is updated if "(1 - acc) · t" exceeds a threshold value, where acc = e**(-lambdat), t is the age of the prepared result, and the validity rate lambda is an indicator of how frequently the prepared result changes.

In document D5, the update indicator is "t", i.e. the prepared result is updated if its age "t" exceeds a threshold value.

9.2 The appellant submitted that the claimed update indicator "(1 - acc) · t" improved the validity (or "freshness" in the terminology of document D2) of the data kept in the cache.

9.3 In its decision, the examining division argued that, although caching, i.e. serving locally stored results instead of fetching remote results, was a technical principle, in the present case the content of the cache, i.e. of the prepared results, was not technical. The update indicator implemented a trade-off between always updating requested results and always returning the prepared results without regard to their validity. Since no technical considerations were apparent in the choice of the update indicator, this trade-off reflected a non-technical user requirement.

9.4 The board agrees that claim 1 does not express any technical use of the returned results. However, improving the functioning of a computer system in terms of speed and resource usage can itself be a technical effect, in particular if the improvement is based on technical considerations. As the examining division acknowledged, caching mechanisms are normally based on such technical considerations.

Moreover, in the present case the claimed update indicator does not merely represent a trade-off between resource usage and the validity of returned search results; rather, it implements a specific strategy which - at least according to the application - achieves a better trade-off curve (overall validity as a function of resource usage) than other update indicators.

9.5 The board therefore accepts that the distinguishing feature may in principle achieve a technical effect over the prior art. However, it still has to be assessed whether such a technical effect is credibly achieved over the whole claimed scope.

9.6 In this respect, the board first notes that the invention as defined by claim 1 assumes that the probability that a prepared result is still valid is correctly modelled by "acc = e**(-lambdat)" and that the validity rates lambda of prepared results are known or can be estimated. Since the claim includes these assumptions as limitations, they are valid over the whole scope of the claim.

In addition, the description, on page 16, lines 13 to 18, makes clear that the update indicator "(1 - acc) · t" is based on the assumption that the cost of an update is constant for all prepared results. This assumption is not necessarily valid but is nevertheless reasonable, in particular in the event that no information on the cost of an update is available and there is consequently no possibility of basing a decision to update a prepared result on the cost of the update.

9.7 The description of the present application, on page 14, line 26, to page 16, line 18, gives reasons why the claimed update indicator "(1 - acc) · t" is an improvement over the update indicator "(1 - acc)", previously known from document D3. The board considers this improvement to be credible in view of the fact that an update strategy based on the update indicator "(1 - acc)" is likely to spend (too) many resources on updating prepared results with a high rate of change, which then quickly become inaccurate again and require a new update.

However, prior-art document D5 does not use "(1 - acc)" but the age "t" of a prepared result as the update indicator.

9.8 Document D2 suggests that the uniform allocation policy performs relatively close to optimal (see point 8. above).

Under the uniform allocation policy, each prepared result i should be updated at the same update frequency fi. Since the long-term update frequency of the prepared result i can be assumed to be 1/ti (see the description of the present application on page 16, lines 3 to 8), this means that prepared results i should be updated at roughly the same age ti.

In other words, document D2 suggests that using the update indicator "t" to improve the freshness/validity of the data kept in the cache should lead to performance that is relatively close to optimal.

9.9 In its communication, the board presented the above analysis of documents D2 and D5 and expressed doubt that the claimed update indicator "(1 - acc) · t" performed better than the update indicator "t" used in document D5.

In response to the board's communication, the appellant filed the following graphs:

FORMULA/TABLE/GRAPHIC

The two graphs show the "global accuracy trend" and the "final accuracy distribution" for three update strategies labelled "no optim", "global accuracy option (first attempt)" and "long term global accuracy optim". The appellant explained that these graphs had been taken from pre-filing documentation and represented the results of a simulation performed on a test data set of 45 000 data entities. The "no optim" strategy corresponded to the update indicator "t", the "global accuracy option (first attempt)" strategy corresponded to the update indicator "(1 - acc)", and the "long term global accuracy optim" accuracy corresponded to the claimed update indicator "(1 - acc) · t". The "global accuracy trend" graph showed that using the claimed update indicator "(1 - acc) · t" resulted in a generally higher overall validity of the prepared results given the same number of updates per unit of time than using the update indicator "t" of document D5.

The appellant conceded that the update indicators "t" and "(1 - acc) · t" were equivalent if the prepared results were homogeneous in the sense that they all had the same validity rate lambda. However, this was an exotic situation that was of no practical relevance. The test data set used in the simulation was relatively homogeneous with respect to the validity rate and already showed a visible improvement.

9.10 During the oral proceedings before the board, the appellant gave the board more insight into its pre-filing documentation, which convinced the board that the three simulated strategies indeed correspond to the update indicators "t", "(1 - acc)" and "(1 - acc) · t".

The graphs confirm that the update indicators "t" and "(1 - acc) · t" both outperform the update indicator "(1 - acc)" by a significant margin. Moreover, the simulation results for the claimed update indicator "(1 - acc) · t" are slightly better than those for the update indicator "t" of document D5.

9.11 The board is aware that the simulation results presented by the appellant correspond to only a single data point and do not amount to conclusive evidence that the distinguishing feature achieves an improvement over the whole scope of claim 1.

However, this single data point is sufficient to refute the board's doubts about the credibility of the alleged technical effect, which were based solely on the teaching in document D2 that the "uniform allocation policy", corresponding to the update indicator "t" of document D5, while not optimal, is significantly better than the "proportional allocation policy", corresponding to the update indicator "(1 - acc)". In the absence of any further substantiated doubts, the board considers that it has to accept that the improvement on which the appellant relies indeed exists (see decision T 578/06, Reasons 21).

9.12 As for the appellant's concession that the update indicators "t" and "(1 - acc) · t" correspond to equivalent update strategies if all prepared results share the same validity rate lambda, the board notes that the feature of claim 1 "wherein the validity rate lambda is an indicator of how frequently the prepared result changes" expresses sufficiently clearly that each prepared result has its own (estimated) validity rate lambda. The computer-implemented method of claim 1 is therefore specifically adapted to data sets with inhomogeneous variable rates, i.e. this capability is a limiting feature of claim 1.

9.13 Hence, the board accepts that the distinguishing feature solves the technical problem of improving the validity of prepared results.

9.14 Since none of the documents D1 to D5 discloses either the claimed update indicator "(1 - acc) · t" or an update strategy which is equivalent to this update indicator, it follows that the subject-matter of independent claim 1 and of the corresponding independent claims 6 and 8 involves an inventive step (Article 56 EPC).

10. Remittal for further prosecution

10.1 In view of the above, the decision to refuse the application cannot be upheld.

10.2 However, the board has not yet examined whether the amendments made to the independent claims require adaptations to be made to the dependent claims or the description.

10.3 Moreover, reference signs may still need to be added to the claims in accordance with Rule 43(7) EPC, and typographical mistakes may need to be corrected. In particular, the text "t as an age" in independent claims 1, 6 and 8 may have to be corrected to "t is an age", and the semicolon after "in response to determining that the comparison indicates a requirement to update the prepared result" in claims 6 and 8 may have to be replaced with either a comma or a colon, for example.

10.4 The case is therefore to be remitted to the examining division for further prosecution (Article 111(1) EPC).

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the examining division for further prosecution.