T 1755/13 (History of query results/GOOGLE) of 1.10.2014

Summary of Facts and Submissions

I. The applicant (appellant) appealed against the decision of the Examining Division to refuse European patent application no. 04734329.8.

II. According to the contested decision, the subject-matter of claim 1 of the main request and of the first and second auxiliary requests lacked an inventive step, having regard to the following prior art document:

D1: EP-A-1 324 250.

III. With the statement of grounds of appeal, the appellant submitted a main request and two auxiliary requests which respectively corresponded to the main request, the first auxiliary request and the second auxiliary request considered in the decision under appeal.

IV. In a communication dated 19 May 2014, accompanying the summons to oral proceedings, the Board drew the appellant's attention to the following documents:

D5: Surajit Chaudhuri and Umeshwar Dayal: "An Overview of Data Warehousing and OLAP Technology", ACM Sigmod record 26.1 (1997), pages 65-74;

D6: Henry G. Goldberg and Ted E. Senator: "Restructuring Databases for Knowledge Discovery by Consolidation and Link Formation", KDD-95 Proceedings, 1995, S. 136-141;

D7: US-A-5 794 246;

D8: Daniel L. Moody and Mark A. R. Kortink: "From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse and Data Mart Design", Proceedings of the International Workshop on Design and Management of Data Warehouses (DMDW'2000), Stockholm, June 5-6, 2000.

According to the Board's preliminary opinion, none of the appellant's requests filed with the statement of grounds of appeal was allowable.

V. In response to the Board's communication, the appellant filed with letter dated 1 September 2014 a new third auxiliary request.

VI. Furthermore, with letter dated 3 September 2014, the appellant submitted a new fourth auxiliary request.

VII. Oral proceedings were held before the Board on 1 October 2014. The appellant submitted a fifth auxiliary request. At the end of the proceedings, the Chairman pronounced the Board's decision.

VIII. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request filed with the statement of grounds or, in the alternative, on the basis of one of the first and second auxiliary requests filed with the statement of grounds, the third auxiliary request filed with the letter dated 1 September 2014, the fourth auxiliary request filed with the letter dated 3 September 2014 and the fifth auxiliary request filed during the oral proceedings.

IX. Claim 1 according to the appellant's main request reads as follows:

"A method of maintaining a history of query results, comprising:

receiving (216) a query (104);

receiving (218) one or more results of the query (106); and

gathering context information (107) about the query;

characterised in that the method further comprises:

determining if the query was previously performed;

if the query was previously performed, determining if the results of the query are the same as the results of the previously performed query;

if the results of the query are the same as the results of the previously performed query, consolidating the query, the one or more results of the query, or the context information, or combination thereof into consolidated query data; and

storing (220) only the consolidated query data if the query and the results of the query have been previously stored."

Claim 1 according to the first auxiliary request reads as follows:

"A method of maintaining a history of query results, comprising:

receiving (216) a query (104);

receiving (218) one or more results of the query (106); and

gathering context information (107) about the query;

characterised in that the method further comprises:

determining if the query was previously performed;

if the query was previously performed, determining if the results of the query are the same as the results of the previously performed query;

if the results of the query are the same as the results of the previously performed query, consolidating the query and the one or more results of the query into consolidated query data;

storing (220) the consolidated query data if the query and the results of the query have been previously stored, such that the query and the results of the query are stored only once; and

storing the context information (107)."

Claim 1 according to the second auxiliary request reads as follows:

"A method of maintaining a history of query results, comprising:

receiving (216) a query (104);

receiving (218) one or more results of the query (106); and

gathering context information (107) about the query;

characterised in that the method further comprises:

filtering the query and the one or more results of the query into filtered query information;

determining if the query in the filtered query information was previously performed;

if the query was previously performed, determining if the results of the query are the same as the results of the previously performed query;

if the results of the query are the same as the results of the previously performed query, consolidating the query and the one or more results of the query from the filtered query information into consolidated query data;

storing (220) the consolidated query data if the query and the results of the query have been previously stored, such that the query and the results of the query are stored only once; and

storing the context information (107), wherein the context information includes a number of times the query (104) was received and a number of times the same result to the query was received."

Claim 1 according to the third auxiliary request reads as follows:

"A method of maintaining a history of query results, comprising:

receiving (216) a query (104);

receiving (218) one or more results of the query (106); and

gathering context information (107) about the query;

characterised in that the method further comprises:

determining if the query was previously performed;

if the query was previously performed, determining if the results of the query are the same as the results of the previously performed query;

if the results of the query are the same as the results of the previously performed query, consolidating the query, the one or more results of the query and the context information into consolidated query data, wherein the context information includes a number of times the query (104) was received and a number of times the same result to the query was received;

storing (220) the consolidated query data if the query and the results of the query have been previously stored, such that the query and the results of the query are stored only once."

Claim 1 according to the fourth auxiliary request reads as follows:

"A method of maintaining a history of query results in a first storage system (108), the method comprising:

receiving (216) a query (110), the query requesting information from a second storage system (114);

receiving (218) one or more results of the query (106), the results based on data stored in the second storage system (114);

filtering, based on filter criteria, the one or more results to select a portion of the results that satisfies the filter criteria;

determining that at least a portion of the query was previously performed based on a comparison between search criteria included in the query and a previously detected query stored in a cache memory of the first device;

in response to determining that the query was previously performed, determining that the results of the query are generally the same as the results of the previously performed query; and

in response to determining that the results of the query are generally the same as the results of the previously performed query, updating consolidated query data stored in association with the previously detected query such that the updated consolidated query data comprises one or more results of the query, without storing the query."

Claim 1 according to the fifth auxiliary request reads as follows:

"A method of maintaining a history of queries and results, comprising:

receiving (216) a query (104) requesting information about a product;

receiving (218) one or more results of the query (106); and

gathering context information (107) about the query;

characterised in that:

the context information (107) includes a timestamp of the query (104); and

the method further comprises:

determining if the query was previously performed;

if the query was previously performed, determining if the results of the query are the same as the results of the previously performed query;

if the results of the query are the same as the results of the previously performed query, consolidating the query, the one or more results of the query, and the context information into consolidated query data, wherein the consolidated query data includes a number of times the query (104) was received, a number of times the same result to the query was received, and times of the day the query was performed;

storing (220) the consolidated query data if the query and the results of the query have been previously stored, such that the subsequent query and corresponding result that are the same as the previously stored query and result are not stored again."

All requests comprise further independent claims which need not be considered in view of the outcome of the appeal.

X. The appellant's arguments may be summarised as follows:

The Examining Division's formulation of a technical problem that required query data to be aggregated was not correct, as the idea of aggregating/consolidating query data was part of the inventor's own solution to the actual technical problem which consisted in reducing the amount of data to be stored. In fact, by requiring query data to be aggregated, the problem formulated by the Examining Division pointed towards the invention.

Document D1 related essentially to a system for collecting transaction data to be used for defining customer profiles and for pushing products.

As it did not teach to maintain a history of queries and query results, and was essentially concerned with maintaining a history of purchases, document D1 did not constitute a suitable starting point for assessing the inventive step of the present invention.

Furthermore, D1 contained no hint or suggestion that there might be redundancy in query history data, let alone any hint or suggestion that the redundancy could be identified by determining if a query had been previously performed and if the results of the query were the same as the results of the previously performed query. D1 also did not contain any hint or suggestion that redundancy in the query history data could then be avoided by consolidating the query, the one or more results of the query, or the context information, or a combination thereof into consolidated query data, and by storing only the consolidated query data if the query and the results of the query had previously been stored. Hence, D1 did not contain any teaching that would have led the skilled person towards the claimed method. In fact, D1 taught away from the claimed subject-matter by disclosing that the "purchase and context information" was stored in its entirety every time the user made a query (D1, lines 11 to 19 of column 5).

Documents D5 and D8 related to data warehouses. Neither document referred to the storage of queries and query results. They mentioned the consolidation of data, but not the consolidation of queries. Document D6 related to a particular knowledge database and, in this case, consolidation had the purpose of detecting fraud.

A further important aspect of the present invention not covered by any of the cited documents was that consolidation of queries and query results were directly performed as the data came in. Document D7 referred to the processing of incoming data, but not of queries.

Hence, none of the cited documents had anything to do with the direct consolidation of queries and query results, if the query had been previously performed and had produced similar results. As an additional benefit of the claimed invention, the consolidated query data could be used to speed up the processing of subsequent queries.

In summary, claim 1 according to the main request involved an inventive step (Article 56 EPC).

Claim 1 according to the first auxiliary request clarified that the queries and the query results were consolidated and aimed at stressing the difference to document D1 which targeted complete transactions.

The second auxiliary request also focused on data consolidation and further comprised a filtering step which was not known from document D1.

The other auxiliary requests highlighted the essential aspects of the invention already referred to in the context of the main request and underscored the differences to the prior art.

Reasons for the Decision

1. The appeal is admissible.

2. As specified in the introductory part of the description, the present application "relates to maintaining information associated with queries performed through a querying system or application" (application as published, page 1, first paragraph).

2.1 In particular, it is observed that in "the process of accepting the queries and providing the results to the queries, a huge amount of information can be gathered about the queries and the results. The gathered information in turn may be used to gain insight and patterns in various user behaviors" (ibid. page 1, last paragraph).

Main request

3. Claim 1 according to the main request is directed to "a method of maintaining a history of query results" and comprises the following features:

(a) receiving a query;

(b) receiving one or more results of the query;

(c) gathering context information about the query;

(d) determining if the query was previously performed;

(e) if the query was previously performed, determining if the results of the query are the same as the results of the previously performed query;

(f) if the results of the query are the same as the results of the previously performed query, consolidating the query, the one or more results of the query, or the context information, or a combination thereof into consolidated query data;

(g) storing only the consolidated query data if the query and the results of the query have been previously stored.

Interpretation of claim 1

4. According to the appellant, the method of claim 1 involved two important aspects. One was maintaining a history of all incoming queries and of all the corresponding query results. The other one was storing them as consolidated query data. The advantage of maintaining a record of all queries and query results was that if the same query was made again the corresponding results on record could be quickly retrieved without having to request information from the storage system 114 (see Figure 1). As to the aspect of storing queries and query results in consolidated form, it saved storage space.

4.1.1 Although maintaining a history of queries and query results may in principle provide ready-made responses to recurring queries, there is no evidence in the present application that the disclosed method and system were conceived to serve this purpose.

4.1.2 Claim 1 includes the step of receiving one or more results of the query. However, neither the claims according to the main request nor the claims as originally filed contain any feature which specifies how or from where the query results are obtained.

4.1.3 Furthermore, there is no evidence in the description that query results may be taken from the consolidated data.

Figure 1 is a block diagram illustrating the components for maintaining a history of query results according to one embodiment of the invention. It shows a query system 108 linked to a user 102 and to a storage system 114. As explained in the description (ibid. page 5, lines 3 to 7), "when a query system 108 receives a query from a user 102, the query system 108 retrieves the information from a storage system 114".

4.1.4 The present application foresees also the possibility that the query system 108 may have a cache memory for temporarily storing previously requested information so that the query system 108 need not make a request for the same information to the storage system 114. However, there is no hint in the description that the query system 108, which returns replies to the user, might fetch information from the storage system 118 where the consolidated query data and query reply data are stored. As shown in Figure 1, data to be consolidated and stored in the storage system 118 are intercepted at the interface between the user 102 and the query system 108, or at the interface between the query system 108 and the storage system 114. As illustrated by the direction of the arrows, there is no data flow from the storage system 118 to the query system 108 or to the user 102.

4.1.5 In summary, the Board considers that steps (a), (b) and (c) of the method of claim 1 are performed by a first system that receives the query from a user, transmits it, if necessary, to a database 114, receives corresponding results, transmits them to the user and gathers context information. The remaining steps (d) to (g) are performed by another system responsible for processing and storing query data and query results.

Prior art and problem to be solved

5. According to the Examining Division, document D1 disclosed a method of maintaining a history of query results comprising features a), b), c) and the step of storing only query data (see feature h)).

