T 2144/14 () of 7.6.2017

European Case Law Identifier: ECLI:EP:BA:2017:T214414.20170607
Date of decision: 07 June 2017
Case number: T 2144/14
Application number: 02765808.7
IPC class: A01K 89/00
G06F 11/34
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 297.191K)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: SYSTEM AND METHOD FOR RAPIDLY LOCATING HISTORICAL PERFORMANCE DATA
Applicant name: Computer Associates Think, Inc.
Opponent name: -
Board: 3.2.04
Headnote: -
Relevant legal provisions:
European Patent Convention Art 84
European Patent Convention Art 111(1)
European Patent Convention Art 123(2)
Keywords: Amendments - allowable (yes)
Claims - clarity after amendment (yes)
Claims - support in the description (yes)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. On 2 May 2014, the appellant applicant lodged an appeal against the decision of the examining division posted on 18 March 2014 refusing European patent application No. 02765808.7 pursuant to Article 97(2) EPC. The appellant paid the prescribed fee at the same time. The statement of grounds of appeal was received on 28 July 2014.

II. In its decision, the examining division held that the claimed subject matter did not meet the requirements of Article 84 EPC, because claim 1 then on file lacked clarity and was not supported by the description.

III. Oral proceedings were duly held before the Board on 7 June 2017. During the oral proceedings, the appellant filed a new set of claims as their main request and withdrew a request for reimbursement of the appeal fees that had previously been on file.

IV. The appellant requests that the decision be set aside and a patent be granted on the basis of the main request.

V. The independent claims according to the appellant's main request read as follows:

1. "A method for providing historical performance data, comprising:

storing historical performance data for an enterprise computing environment in a plurality of arrays, each array having array elements represented in at least three dimensions associated with respective performance metrics of the array elements, the performance metrics including a date metric and a resource metric;

receiving (510) a request for selected historical performance data from the historical performance data, the request including at least date and resource set performance metric requirements including a comparator and a value associated with each of a date and a resource set;

determining (515) a list of array elements from the plurality of arrays, wherein the list represents a portion of the stored historical performance data with an associated date meeting the date performance metric requirement of the received request;

sorting (520) the list of array elements from most likely to least likely to match, according to predetermined ordering criteria based on nearness of date to the date performance metric requirement of the received request; and

determining (525,530) a best match array element for the request from the sorted list, wherein the determination is altered from a default behaviour based on an option flag of the request indicating specific rules for selecting the best match, by:

traversing (525,530) the sorted list of array elements from most likely to least likely, and determining an array element having at least one of the resources of the resource set performance metric requirement, wherein the option flag alters the default behaviour that all resource set performance metric requirements must be found".

7. "A system for providing historical performance data, comprising:

means (310,400) for storing historical performance data for an enterprise computing environment in a plurality of arrays, each array having array elements represented in at least three dimensions associated with respective performance metrics of the array elements, the performance metrics including a date metric and a resource metric;

means (315) for receiving a request for selected historical performance data from historical performance data, the request including at least date and resource set performance metric requirements including a comparator and a value associated with each of a date and a resource set;

means (315) for determining a list of array elements from the plurality of arrays, wherein the list represents a portion of the stored historical performance data with an associated date meeting the date performance metric requirement of the received request;

means (315) for sorting the list of array elements from most likely to least likely to match, according to predetermined ordering criteria based on nearness of date to the date performance metric requirement of the received request; and

means (315) for determining a best match array element for the request from the sorted list, wherein the determination is altered from a default behaviour based on an option flag of the request indicating specific rules for selecting the best match, the determination comprising:

traversing (525,530) the sorted list of array elements from most likely to least likely, and determining an array element having at least one of the resources of the resource set performance metric requirement, wherein the option flag alters the default behaviour that all resource set performance metric requirements must be found".

13. "A computer-readable storage medium encoded with processing instructions for causing a computer to perform the method of any one of claims 1 to 6 when said processing instructions are executed by the computer".

VI. The appellant argued as follows:

The application as amended overcomes all the objections raised in the impugned decision and during the course of the appeal proceedings, in particular with respect to clarity, support by the description and added subject matter. The plurality of arrays defined in claim 1 are referred to as "cubes" in the application as filed. Such an array or "cube" is shown in figure 4.

Reasons for the Decision

1. The appeal is admissible.

2. Background

