T 0718/10 (Format description/HARMAN BECKER) 25-02-2015

Reasons for the Decision

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

2. The invention

2.1 The invention relates to databases for navigation systems. According to the background section of the application, known databases employ customised proprietary binary (or text) data formats that minimise storage requirements and optimise data access in view of a particular application. This approach has the problem that such data formats are difficult to adapt to future unforeseen requirements and format extensions. In particular, it is difficult to adapt a navigation database to a modified more recent format in such a way that it can still be read by older software releases. The object of the invention is therefore to provide a method for managing a navigation database in an efficient and reliable manner that allows for further extensions without any loss of compatibility.

2.2 The solution proposed by the present application is to associate with the database a "format description" describing the structure of the database records and to provide the navigation software with a "parser" for interpreting the data stored in the data file in accordance with the format description. In this way, if the format of the database is changed by extending the data records with new data fields, an existing version of the navigation software is still able to use the new database.

3. Added subject-matter - Article 123(2) EPC

Independent claim 1 of the main request corresponds to claim 1 as originally filed with amendments based on the sixth paragraph ("navigation database of a navigation system" and "to a navigation software") and the seventh paragraph ("wherein the format description declares ... records") of page 3 of the originally filed description. In addition, the term "abstract machine" has been replaced with "parser" on the basis of page 3, fourth paragraph.

Dependent claims 2 to 9 correspond to originally filed claims 3 to 10, respectively. In claim 3, the term "data entities" has been replaced with "words" on the basis of page 4, first full paragraph.

Independent claim 10 corresponds to originally filed claim 11 with amendments similar to those applied to claim 1.

The main request hence complies with Article 123(2) EPC.

4. Clarity - Article 84 EPC

The clarity objections raised in the communication accompanying the summons no longer apply to the present set of claims. In addition, the description has been adapted to the claims. The main request therefore meets the requirements of Article 84 EPC.

5. Inventive step - Article 56 EPC

5.1 In its decision, the Examining Division essentially argued with respect to claim 1 of the then main request that interpreting stored data for application software in accordance with a format description was generic functionality that could be found in a variety of well-known computer technologies and was implemented in "[a]ny program that interprets, maps, or parses data to an application according to some associated metadata". Examples of such technologies were "HTML, XML, PostScript, LaTeX, and Hashing Tables". The further limitation to navigation databases was obvious.

5.2 While the Board accepts that processing XML data typically involves parsing an XML data file on the basis of metadata embedded in the file, this metadata cannot be regarded as a "format description" that declares types of records. As explained on page 2, fourth paragraph, of the original description of the present application, in an XML file data entities are stored in association with identification tags. Each tag describes only its corresponding data entities; the tags do not give a general description of all data entities stored in the file.

5.3 The other examples given by the Examining Division are even less convincing. HTML, PostScript and LaTeX are document formats that include document processing instructions. These formats are not suitable for storing generic data entities, and documents in these formats do not include a "format description" within the meaning of the claim. In addition, it is not clear to the Board how "Hashing Tables" would relate to the invention, and the contested decision does not explain this further.

5.4 The Board is hence not convinced by the inventive step reasoning set forth in the decision under appeal. It will therefore perform its own assessment, starting with selecting the closest prior art.

5.5 As discussed in the background section of the present application, the starting point for the present invention was a commonplace vehicle navigation system. Such a vehicle navigation system comprises a (navigation) database storing lists of entries representing inter alia cities, streets and points of interest, typically in a customised proprietary data format in order to minimise storage requirements and optimise data access. See page 1, second to fourth paragraphs.

5.6 The European search report cited documents D1 and D2. Document D1 relates to the generation of route maps (see abstract and column 1, lines 4 to 10). It is not concerned with database formats for such route maps. Document D2 relates to the transformation of XML documents using stylesheets (see abstract and paragraph [0001]). Neither of these documents is closer to the invention than the aforementioned commonplace vehicle navigation system, which is hence taken to be the closest prior art.

5.7 The subject-matter of claim 1 differs from this closest prior art essentially in that the navigation software accesses the data stored in the navigation database using a parser that parses the data on the basis of a format description. According to the claim, this format description "declares types of records consisting of different data types and declares a sequence of elements of the records".

The effect of these features is that the data format of the data stored in the navigation database is decoupled from the navigation software in the sense that a particular version of the navigation software continues to be functional even if the data format of the navigation database is changed, e.g. if new data fields are added. This ability to work with future data formats is known in the art as "upward compatibility".

