T 1800/14 (Data compression/HARMAN BECKER) of 12.6.2019

Summary of Facts and Submissions

I. The appeal lies from the decision of the Examining Division to refuse European patent application No. 08010349.2 for lack of inventive step of the subject-matter of the independent claims of a main and an auxiliary request over document D3 cited in the contested decision as "Held: 'Data compression', Wiley&Sons, 1983".

II. In the statement of grounds of appeal the appellant requested that the decision be set aside and that a patent be granted on the basis of the main request or auxiliary request considered in the decision under appeal.

III. In a communication accompanying a summons to oral proceedings, the Board introduced the following document which seemed to correspond to document D3 cited in the decision under appeal:

D3: Held, G.; "Data Compression; Techniques and Applications; Hardware and Software Considerations", pages 18 to 20 and 26 to 40, Chichester, J. Wiley & Sons, GB, 1983.

The Board was of the preliminary opinion that claim 1 of the main and auxiliary requests did not fulfil the requirements of Articles 56 and 84 EPC. The subject-matter of claim 1 of both requests was not inventive over document D3, taking into account the standard practice of the person skilled in the art.

IV. In a letter of reply, the appellant requested that the previous auxiliary request be considered as the main request and filed a new set of claims as the auxiliary request. It also submitted arguments. In a further letter, the appellant informed the Board that it did not intend to participate in the oral proceedings.

V. Oral proceedings were held on 12 June 2019 in the absence of the appellant. At the end of the oral proceedings, the chairman pronounced the Board's decision.

VI. The appellant's final requests were that the contested decision be set aside and that a patent be granted on the basis of the main request, consisting of claims 1 to 16 filed as an auxiliary request with the letter dated 24 October 2013, or the auxiliary request, consisting of claims 1 to 16 filed with the letter dated 16 April 2019.

VII. Claim 1 of the main request reads as follows:

"Data compression method, comprising

retrieving data from a data block (5; 40; 100; 160) to be compressed, determining whether the data includes a predetermined number of repetitions of a data sequence (51; 111; 169),

selecting a packet type from a plurality of packet types for said data based on said determining, and

generating a data packet (61-63; 81; 121-123; 141; 171-173; 191) from said data (40; 100; 160), said data packet (61-63; 81; 121-123; 141; 171-173; 191) including control information (64a, 64c; 65a, 65c; 66a, 66c; 175a, 175c, 176; 177a, 177c, 178) which is set based on said selected packet type, wherein, when said data (44-49; 104-109; 164-167) includes said predetermined number of repetitions of a data sequence (51; 111; 169),

- said packet type is selected to be a second packet type,

- said data sequence (51; 111; 169), rather than the data, is included in said data packet (62; 122; 172), and

- the control information is set to include information (65c; 175c, 176) on a number of repetitions of said data sequence (51; 111; 169) in said data (44-49; 104-109; 164-167),

characterized in that said generated data packet includes size information (64b; 65b; 66b; 175b; 177b) which is set such that it indicates a storage space containing said control information,

wherein said data packet (61-63; 81; 121-123; 141; 171-173; 191) includes at least one control byte (64-66; 82; 124-126; 142; 174-178; 192, 193) which comprises said control information and said size information, wherein said size information (64b; 65b; 66b; 175b; 177b) is a size bit which indicates whether the control information is stored in only one control byte or in two control bytes."

VIII. Claim 1 of the auxiliary request differs from claim 1 of the main request in that after the text "which is set based on said selected packet type," the following text has been inserted:

"the control information including a packet type indicator indicating whether the data packet is a first packet type or a second packet type".

IX. The appellant's arguments, where relevant to this decision, are addressed in detail below.

Reasons for the Decision

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

The invention

2. The present invention concerns data compression and decompression, in particular, for use in a navigation device (see page 1, lines 8 to 13, of the original application).

2.1 In the data compression method of the invention, a data packet is generated from each data block of the original data. Data is retrieved from a data block and then it is determined whether the retrieved data includes a predetermined number of repetitions of a data sequence. Depending on the result of the determination, a packet type is selected and a data packet is generated. A data packet comprises control information, size information and payload data (page 10, line 20, to page 11, line 14, and Figure 2).

2.2 In the embodiments of Figures 4A to 6C, a data packet consists of at least one control byte and payload data, the control byte(s) including a packet type indicator, a size bit (the size information) and a counter value (see e.g. page 13, line 25, to page 14, line 25, Figure 4B). The counter value is part of the control information. If the data block does not include a predetermined number of repetitions (first data packet type), the counter value indicates the amount of payload data (e.g. in bytes) and the original data is written into the data packet. Otherwise (second data-packet type), the counter value indicates the number of repetitions of the data sequence and a copy of the data sequence is written into the data packet. The size bit is set to "1" if the control and size information together cannot be stored in a single byte, to "0" otherwise (page 12, line 5, to page 13, line 19, Figure 3).

2.3 According to the description, the invention can be used in a navigation device comprising a digital data archive, a processor and an output device such as a display. Compressed data is stored in the digital data archive using any suitable storage medium such as a hard disk, a DVD or a flash memory. The processor retrieves the compressed data from the digital data archive, decompresses it, and sends the decompressed data to the output device (page 23, line 29 to page 24, line 14).