5.1 Furthermore, the Examining Division noted that document D1 disclosed storing query, query results and context data at the transactional level, i.e. at high granularity. On the basis of these stored data, aggregations were performed according to non-technical specifications of reports by the subscribing vendor. An example of a non-technical specification consisted in providing only reports including query data in aggregated form.

5.1.1 The Examining Division considered that these specifications of reports were non-technical and that they could be used in formulating a technical problem. Hence, starting from D1, the Examining Division defined the problem as follows: "How to efficiently store data in order to provide only reports including query data in aggregated form".

5.1.2 In the opinion of the Examining Division, the most efficient way of storing data was to store them in the same form as the data required to produce the reports according to a subscriber's specifications. This implied storing the data in aggregated/consolidated form. As it was obvious to modify the data storage of D1 in order to store only aggregated/consolidated data, the subject-matter of claim 1 did not involve an inventive step.

5.2 The appellant has argued that the application was concerned with storing data relating to queries and query results. Although it was desirable to store these data, it could require a huge amount of storage capacity. The claimed subject-matter provided a way to reduce the quantity of data to be stored.

5.2.1 As pointed out by the appellant, the problem of reducing the quantity of data to be stored was solved by storing only consolidated query data, rather than a query and the results of that query, when certain criteria were fulfilled. To paraphrase claim 1 of the main request, consolidated query data was the only data to be stored when:

(i) the query to which the consolidated query data related had been previously performed,

(ii) the results of the query were the same as those of the previously performed query results,

(iii) the query and the results of the query had already been stored.

Thus, the claimed invention avoided the storage of multiple copies of identical queries and identical query results.

5.3 The Board concurs with the Examining Division that document D1 can be regarded as the closest available prior art.

5.4 Document D1 relates to "a system and a method of generating a sale, using a computer network" and in particular to "a mobile virtual network operators system (MVNO)" (D1, paragraph [0007]). As further explained in D1 (paragraph [0007]), "[e]ach time a customer presents a search request, the MVNO system gathers and analyzes the customer's context aware information. Such accumulated context information builds the customer's purchase history" (underlining added). Thus, the MVNO system maintains a customer database to store the purchase histories of its customers.

5.4.1 In particular (see D1, paragraph [0025]), the MVNO system 210 comprises a "purchase and context information database 240" which stores information about each customer in a customer record. Each customer record contains "the context information of each purchase by the customer". Furthermore, the "purchase and context information database 240 is updated to record every single purchase behavior 230 of the customer 200".

5.5 The appellant has argued that a fundamental difference between the present invention and D1 was the kind of data stored. Although a commercial transaction usually involved a query about a product and a corresponding response on the part of the vendor, according to the appellant D1 stored only data relating to complete transactions. On the other hand, the present invention was directed to maintaining a history of all queries and query results. This provided the additional advantage that the recorded query results could also be used to provide replies to recurring queries. The nature of the data for which a history was maintained constituted an essential aspect of the invention and was an important distinguishing feature not to be neglected when assessing the inventive step.

