|European Case Law Identifier:||ECLI:EP:BA:2012:T124109.20121026|
|Date of decision:||26 October 2012|
|Case number:||T 1241/09|
|IPC class:||G06F 17/30|
|Language of proceedings:||EN|
|Download and more information:||
|Title of application:||Method and computer system for data retrieval|
|Applicant name:||SAP AG|
|Relevant legal provisions:||
|Keywords:||Inventive step - no|
Summary of Facts and Submissions
I. European patent application number 03 028 314 (publication number EP 1 542 136 A1) was filed in 2003 for an invention related to data retrieval using a customised index for searching data in multiple data sources.
II. In oral proceedings on 11 November 2008, the examining division refused the application on the basis of a set of claims filed by a letter dated 11 April 2008. According to the decision in writing posted on 26 November 2008, the subject matter of the independent claims did not involve an inventive step in the light of the following documents D2 and D3, document D2 representing the closest prior art:
D2: Hu J. et al.: "Locating Patient Data among Multiple Heterogeneous Medical Databases", Information and Software Technology, [Online] vol. 35, no. 8, August 1993, pages 439-447, retrieved from the Internet on 29 April 2004.
D3: Zerner L.: "Site Search and Retrieval Tools" Internet article, [Online] June 1997, retrieved from the Internet on 29 April 2004.
III. The appellant (applicant) lodged an appeal against the refusal decision on 23 January 2009. By a letter dated and received on 31 March 2009, the appellant filed a statement setting out the grounds of appeal and two sets of claims as main and auxiliary requests. Furthermore, it was submitted that the examining division committed a procedural violation by having granted interlocutory revision against a first refusal dated 20 December 2007, since neither the requirements for a reformatory revision nor those for a cassatory revision had been met. The claims of the main request correspond identically to claims already filed with the letter of 11 April 2008 (see above). Claim 1 of the auxiliary request reads as follows (underlining added):
"1. A computer system (999) for data retrieval comprising first data storage means (901) and second data storage means (902), the first data storage means (901) including a file system (101) and having a customised index (201a) according to individual needs being interfaced (990) to the second data storage means (902) including a relational database (102) and an index table (202);
wherein the customised index (201a) is defined to reflect preferences with respect to the search criteria and describes a limited set of search criteria, the customised index (201a) includes both, an index for the first data storage means (901) and a corresponding index for the second data storage means (902), wherein the customised index (201a) is relatively small when compared to the index table (201a) and the customized index (201a) is independent from the data storage means (901, 902),
wherein data records of the customised index (201a) that relate to the first data storage means (901) include search fields and at least one further search attribute indicating a position of the corresponding data in the file system (101), and
wherein data records of the customised index (201a) that relate to the second data storage means (902) include only search fields; and
wherein the computer system (999) is configured to perform a search for data in the first data storage means (901) and in the second data storage means (902) and comprises a central reporting framework (301) for applying a search algorithm to determine the origin of the data to be searched from the customised index (201a),
wherein the customised index (201a) is used instead of the index table (202) to access the relational database (102),
wherein the reporting framework applies the search algorithm to either the file system (101) or the relational database (102) dependent on the value of the further search attribute in the data record of the customised index (201a)."
In claim 1 of the main request the passages underlined above are omitted.
IV. In a communication accompanying the summons to oral proceedings, the Board set out its provisional opinion. In oral proceedings before the Board on 26 October 2012, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request or the auxiliary request filed with the statement setting out the grounds of appeal dated 31 March 2009.
V. The arguments of the appellant submitted in writing and orally in support of the patentability of the invention are summarised as follows:
Document D2 disclosed a patient data system for data retrieval with local indexes -- local to each site -- and a global index -- remote from all sites -- for storing details about where in a plurality of interconnected data storage means information about a patient can be found. The global index was a combination of all the local indexes of the interconnected databases, used only for occasional searches and for global index maintenance. This was an essential structural difference to the customised index of the invention which comprised unified definitions for each of the data sources. Document D2 disclosed the operation on different data stored at different sites in the same kind of data storage system, namely relational databases, whereas the invention used a single customised index and operated on the same data, said data being stored in different kinds of data storage systems, namely in a file system and a relational database.
The objective technical problem solved by the invention was the improvement of the search performance when searching data of multiple sources. This problem was neither addressed nor solved in document D2. The global and local indexes were simply not designed to be used in a manner to search over different kinds of data storage devices. In combination with document D3, the skilled person would arrive at an index similar to that of D2, which was inherently different from the customised index of the invention.
Reasons for the Decision
1. The appeal, although admissible, is not allowable since both requests before the Board are unsuccessful for lack of inventive step in the respective claim 1 of the requests.
2. The following statement of the reasons for lack of inventive step is confined to claim 1 of the auxiliary request since this claim contains all the features of claim 1 of the main request.
2.1 Document D2 is undisputedly an appropriate starting point for judging inventive step. This document describes the architecture of a patient data sharing system for connecting existing heterogeneous medical databases (see the title) and a specific prototype of such a system interconnecting four different databases at three sites via a communication network (see D2, page 443 ff.). The preferred solution for providing access to and communications between heterogeneous databases relies on local indexes and a global index, both types of indexes having the same composition and providing the same set of standard attributes agreed on within the entire system. Each participating database keeps a mapping between the standard attributes and its local schema (see page 443 and figures 2 and 3) so that a user at an arbitrary site can fetch subsets of the patients medical record from other databases, without knowledge of their schema details (see D2, page 446, 1st col., 2nd par.).
2.2 Hence, document D2 discloses, in terms of claim 1, a computer system (prototype, see figure 5) for data retrieval comprising first data storage means, e.g. database 1 at site 1. This data storage means is however not said to include a file system. D2 further discloses a second data storage means including a relational database, e.g. database 4 (Oracle) at site 3. Each data storage means includes an index as shown in figure 5 and in the flowchart of figure 4. In the prototype of figure 5, the local indexes are used with heterogeneous databases and are therefore independent of the data storage means, as required by the claim. But there is no "index table" in the sense of claim 1, ie an index that is not used to access its associated relational database (claim language: "the customised index... is used instead of the index table... to access the relational database").
2.3 The local index is "customised according to individual needs" since it keeps the information about the location where the (partial) medical records of the subset of site-affiliated patients are stored. In addition, the medical records of a patient are fragmented and may be distributed over several databases (see the introductory and concluding sections of document D2) so that the medical attributes of the medical records of one and the same patient may vary from database to database and are a limited subset of the entire set of attributes maintained in the global index, a circumstance which is taken into account by index component 4 shown in figure 2 of documents D2. Since the attributes determine the available search criteria it can be said, using the phraseology of the present claims, that "the customised index is defined to reflect preferences with respect to the search criteria and describes a limited set of search criteria".
2.4 In document D2, the system architecture includes software "utilities" (see figure 4) which apply a search algorithm to determine the origin of the data to be searched (utility 2 consulting the local index, see the penultimate paragraph of page 443) and is thus a "central reporting framework" in the present phraseology. Since the D2 system locates the appropriate database on the basis of the patient ID, which is an attribute of the indexes (see index component 1 in figure 2), the reporting framework applies the search algorithm to a certain database "dependent on the value of /a/ search attribute in the data record of the customised index". The patient ID in D2, however, is not indicating a position of the corresponding data in a "file system", since - as already noted - there is no file system in D2.
2.5 Claim 1 specifies some further features of the customised index, which raise some questions about their technical meaning. According to the claim wording (see above), the customised index "includes both, an index for the first data storage means ... and a corresponding index for the second data storage means ..., wherein data records of the customised index (201a) that relate to the first data storage means (901) include search fields and at least one further search attribute indicating a position of the corresponding data in the file system (101), and
wherein data records of the customised index (201a) that relate to the second data storage means (902) include only search fields".
In normal terminology, an index is a data file in which each entry consists of two values, a data value and a pointer, the data value being the value for some key field of the indexed database whereas the pointer identifies a record of that database. Thus an index that includes "only search fields", ie which has no pointers, strictly speaking makes no technical sense (cf. the "index for the online data in the CRM database 102" in section 0016 of the published application). Neither the description of the invention nor the written and oral submissions of the appellant provide an explanation. Since the technical meaning of this feature remains unclear, it must be ignored in the assessment of inventive step.
2.6 In addition, there are doubts about the meaning of the feature that the unified customised index "includes" indexes for the first and second data storage means. Whereas figure 1 of the application shows a single index table addressing two different databases, the alternative implementation of figure 2 apparently requires a search algorithm that runs over "separate" customized index tables as formulated in section 0017 of the application. The scope of claim 1 hence is mainly confined to the embodiment shown in figure 1 and described in section 0016 of the application. The Board concludes therefrom that the term "index" is used by the application in the broader sense of figure 3 of the application, namely as including a set of records merely specifying the search fields and, directly or implicitly, the database to be accessed. Moreover, in view of the manual source selection shown in figure 3 (cf 0020: "the user can select from various data sources by using a corresponding source selection layout element") the last feature of claim 1, stating that the search algorithm is applied to either the file system or the relational database dependent on the value of the further search attribute, cannot be understood in the way that the source is chosen solely depending on this value. The contradictory disclosure merely permits the interpretation that the search attribute is (in some way) involved in the selection.
2.7 It follows that the claimed computer system differs from D2 in the following features:
- the first data storage means includes a file system;
- the search attribute indicates a position of the corresponding data in such a file system;
- the search algorithm is applied to either the file system or the relational database dependent on the value of the further search attribute;
- an index table that is not used to access the relational database is included in the second data storage means;
- the customised index is "relatively small when compared to the index table".
2.8 However, none of these features involve an inventive step. The use of a file system as database is well known in the prior art. In support of this statement, document D3 might be cited (cf the decision under appeal, p. 9), which already in 1997 counted file systems as well as relational databases to "enterprise information sources" (see document D3, page 8, last paragraph). There is no technical reason why one of the "heterogeneous databases" to which document D2 relates could not be a file system. Such a possibility would actually have to be taken into account by the skilled person who considers a practical application of the patient data sharing system to existing databases located in heterogeneous hardware and software environments (see the introductory section of D2). Reciting a common file system in this technical context does not involve an inventive step.
A file system would be indexed by means of "further search attributes" as claimed. It would be obvious at least to associate (cf point 2.6 above) the indication of a patient ID in D2 - which leads to the selection of the corresponding database - with such attributes. The Board notes in this context that the Appellant itself does not regard this particular choice of attribute as important: "Any other attribute serving the purpose of identifying the corresponding data source for a respective customised index table record can be used instead" (0016, last sentence).
As to the "index table", claim 1 states explicitly that it is not used in the computer system as defined by the claim. It is merely present. Thus the index table does not contribute to the solution of a technical problem and therefore cannot contribute to an inventive step.
3. In summary, claim 1 of the auxiliary request and consequently claim 1 of the main request do not meet the requirement of inventive step under Article 52 (1) EPC and Article 56 EPC 1973.
4. Since the appellant did not base any requests on the alleged procedural violation and the Board already explained in its communication why it does not share the appellant's view, it is not necessary to give any further reasons in this respect.
For these reasons it is decided that:
The appeal is dismissed.