Inventive step - claim 1 of the main request

3. It is common ground that the present invention uses run length encoding (RLE) techniques such as those described in document D3, and that document D3 is an appropriate starting point for the assessment of inventive step.

3.1 According to the RLE scheme of document D3, a string of repeated characters is converted into a compressed data string that includes a special character Sc indicating that compression follows, a data character X which was repeated in the original data and a character count Cc indicating the number of times the compressed character is to be repeated upon decompression (see page 26, last two lines, page 27, Figure 2.7). With three characters required to denote compression, RLE compression is only effective when a data string contains a sequence of four or more repeated data characters (page 27, first three lines). In the description of the RLE algorithm of Figure 2.8, document D3 explains that if the original data string does not include at least four or more repetitions of a data character, no compression is worthwhile (page 27, last paragraph, Figure 2.8).

The skilled person therefore understands from document D3 that the encoded RLE data consists of sequences of original characters and sequences (Sc, X, Cc) of compressed data starting with a special character. The RLE scheme of document D3 therefore includes two types of sequences, the second type corresponding to the format (Sc, X, Cc) selected when the data includes a predetermined number of repetitions (where the predetermined number is 4 in document D3). The fields Sc and Cc constitute control information.

3.2 In the method of document D3, control information is not added to the non-compressed sequences of encoded data ("first packet type" in the language of the claim). But, since Sc is used to indicate that a sequence is of the second type, document D3 discloses that the control information is selected on the basis of the selected sequence type.

The subject-matter of claim 1 of the main request therefore differs from the RLE method of D3 in that:

(a) a data packet is generated for each sequence, each data packet including at least one control byte;

(b) the at least one control byte comprises control information and size information indicating the storage space containing the control information;

(c) the size information is a size bit indicating whether the control information is stored in one control byte or in two control bytes.

3.3 The use of data packets has the well-known advantage of facilitating data transmission between devices or components of different types, for instance between a digital data archive and a processor in a navigation device.

In its reply to the Board's communication, the appellant agreed that the main distinguishing features related to the control byte comprising control information and size information. An object of the invention was to be able to compress data with a high compression rate when the number of repetitions of the data sequence was high.

The objective technical problem solved over the prior art can thus be expressed as how to improve the compression method of document D3 to facilitate communication and achieve a high compression rate.

3.4 It is standard practice to manage data in packets for transmission, the advantages of data packets being well known. The skilled person would therefore consider generating data packets for facilitated data communication and, starting from document D3, generating a data packet for each sequence, the packet type corresponding to the sequence type of D3. As commonly known, a data packet typically includes a header with control data, for example of one or more bytes. Feature (a) would therefore be an obvious option for the skilled person.

Regarding improving the compression rate, the appellant argued that document D3 taught away from the invention, as it disclosed that the number of repetitions was limited by the maximum value that could be stored by the bits used for the character counter. The skilled person might have considered to increase the number of bits provided for the number of repetitive characters. However, having control information of variable length was not within the customary practice of the skilled person.

As explained in the Board's preliminary opinion, control information of variable size is disclosed in the section "Utilization" starting from page 30 of document D3. This passage discloses that in an IBM system employing a special case of RLE known as "null compression", each group of two or more consecutive space characters is replaced by a special character followed by a number of repetitions in a "space count" that can store a value up to 63. If 64 or more consecutive space characters occur, an additional special character and an additional space-count character are inserted.

The Board is thus of the opinion that at the filing date it would have been obvious for the skilled person to solve the above mentioned problem by allowing the space for the counter to be extended only when needed. Since computer systems usually process data in bytes, it would be an obvious option to use one byte for the control information and extend by one byte when needed. The skilled person would also recognise that once the size of the counter is variable, size information would have to be encoded so that the decoder could interpret the data packet correctly. Using a control bit for specifying whether the size is one or two bytes would be obvious. The manner of encoding such information is a matter of routine design. The skilled person would therefore arrive at features (b) and (c) without exercising inventive skills.

3.5 Therefore, the subject-matter of claim 1 of the main request does not involve an inventive step (Article 56 EPC).

Inventive step - claim 1 of the auxiliary request

4. Claim 1 of the auxiliary request additionally specifies that the control information includes a packet type indicator indicating whether the data packet is a first or a second data packet.

Therefore, each data packet generated according to the method of claim 1 of the auxiliary request includes control information. The control information includes the packet type indicator, the size information, and the number of repetitions.

4.1 The additional feature is not disclosed in document D3.

The subject-matter of claim 1 of the auxiliary request therefore differs from the RLE method of D3 in that it includes features (a) to (c) and in that

(d) the control information further includes a packet type indicator indicating whether the data packet is of a first or a second type.

4.2 It is standard practice to include packet type indicators in packet headers in order to enable or facilitate further processing of the data packet. Feature (d) would thus constitute an obvious implementation option for the skilled person. For the reasons given for the main request, the other distinguishing features are not inventive.

4.3 In its reply to the Board's communication, the appellant did not provide any arguments specifically dealing with the additional feature of claim 1 of the auxiliary request.

4.4 Therefore, the subject-matter of claim 1 of the auxiliary request does not involve an inventive step (Article 56 EPC).

Conclusion

5. Since none of the requests on file is allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.