Starting from a known navigation system as described in the background section of the application, the objective technical problem to be solved may therefore be regarded as that of ensuring compatibility of the system with future versions of the system's navigation database. Neither document D1 nor document D2 addresses this problem.

5.8 In its communication accompanying the summons to oral proceedings, the Board cited document D3. Section 2 of this document discusses the "SDF Self-Describing File Format". An SDF file consists of a descriptive header followed by a series of data records. The header describes the format of data records and specifies mnemonic names for data-record types and data-record fields. According to section 2.2, SDF files offer several advantages, one of them being the potential of upward-compatible extension, meaning that new fields or record types can be added in a way that allows old programs to accept the new data files without even needing to be recompiled (page 257, line 28, to page 259, line 5).

5.9 At the oral proceedings, the appellant did not call into question that document D3 implicitly disclosed a "parser" for parsing the data contained in an SDF file on the basis of its descriptive header. The appellant contested, however, that the skilled person would consider document D3 when looking for a solution to the problem posed.

5.10 As explained in its abstract, document D3 focuses on the use of SDF files for the purpose of building tools for gathering and visualising parallel program performance data. The field of program performance analysis is clearly remote from the field of navigation databases.

In the Board's view, the skilled person faced with the stated problem would not confine himself to navigation databases but would look for a solution in the more general field of database technology. It could further be argued that the skilled person would recognise that the teaching of sections 2 and 2.2 of document D3 is not limited to the processing of performance data, but is more generally applicable. However, document D3, while dealing with data sets comprising large numbers of data records, is not concerned with accessing individual records in a database. Instead, the SDF files of document D3 are processed as a whole, and the SDF format is primarily intended to allow information exchange between different application programs (see abstract and page 259, lines 6 to 16). SDF files are therefore not comparable to databases of navigation systems.

Hence, the Board concurs with the appellant and judges that the skilled person, faced with the problem posed, would not consider document D3.

5.11 It follows that the subject-matter of claim 1 and that of corresponding claim 10 of the main request involves an inventive step over the available prior art. By virtue of their dependency on claim 1, the same applies to the subject-matter of claims 2 to 9. The main request hence meets the requirements of Articles 52(1) and 56 EPC.

6. The Board concludes that the main request complies with the provisions of the EPC.

7. Request for reimbursement of the appeal fee

7.1 In the statement of grounds of appeal, the appellant submitted that the contested decision was based on two "completely unsupported statements" regarding the common general knowledge of the skilled person, which had both been disputed by the appellant. According to decision T 929/94 of 7 July 1998, it was inappropriate to base a ground of refusal on an unsupported statement, and doing so constituted an infringement of the right to be heard as protected by Article 113(1) EPC.

7.2 The Board first notes that decision T 929/94 does not fully support the appellant's position. The finding of a violation of Article 113(1) EPC in that case was based on the fact that the reasoning which led to the finding of an alleged fact, which reasoning was considered to form part of the essential legal and factual reasoning which had led to the refusal of the application, had not been communicated to the applicant before the decision under appeal was issued (see reasons 2.1, third to fifth paragraphs).

7.3 The two statements referred to by the appellant relate to the features of claim 1 of the then main request, specifying that the format description "declares types of records consisting of different data types and declares a sequence of elements of the records" and that the parser is "for interpreting the byte code of the format description". According to point 3 of the reasons of the contested decision, both features amounted to "an obvious implementation of common general knowledge in conjunction with basic programming skills". The Examining Division apparently considered these individual features to be part of what decision T 190/03 of 29 March 2006, reasons 16, refers to as the unwritten "mental furniture" of the person skilled in computer programming. Since the Examining Division had already made this argument earlier in the proceedings (see point 3.2 of the communication dated 12 June 2009), the Board considers that the appellant's right to be heard was respected.

7.4 In addition, it must be noted that point 3 of the reasons for the contested decision is largely superfluous in view of points 4 and 5, which contain the actual reasoning as summarised in point 5.15.1 above. This is a further reason why the disputed statements cannot lead to the finding of a substantial procedural violation.

7.5 For the sake of completeness, the Board notes that while the reasoning set forth in points 4 and 5 also does not refer to written evidence, it does list well-known examples of technologies that the Examining Division considered pertinent. The Board finds this reasoning unconvincing, but this amounts to an error of judgment, not a substantial procedural violation.

7.6 In conclusion, since the decision under appeal is not tainted by a substantial procedural violation, there is no basis for reimbursement of the appeal fee (Rule 103(1)(a) EPC).