5.5.1 Hence, in the appellant's view, the subject-matter of claim 1 did not differ from D1 only in the way data was stored, but also and in particular because of the kind of stored data. None of the prior art documents was concerned with maintaining a history of all incoming queries, of corresponding results and context information. In view of the amount of data to be stored, the appellant has stressed that this aspect of the invention involved non-trivial technical issues.

5.6 The Board accepts that storing a great amount of data may indeed pose a technical challenge. On the other hand, it should be noted that claim 1 merely specifies "receiving a query" and "receiving one or more results of the query", and thus does not require that all, or at least a large number, of queries handled by the query system should be stored in the storage system 118. Thus, the method of claim 1 is not directly concerned with storing large amounts of data.

5.6.1 Furthermore, a "transaction" according to document D1 does not merely involve the placing of an order with a vendor and the vendor's confirmation that the order has been processed and shipped, as argued by the appellant.

5.6.2 As specified in paragraph [0032] of D1, "the MVNO system 210 assimilates the context aware purchase history of the customer 200 to classify the customer 200 into one of the preset customer profile categories". For example (see D1, paragraph [0033]), "the MVNO system 201 may classify a customer as a detail oriented customer, if prior to purchasing a phone, the customer 2000 made several inquiries about the phone...." (underlining added). Thus, the classification of a customer involves the monitoring of the customer's behaviour prior to a purchase and necessarily implies keeping a record not only of the final transaction but also of all queries that may lead to the purchase of a product. Although this information is defined in D1 as "context information of each purchase" (see D1, paragraphs [0025] and [0032]), it corresponds to a query and query results according to the present application.