The application relates to retrieving historical data, from a data repository for the purpose of system performance monitoring. In particular the invention aims to provide an estimate of such data where it is incomplete (published application, paragraph bridging pages 1 and 2 and the paragraph following.

3. Added subject matter, Article 123(2) EPC, clarity and support by the description, Article 84 EPC

3.1 Claim 1 of the sole request is based on claim 1 as filed. In the following (all references to the application as filed are to the application as published), the Board summarises the amended sections of the claim, followed, for each section, by an explanation as to where the Board finds a basis in the application as filed:

3.1.1 Original claim 1 referred to performance metrics stored in "an array of at least three dimensions" in the singular. As amended, the claim refers to data stored in a plurality of arrays, having array elements represented in at least three dimensions associated with respective performance metrics including a date and resource metric.

The application as filed defines a "performance cube" as a paradigm for representing, analyzing and managing performance information and that performance cubes are "a model of sampled metrics and their values stored in a three-dimensional lattice" (page 5, lines 20 to 32 and figure 4). Thus a "performance cube" is a three dimensional array storing performance information, in other words data. Furthermore, such an array can have more than three dimensions (page 5, lines 24 to 25).

Throughout the application, a plurality of such cubes is disclosed, see for example page 7, lines 13 to 15 with figure 3, reference 310: "...the Performance Cube repository...may be a complex store containing many Cubes".

Thus, there is a basis for data stored in a plurality of such arrays of three or more dimensions.

Furthermore the dimensions of the array are associated with performance metrics including a date and a resource metric, see for example figure 4, with days on the z axis and resource on the y axis, indexing thus associating, days and resources with the stored information. Therefore there is a basis for the first feature in the application as filed.

3.1.2 Original claim 1 defined receiving metric requirements. This is amended to receiving a request for selected historical performance data...the request including at least date and resource set performance metric requirements including a comparator and a value associated with each of a date and a resource set.

The original application discloses (page 9, last two lines to page 10, first line, with figure 5) that to locate historical performance data a basic performance metric must be received, step 510. Thus receiving metric requirements in original claim 1 is a request for historical performance data.

Furthermore, the basic performance metric requirements, include a date and a resource set (page 10, line 3, original claim 3) and may include a comparator and a value for these (page 10, line 2). Thus there is a basis for a request including a comparator and value for each of a date and resource set as now claimed.

3.1.3 The step of determining (515) a list of array elements (original claim 1) is further specified to be a list from the plurality of arrays, wherein the list represents a portion of the stored historical performance data with an associated date meeting the date performance metric requirement of the received request.

As explained above there is a basis for receiving a date as a basic performance metric requirement (figure 5, step 510 again). As amended, the "determining a list" feature has a basis on page 10, lines 6 to 8 with figure 5, where the determined list is of those array elements that meet the received requirement, step 515. Thus there is a basis for the list being the portion of data meeting the date requirement.

3.1.4 Sorting the list according to predetermined ordering criteria (original claim 1) has been amended to sorting from most to least likely to match and the ordering criteria defined as based on nearness of date to the date performance metric requirement of the received request.

Exactly this most likely to match "sorting" order (based on nearness to required date) is disclosed on page 10, line 20.

3.1.5 The step of determining a best match (original claim 1) is amended to specify that the determination is altered from a default behaviour based on an option flag of the request indicating specific rules for selecting the best match, by:

traversing (525,530) the sorted list of array elements from most likely to least likely, and determining an array element having at least one of the resources of the resource set performance metric requirement, wherein the option flag alters the default behaviour that all resource set performance metric requirements must be found.

The "determining a best match" feature thus now defines that the default determination behaviour is finding all set requirements, which has a basis on page 10, lines 27 to 28, and that this is altered on the basis of an option flag so that at least one resource is found. Modification of the default behaviour by an option flag is disclosed on page 10, lines 28 to 29 and again on page 17, lines 5 to 8. Furthermore, the claimed modifying option flag (at least one of the resources need be found) is literally disclosed on page page 18, lines 7 to 9).

3.2 Therefore all features of claim 1 have a basis in the application as filed, Article 123(2) EPC. For the same reasons, the Board considers the claim to be supported by the description, Article 84 EPC.

3.3 Claim 1, Clarity, Article 84 EPC

3.3.1 In the Board's view, claim 1 is also clear. In particular, the "determining a list" step no longer determines "potentially matching" data elements but simply those that match, as could be determined by analysing reading the date data stored in the arrays, which, as the claim defines, is always present (see page 10, lines 26 to 27, cf. impugned decision, reasons 2.1.1).

3.3.2 Furthermore, the last claim feature now makes clear what the default determining best match behaviour is (all resources present) and that it is this behaviour that is altered to finding just one resource by an option flag. Therefore the objection in the impugned decision (reasons, point 2.1.2) is moot.

3.4 The Board is also satisfied that the dependent claims 2 to 6 do not add subject matter, are clear and supported by the description.

3.4.1 Claim 2 is based on original claim 3, where the metric requirements "machine identifier" and user description have a literal basis. The feature "type of data" is based on the original claim 3 feature "cube type" with page 6, table A, penultimate row, where cube type is linked to the type of data stored.

Claim 3 is based on page 16, lines 1 to 22, in particular listed point 4.

3.4.2 Claim 4 is based on page 16, lines 1 to 22, in particular listed point 6.

3.4.3 Claims 5 and 6 are based on originally filed claims 9 and 10 respectively.

3.4.4 Furthermore, the Board sees no reason as to why these claims might not be clear or might not be supported by the description, nor has this been argued in the impugned decision.

3.5 Independent (system) claim 7 is based on claim 11 as filed, with amendments corresponding to those made to claim 1. Therefore, for the same reasons as apply for claim 1, the Board holds that claim 7 does not contain added subject matter, is clear and supported by the description.

3.6 Claims 8 to 12 are dependent on claim 7 and correspond to method claims 2 to 6 in system terms. Therefore, the same positive conclusion vis-à-vis added subject matter, clarity and support by the description (see above, section 3.5) equally applies to these claims.

3.7 By the same token, independent claim 13 is based on claim 20, but now makes direct reference to claims 1 to 6, thus likewise does not add subject matter, is clear and supported by the description.

3.8 In summary, the Board finds that the claims of the main request do not contain added subject matter, Article 123(2) EPC. They are furthermore clear and supported by the description, Article 84 EPC.

4. Remittal

4.1 The decision under appeal considered only Article 84 EPC, clarity and support in the description. In the interests of overall procedural economy, the Board has also considered the issue of added subject matter, Article 123(2) EPC.

4.2 However, other issues have yet to be examined. In particular, the examining division has yet to consider, inter alia, novelty (Article 54 EPC) and inventive step (Article 56 EPC), which may require considerable investigative effort.

In view of this and in order to allow the appellant consideration of the remaining issues before the first instance, the Board considers it appropriate to exercise its discretion under Article 111(1) EPC by remitting the case to the department of first instance for further prosecution on the basis of claims 1 to 13 of the main request.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

Quick Navigation