5.6.3 Notwithstanding the fact that, in the Board's opinion, D1 maintains a history not only of commercial transactions, but also of queries and query results, it should be noted that in the application the term "query" has a very broad meaning. In particular, as stated in the last paragraph of page 4 (application as published), it may cover the action of ordering a product and including a shipping address and specifying a method of payment. In this case, the corresponding query result may include the action of accepting the order and providing shipment date confirmation. As the expression "query and query results" according to the application encompasses purchases, claim 1 is to be interpreted as covering also a method of maintaining a history of purchases.

5.6.4 Furthermore, even if the data collected by the method of the invention were essentially different from the data stored in D1, the Board would consider that this difference could not give any contribution to the inventive step of the claimed subject-matter. All the steps recited in claim 1 are independent of the content of the data involved or of its characteristics. It is also evident to the skilled person that the nature of the queries and of the query responses can have no effect on the way the steps of the claimed method are carried out.

5.7 In summary, the Board considers that document D1 discloses a method comprising features (a), (b) and (c) recited in claim 1 of the appellant's request.

5.7.1 As to features (d) to (g) of claim 1, they essentially specify that duplicate query data and query results are stored in a consolidated form.

5.8 Starting from document D1, a problem addressed in the present application may be seen in storing query data and query response data in a more efficient way.

5.8.1 The person skilled in the art is familiar with the task of efficiently storing and maintaining data in large databases. Various consolidation techniques for grouping together similar data or avoiding duplicate data are well known in the art.

It is for instance pointed out in D5 (first page, right-hand column, third paragraph) that historical, summarised and consolidated data is more important than detailed, individual records.

5.8.2 The appellant has objected that D5 related to data warehouses and thus dealt with a different problem. However, in the Board's view, the system shown in Figure 1 of the application also includes a data warehouse, in the sense that it is a subject-oriented integrated time-varying non-volatile collection of data that may be used in organisational decision making.

5.8.3 In the Board's opinion, it would be obvious to a skilled person to keep the data stored in the database of query and query results in consolidated form.

5.9 The appellant has conceded that it might occur to the skilled person to consolidate query data stored in a database. However, it has contested that it would be obvious to perform consolidation directly on incoming data.

5.10 The Board accepts that an aspect of the present invention is the consolidation of data as it comes in, and not the consolidation of data after it has been stored in the storage system 118, although step (g) in claim 1 may refer to the permanent storage of the data and the claim wording does not exclude that the incoming data is temporarily stored in a buffer prior to being consolidated and transferred as consolidated data to the storage system 118.

5.10.1 However, in the Board's view, it is obvious that, in order to achieve the final result of storing only consolidated data, consolidation has to be performed either on the data already stored or on the data as it comes in. Examples of consolidation of incoming data are known from the prior art (see for instance D7, column 2, lines 30 to 63).

5.10.2 It should also be noted that the application does not give any details as to how an on-the-fly consolidation of incoming data could be carried out. The authors of the description apparently assumed that at the priority date of the present application direct consolidation of incoming data was within the grasp of the person skilled in the art.

By the same token, it can be assumed that it would have been obvious to the skilled person to apply the same data consolidation technique within the context of a method of maintaining a history of query results, as it avoided the lengthy procedures required for consolidating large databases and reduced downtime for database maintenance.

5.11 In summary the Board considers that in the light of D1 and of the skilled person's general knowledge it would have been obvious to arrive at the claimed subject-matter.

First auxiliary request

6. Claim 1 according to the first auxiliary request differs from claim 1 of the main request in that features (f) and (g) are amended as follows (additions are underlined; deleted text is shown as strikethrough):

(f') if the results of the query are the same as the results of the previously performed query, consolidating the query and the one or more results of the query[deleted: , or the context information, or combinations thereof] into consolidated query data;

(g') storing [deleted: only] the consolidated query data if the query and the results of the query have been previously stored, such that the query and the results of the query are stored only once; and

Furthermore, claim 1 contains the following additional feature:

(h) storing the context information.

6.1 It is specified in the description (cf. published application, page 2, lines 21 to 29) that the method of the invention in one aspect "includes consolidating the query data and storing the consolidated query data. In this aspect, a query and one or more results of the query are received. Context information about the query is gathered. A determination is made as to whether the query was previously performed, and if the query was previously performed, the query, the one or more results of the query, or the context information, or combination thereof is consolidated into consolidated query data" (underlining added).

6.1.1 Thus, according to one aspect of the invention as disclosed in the original application, a combination of the query, the result(s) of the query and the context information are consolidated into consolidated query data and then stored.

6.1.2 In fact, as it appears from claims 1 and 3 of the application as published, a first embodiment of the invention no longer covered by any of the present requests included storing data about the query, the one or more results of the query, or the context information, or a combination thereof, whereas a third embodiment foresaw storing consolidated query data obtained by consolidating query data, query results and context information.

6.1.3 Claim 1 of the first auxiliary request, however, at least arguably implies that the context information is stored separately from the consolidated query data obtained by consolidating the query and the query result(s). This feature is not explicitly disclosed in the application as originally filed.

6.1.4 On the other hand, it could be argued that the above cited passage of the description (ibid. page 2, lines 21 to 29), by referring to the consolidation of "the query, the one, the one or more results of the query, or the context information, or combination thereof" into consolidated data, implicitly discloses the consolidation of only the query and the one or more results of the query and the separate storing of the context information which relates to individual queries and is thus less suitable for consolidation.

6.2 On balance, the Board considers that the arguments of the appellant relating to the compliance of claim 1 of the first auxiliary request with Article 123(2) EPC can be followed and that this objection raised in the communication dated 19 May 2014 need not be maintained.

Inventive step

7. The appellant has pointed out that the purpose of the amendments submitted by way of the first auxiliary request was to address an allegation by the Examining Division that the claimed subject-matter resulted in part of the information specific to a query being lost.

7.1 The gist of the method according to claim 1 of the first auxiliary request consists essentially in storing consolidated query data and corresponding context information, if the query was previously performed and the query results are unchanged.

7.1.1 It is explained in the description (see application as published, page 6, lines 18 to 22) that, "after a query and a corresponding result is stored the first time, subsequent queries and results that are the same as the previous one need not be stored again, but only have its counter incremented".

7.1.2 The incremental aggregation of increasing database sets was well known in the art. As specified in document D7, it has, inter alia, the advantage that "raw data is translated into the most current meaningful information that can be relied upon by decision makers" (D7, column 2, lines 3 to 5 and lines 47 to 52). The skilled person was furthermore aware that aggregation might cause a loss of information, such as the times of the day the queries were performed (cf. D8, page 5-6, "Operator 2: Aggregation").

However, it is evident that context information, which as a distinctive attribute of a particular query cannot be aggregated, can be stored separately, if it is considered relevant.

7.2 To the skilled person starting from D1 and wishing to store data relating to queries and query results in a manner requiring less storage space or in a form that would be more useful and understandable for decision-makers without losing information, it would appear obvious to apply standard database management techniques as exemplified, for instance, in D5, D7 and D8 (see also points 5.8.1 to 5.8.3).

In doing so, the skilled person would arrive at a method falling within the terms of claim 1 according to the first auxiliary request (Article 56 EPC).

Second auxiliary request

8. Claim 1 according to the second auxiliary request differs from claim 1 of the first auxiliary request in that it further comprises the following step:

(i) filtering the query and the one or more results of the query into filtered query information.

Furthermore steps (d) (see point 3. above) and (h)(see first auxiliary request, point 6 above) are amended as follows:

(d')determining if the query in the filtered query information was previously performed;

(h')storing the context information, wherein the context information includes a number of times the query was received and a number of times the same result to the query was received.

9. As specified in claim 4 of the application as published, a number of times the query was received and a number of times the same result to the query was received are part of the consolidated query data and not of the context data. Hence, it can be questioned whether feature (h') has sufficient support in the original application (Article 123(2) EPC).

9.1 As to feature (i) and (d'), it is a known procedure (see D7, column 1, lines 42 to 49) to filter input data before loading it into a data warehouse. Hence, these features cannot contribute to the inventive step of the claimed method.

9.1.1 Notwithstanding the objection under Article 123(2) EPC raised against feature (h'), it is known to keep a record in a database of the number of times a certain data set is received. For instance, document D7 (column 2, lines 30 to 32) relates to "a method of performing incremental aggregation of dynamically increasing database data sets". The aggregate data set consists of "data values" (i.e. numbers of pieces of certain articles) and "count values" (i.e. numbers of times data values of the article are aggregated), whereby data values and count values correspond to specific "group identifiers" (i.e. certain articles).

As specified in D7, "[i]f an inputted group identifier matches a stored group identifier, the inputted data value corresponding to the inputted group identifier, is aggregated with the stored data value corresponding to the stored group identifier. The count value corresponding to the stored group identifier is incremented by the value of one" (D7, column 2, lines 47 to 52).

9.1.2 In the Board's opinion, it would have been obvious to a person skilled in the art to combine the teaching of document D1 with standard techniques of database management, such as the filtering of input data and the incremental aggregation of dynamically increasing data sets, as shown in D7. In doing so the skilled person would have arrived at the subject-matter of claim 1 according to the second auxiliary request without involving any inventive skills (Article 56 EPC).

Third auxiliary request

10. Claim 1 according to the third auxiliary request differs from claim 1 according to the main request essentially in that the query, the one or more results of the query and the context information are consolidated into consolidated query data, and in that it further comprises the following feature:

(f') wherein the context information includes a number of times the query was received and a number of times the same result to the query was received.

Furthermore, feature (g) comprises the following clause:

(g'')such that the query and the results of the query are stored only once.

10.1 The appellant has pointed out that the third auxiliary request had been filed to overcome the Board's observations under Article 123(2) EPC to the first and second auxiliary requests, as set out in the communication dated 19 May 2014.

10.2 According to claim 4 as originally filed, a number of times the query was received and a number of times the same result to the query was received are part of the "consolidated data" and not of the context data. In claim 6 as originally filed, the context information is said to include "timestamp of the query". Claim 7 as filed specifies that "the context information includes one or more results, which the user selected to view from the one or more results of the query".

10.2.1 In the Board's view, according to the original disclosure of the application it is the time at which a query is received that is stored as context information, and not the number of times the same query is received. Thus, it is doubtful whether the amendments according to the third auxiliary request made to claim 1 of the main request comply with Article 123(2) EPC.

10.2.2 In any case, consolidation of query data performed by storing the query, the results of the query and the number of times the same query and the same query result occurs is a straightforward application of the data aggregation technique shown in D7, as observed for the second auxiliary request.

10.3 Hence, the Board comes to the conclusion that the subject-matter of claim 1 according to the third auxiliary request does not involve an inventive step within the meaning of Article 56 EPC.

Fourth auxiliary request

11. The fourth auxiliary request was filed with letter dated 3 September 2014, i.e. after the time limit ("at least a month before the date of the oral proceedings") for new submissions indicated in the Board's communication of 19 May 2014. Hence, it was filed very late in the appeal proceedings.

11.1 Far from addressing all the objections raised in the Board's communication, claim 1 of the fourth auxiliary request comprises a number of new features which are not clear and do not appear to be disclosed in the original application documents.

11.1.1 For example, claim 1 specifies that filtering, based on filter criteria, selects "a portion of the results that satisfies the filter criteria". The passage of the description cited by the appellant in support of this feature only refers to filtering, filter criteria and the fact that, as a consequence of filtering, "not all information from the query and subsequent returned result need to be stored" (application as published, page 6, lines 1 to 9).

Selecting a portion of the results appears to mean the the same as filtering the one or more results. In this case, the above feature merely specifies what filtering is about and thus seems redundant. If, however, "to select a portion" means more than just filtering, the feature has no support in the application as filed.

11.1.2 Similarly, the original application refers to the step of "filtering the query" (see for instance claim 2). However, there is no direct support for the step of "determining that at least a portion of the query was previously performed based on a comparison between search criteria included in the query and a previously detected query stored in a cache memory of the first device", as now recited in claim 1 of the fourth auxiliary request.

11.1.3 Also the step of "determining that the results of the query are generally the same as the results of the previously performed query" is not explicitly disclosed in the application as filed. The passage cited by the appellant merely specifies that "the queries need not be strictly identical" (ibid. page 6, lines 28, 29).

11.2 Furthermore, as far as it is supported by the application as originally filed, the subject-matter of claim 1 prima facie appears to result from an obvious combination of the teaching of D1 with standard procedures for database management and consolidation (Article 56 EPC).

11.3 Hence, in the exercise of its powers under Article 13(1) and (3) RPBA, the Board has decided not to admit the fourth auxiliary request into the appeal proceedings.

Fifth auxiliary request

12. Claim 1 according to the fifth auxiliary request is based on claim 1 according to the main request amended as follows:

i) it relates to a method of maintaining a history of "queries and results";

ii) a query is directed to "requesting information about a product";

iii) the context information "includes a timestamp of the query";

iv) the one or more results of the query are consolidated into consolidated query data;

v) the consolidated query data includes "a number of times the query was received, a number of times the same result to the query was received, and times of the day the query was performed";

vi) storing the consolidated query data if the query and the results of the query have been previously stored, "such that the subsequent query and corresponding result that are the same as the previously stored query and result are not stored again".

12.1 The appellant filed the fifth auxiliary request at the oral proceedings essentially to clarify several aspects of the present invention which, in its view, might not have appeared sufficiently clear from the wording of the previous requests, and to try to overcome all the outstanding objections maintained by the Board against the higher ranking requests.

12.1.1 The Board acknowledges that the wording of claim 1 according to the fifth auxiliary request constitutes a significant improvement over the previous requests. In fact, it clearly reflects the Board's understanding of the present invention.

12.1.2 Thus, in the exercise of its powers under Article 13(1) and (3) RPBA, the Board has decided to admit the fifth auxiliary request into the appeal proceedings despite its very late filing.

12.2 As specified in claim 20 of document D1, the method disclosed in that document senses and records the time of the day when the customer contacts the system.

Furthermore, document D1 (column 14, lines 6 to 18) specifies that to "establish a pattern, the MVNO system starts a timer from the time when the customer first requests a product. Using both the previous purchase history log and timer recordings, the MVNO system can establish a purchase pattern for a customer. Based on the purchase pattern, the MVNO system anticipates the customer's needs at any given time. For example, if a customer orders a pizza and a movie every Friday night, the MVNO system would not know the first few times that the customer purchases a pizza and a movie every Friday night, but, after repeated requests of the same type, over a period of time, the MVNO system will eventually detect the customer's purchase pattern."

12.2.1 Hence, the method according to document D1 keeps a record of the context information referred to in claim 1 according to the fifth auxiliary request.

12.2.2 As to the other aspects of claim 1, such as consolidated query data including a number of times the query was received and a number of times the same result to the query was received, and stored queries and query results not being stored again, they have already been dealt with in the context of the previous requests.

12.3 In summary the Board considers that it would have been obvious to the person skilled in the art, faced with the problem of improving the method of maintaining a history of purchases and inquiries about products according to D1 (cf. paragraph [0033]), to rely on the general knowledge common in the art of data consolidation and archiving. In doing so, the skilled person would have arrived at a method falling within the terms of claim 1 without exercising any inventive activity.

Hence, the subject-matter of claim 1 does not involve an inventive step within the meaning of Article 56 EPC.

13. In the result, the Board finds that none of the appellant's requests constitutes a basis for granting a patent. Consequently, the appeal has to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.