T 2385/16 (Encoding and decoding apparatus/NIPPON TELEGRAPH AND TELEPHONE … of 8.11.2019

Summary of Facts and Submissions

I. The applicant (appellant) appealed against the decision of the Examining Division refusing European patent application No. 07860476.6, which claims a priority date of 9 January 2007 and was filed in Japanese as PCT/JP2007/075273 and published in English as EP 2 093 672, in accordance with Article 153(4) EPC.

II. The documents cited in the contested decision included the following.

D1: US 6,144,969, published on 7 November 2000

D2: US 5,754,848, published on 19 May 1998

D7: "APPNOTE.TXT - .ZIP File Format Specification", 29 September 2006, retrieved from URL pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.0.TXT

III. The Examining Division decided that the subject-matter of claim 1 of the then main request and first auxiliary request, both filed on 26 January 2016, and the then second auxiliary request filed during oral proceedings lacked inventive step in view of document D7.

IV. In its statement of grounds of appeal, the appellant requested that the decision be set aside and that a patent be granted on the basis of a new sole request consisting of claims 1 to 17, as submitted with the grounds, and the description and drawings as originally filed. It also submitted the following documents as prior art.

D8: "Zip files and Encoding - I hate you.", retrieved from URL marcosc.com/2008/12/zip-files-and-encoding-i-hate-you/

D9: "filename encoding in Mac vs Windows", retrieved from URL discussions.apple.com/thread/3771617?start=0&tstart=0

D10: Microsoft, "PRB: Conversion Problem Between Shift-JIS and Unicode", retrieved from

URL support.microsoft.com/en-us/kb/170559

V. In a communication under Article 15(1) RPBA 2007 (in the following, the Board refers to RPBA 2007 as RPBA) accompanying the summons to oral proceedings, among other points the Board expressed its provisional opinion that the subject-matter of claim 1 of the sole request lacked inventive step in view of document D7. It also informed the appellant that documents D8 and D9 seemed to have been published after the filing date of the application and that document D10 appeared to have been published before the priority date of the application.

VI. By letter of 8 October 2019, the appellant submitted a main request and an auxiliary request (in the following referred to as first auxiliary request) replacing the prior request.

VII. In a telephone conversation before the oral proceedings, the rapporteur informed the appellant that the Board still had concerns regarding inventive step for all requests.

VIII. Oral proceedings were held as scheduled and the appellant was heard on relevant issues. In the oral proceedings, the appellant submitted a second auxiliary request. At the end of the oral proceedings, the chairman pronounced the Board's decision.

IX. The appellant's final request was that the decision under appeal be set aside and that a patent be granted on the basis of the main request or, in the alternative, the auxiliary request, both filed with the letter dated 8 October 2019, or the second auxiliary request filed during the oral proceedings.

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

"A decoder (20) for restoring an initial file, file name, and file hierarchy from an archive file containing one or more files and/or one or more files contained in a folder together with the file name and file hierarchy information, the decoder (20) comprising:

original hierarchy information decoding means (22A) adapted to restore, if a special character coding expressing the type of a character coding recorded in association with original hierarchy information in the file hierarchy information in the archive file is a character coding that can be used in a system environment where decoding is performed, the original hierarchy information to a character string in the special character coding and restore the file name and file hierarchy; and standard hierarchy information decoding means (22A) adapted to restore, if the file hierarchy information in the archive file does not include the original hierarchy information or if the special character coding included in the original hierarchy information is not a character coding that can be used in the system environment in which decoding is performed, the file name and file hierarchy by converting a file name in a standard character coding indicated by standard hierarchy information in the archive file to a file name in the character coding that can be used in the system environment, the standard character coding being a predetermined character coding common for different system environments."

XI. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that the following text was added after the phrase "and restore the file name and file hierarchy" at the end of the original hierarchy information decoding means feature:

", the special character coding being any one of US-ASCII, EUC-JP, UTF-8 and SJIS".

XII. Claim 1 of the second auxiliary request differs from claim 1 of the first auxiliary request in that it adds the following text at the end of the claim:

"; and compatible hierarchy information decoding means (22A) adapted to restore the file name and file hierarchy from compatible hierarchy information and a compatible character coding, if the special character coding recorded in association with the original hierarchy information in the file hierarchy information in the archive file is not a character coding that can be used in the system environment in which decoding is performed and if the compatible character coding specified in the compatible hierarchy information in the archive file can be used in the system environment."

XIII. The appellant's arguments, where relevant to the decision, are discussed in detail below.

Reasons for the Decision

1. Admissibility of appeal

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

The invention

2. The application relates to encoders for encoding one or more files and/or their file hierarchy as a single archive file and decoders for restoring the initial file, file name, and file hierarchy from the archive file (description as originally filed, paragraph [0001]).

File systems manage files in hierarchies of folders. In the encoding method, a plurality of files are put into a single archive file with the file names and file hierarchy information retained, and the initial files, file names, and file hierarchy are restored from the archive file by the decoding method (description, paragraphs [0002] and [0003]; Figures 1A and 1B). Known tools for compressing and restoring this type of hierarchical file set include GZIP and WinZIP (description, paragraph [0003]).

Windows, Mac OS, and other operating systems allow a file name using Japanese kana and/or kanji to be specified. However, the Japanese kana-kanji code that can be used depends on the operating system (OS): SJIS can be used on Windows; EUC or UTF-8 can be used on Linux; and UTF-8 can be used on Mac OS. The standard kana-kanji code depends on the OS. If an archive file formed by compressing a folder by WinZIP on Windows is copied onto a Linux or Mac OS processing system, a recognizable Japanese file name cannot be restored (description, paragraph [0004]).

An object of the proposed invention is to provide an encoder that allows the file names and hierarchy information to be read correctly even if the archive file created by the encoder on a given OS or file system (system environment) is decoded in a different system environment. A corresponding decoder is also proposed (description, paragraph [0005]).

The invention proposes that the encoder normally records in the archive file two representations of the file hierarchy information (e.g. a path name containing a file name - see paragraphs [0014] and [0018] of the description): the original hierarchy information together with the type of Non-ASCII special character encoding (e.g. UTF-8, SJIS, EUC-JP); and standard hierarchy information, which uses a common standard character coding specified beforehand for different system environments (such as UTF-8 - see description, paragraph [0017]). Thus, if the special character coding used in the original hierarchy information cannot be used in the system environment of the decoder or is not included in the archive file, the decoder can restore a file name by means of conversion from the standard hierarchy information (description, paragraphs [0006] to [0008], Figures 2 and 3).

Main request and first auxiliary request - admission

3. The claims of the main request and of the first auxiliary request differ from the claims of the requests considered by the Examining Division and from those of the appellant's sole request filed with the statement of grounds of appeal in essence in that the claims relating to an encoder and an encoding method are omitted. Moreover, the first auxiliary request adds a further clarifying feature to the independent claims of the main request.

The omission of certain claims was a response to the preliminary opinion of the Board; both requests could be treated without adjournment of the oral proceedings. Consequently, the Board admitted the main request and the auxiliary request into the appeal proceedings (Article 13(1) and (3) RPBA).

Main request

4. Prior art

According to the established case law (see Case Law of the Boards of Appeal of the EPO, 9th edition 2019, I.C.2.1, I.C.3.2.3 and the decisions cited therein), under Article 54(2) EPC, the state of the art comprises everything made available to the public by means of a written or oral description, by use, or in any other way, before the filing or priority date of the European patent application. Disclosures on the internet may be part of the state of the art within the meaning of Article 54(2) EPC. Information disclosed on the internet is considered to be publicly available as of the date it was publicly posted.

4.1 Document D7

In its decision, the Examining Division used document D7, an internet disclosure, as the starting point for assessing inventive step of the claimed invention.

Document D7 is a technical specification to ensure interoperability between different vendors (see D7, section I). For this purpose, prior versions of the document have been made available to the public since 1989 (see D7, sections I, IV and XVII). D7 is version 6.3.0 of the technical specification and carries a revision date of 29 September 2006 (see page 1, first paragraph), which is more than three months before the priority date of the present application. As the Board sees no reason to doubt that document D7 was published before the priority date of the application, the Board recognises document D7 as valid prior art for the present application, noting further that this was not disputed by the appellant.

4.2 Documents D8 to D10

Documents D8 to D10 are internet disclosures that were submitted by the appellant with the statement of grounds of appeal to support its arguments in favour of inventive step. Document D8 contains dates starting from 8 December 2008 (see for example page 2, lines 14, 18 and 21; page 4, first line; page 5, last line). Document D9 contains dates starting from 29 February 2012 (see for example page 1, line before the box "I have this question too" and sixth line from the bottom; page 3, first line). As these dates are after the filing date of the present application, the Board is not convinced that these documents are prior art for the present application.

Document D10, on page 9, bears a last review date of 7 November 2005, and the Board sees no reason to doubt that it was published as Microsoft product documentation before the priority date of the application (9 January 2007). Consequently, it is prior art for the following assessment of inventive step.

5. The appellant's request

Claim 1 relates to a decoder with the following features:

A the decoder being for restoring an initial file, file name, and file hierarchy from an archive file containing one or more files and/or one or more files contained in a folder together with the file name and file hierarchy information

B original hierarchy information decoding means adapted to restore, if a special character coding expressing the type of a character coding recorded in association with original hierarchy information in the file hierarchy information in the archive file is a character coding that can be used in a system environment where decoding is performed, the original hierarchy information to a character string in the special character coding and restore the file name and file hierarchy

C standard hierarchy information decoding means adapted to restore, if the file hierarchy information in the archive file does not include the original hierarchy information or if the special character coding included in the original hierarchy information is not a character coding that can be used in the system environment in which decoding is performed, the file name and file hierarchy by converting a file name in a standard character coding indicated by standard hierarchy information in the archive file to a file name in the character coding that can be used in the system environment, the standard character coding being a predetermined character coding common for different system environments

6. Inventive step with document D7 as starting point

6.1 Document D7 was used in the contested decision as the starting point for assessing inventive step. It discloses technical information about the ZIP file format to ensure interoperability (section I). It is well known that this file format is used to archive files from a hierarchical file system into a single archive file.

6.1.1 Document D7, section V, on page 2, describes the archive file format which shows that multiple files are archived. Section V.A on page 3 of D7 describes the local file header. This section, and the paragraph about the file name on page 11, disclose that the file name and file path information are included in the archive file.

The Board agrees with the appellant that document D7 does not explicitly disclose the decoding method or a decoder for the archive file. However, the skilled person would understand that D7 implicitly discloses that a decoder is used to restore files including their file names and file hierarchy information from the archive file in ZIP file format. Hence, D7 implicitly discloses a decoder with feature A of claim 1.

6.1.2 As disclosed in appendix D, on page 49 of D7, the ZIP file format has historically supported only the original IBM PC character encoding set, commonly referred to as IBM Code Page 437. This limits the storage of file name characters to those within the original MS-DOS range of values only, and does not properly support file names in other character encodings or languages.

D7 discloses, in appendix D, that this limitation is addressed by encoding file name characters either in IBM Code Page 437 or in Unicode standard (UTF-8). If general purpose bit 11 of the ZIP file format is unset, the file name should conform to the original ZIP character encoding (i.e. IBM Code Page 437). If general purpose bit 11 is set, the filename must support the Unicode standard, version 4.1.0 or above, using the character encoding form defined by the UTF-8 storage specification. The UTF-8 character encoding is a standard character coding in the sense of claim 1 (see for example the description of the application, paragraph [0017]) as it is a predetermined character coding common to different system environments. Moreover, section I of document D7 discloses that the ZIP file format is intended to serve as a cross-platform, interoperable file storage and transfer format.

In view of the above, the skilled person understands document D7 as implicitly disclosing that if the filename field in the archive file conforms to the original ZIP character encoding the original ZIP character encoded file name and file hierarchy can generally be used by a decoding means to restore the file name and file hierarchy, provided that the original ZIP character encoding can be used in the target system environment where decoding is performed.

Moreover, the skilled person understands document D7 as implicitly disclosing that if the filename field in the archive file conforms to the standard character encoding (i.e. UTF-8) the standard character encoded file name and file hierarchy can generally be converted by a decoding means to a file name and file hierarchy in a character encoding that can be used in the target system environment. Clearly, there may be cases where the target system environment supports the standard character encoding (UTF-8) and conversion is not necessary. However, the skilled person understands that the standard character encoding (UTF-8) is not supported by all possible target system environments. Hence, the decoder needs to be adapted to perform the above-mentioned conversions.

6.1.3 In the oral proceedings, the appellant contested that document D7 implicitly disclosed aspects of decoding as indicated by the Board.

The Board is aware that document D7 does in essence disclose only the ZIP file format and not an encoder or a decoder. However, as the ZIP file format is relatively simple in its use of the file name and path information, and the encoding/decoding of the file name and path are relatively simple operations, the Board is convinced that for the skilled reader certain aspects of the decoding (as discussed above) are implicitly disclosed in document D7.

6.2 In view of the above, the Board concludes that the difference between the decoder of claim 1 and the disclosure of document D7 is that, according to claim 1, the archive file to be decoded may contain two different character encodings of the filename field, i.e. an original and a standard character encoding, and that the decoder comprises decision logic for establishing which character encoding is included in the archive file and for selecting the appropriate character encoding for decoding in the target system environment (see also the appellant's reply to the Board's summons, page 8, last paragraph, to page 9, first paragraph).

6.3 When compared to the decoder implicitly known from document D7, the decoder of claim 1 has the effect that the decoding is more efficient when the original character encoding is present in the archive file and can be used in the target system environment, since no conversion is necessary.

6.3.1 In the oral proceedings and in its statement of grounds, the appellant argued that the effect was rather that correct decoding was achieved in certain cases, such as when file names were encoded in the source and target system environments in SJIS character encoding and the decoding in the target system environment was based on UTF-8 encoded file names from an archive file. This problem was known in the art: document D10 explained that it was caused by a loss of information about the original character code before conversion (see statement of grounds of appeal, page 8, second and third paragraphs). In its written submissions, the appellant also referred to documents D8 and D9 to support its argument that the effect was to achieve correct decoding.

6.3.2 However, the Board is not persuaded by the appellant's arguments. As claim 1 is not limited either to the use of UTF-8 as standard character encoding or to the use of SJIS as character encoding in the source/target system environment, the alleged improved correctness of the decoding with respect to the problem identified in document D10 cannot be accepted as the effect of the decoder of claim 1 when starting from document D7. In particular, the use of the original hierarchy information is not limited to cases where correct decoding based on the standard hierarchy information is not possible.

Moreover, as the documents D8 and D9 are not prior art for the present case, the Board is not convinced that they can support the appellant's case.

Nevertheless, for the sake of completeness, the Board observes that it would have been obvious to adapt the teaching of document D7 to arrive at a decoder as claimed if the problem was how to improve the correctness of decoding when certain information about the original character encoding is lost in the standard character encoding, since it was a routine measure to overcome the loss of information by preserving and restoring the original hierarchy information.

6.4 With respect to the obviousness of the claimed solution, appendix D of document D7 also discloses that the ZIP file format includes an extra field which can be used to indicate commonly used character encoding (code page) designations, such as whether "modified-UTF-8" (JAVA) or UTF-8-MAC is used. According to the cited appendix, use of this extra field provides for storing data within a ZIP file in an encoding other than IBM Code Page 437 or UTF-8.

In view of this disclosure, the Board considers that it was obvious for a skilled person who was faced with the problem of how to improve the efficiency of the decoding to use UTF-8 in the ZIP file and to optionally store original hierarchy information in the extra field of the ZIP file format known from document D7. In that case it would be necessary, and hence obvious, to adapt the decoder by adding decision logic to select either the original or the standard hierarchy information for decoding by considering the availability of the original hierarchy information and the character encoding requirements imposed by the target system environment.

6.4.1 In the oral proceedings, the appellant argued that the extra field was to be used merely for storing additional information to assist an application, but not to store the original file name and path. In that case, the skilled person had to perform multiple steps in order to arrive at the solution and some of these steps were contrary to the disclosure of document D7.

The Board does not agree with the appellant. In particular, in the oral proceedings it informed the appellant that document D7 disclosed, on page 11, last paragraph, that the extra field should be used to store additional information for special needs or for specific platforms. Thus, the Board finds that it was an obvious option also to use this field to store the original file name and path.

6.5 To sum up, the skilled person would arrive at the decoder of claim 1 without exercising inventive skill. Consequently, claim 1 of the main request lacks inventive step (Article 56 EPC).

First auxiliary request

7. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that it specifies that the special character coding expressing the type of a character coding recorded in association with the

original hierarchy information is any one of US-ASCII, EUC-JP, UTF-8 and SJIS.

8. Inventive step

8.1 In the oral proceedings, the appellant argued that claim 1 of the first auxiliary request supported special character codings beyond Code Page 437, which was very limited in that respect, and UTF-8. Nothing in document D7 hinted at using any of the claimed special character codings.

8.2 The Board considers that the four special character codings US-ASCII, EUC-JP, UTF-8 and SJIS are all well-known alternative special character codings. Thus, the skilled person would consider using any of these special character codings in place of Code Page 437 when faced with the additional problem of supporting further special character codings.

As claim 1 of the first auxiliary request covers the use of US-ASCII, EUC-JP and SJIS as special character codings and UTF-8 as standard character coding, and since US-ASCII, EUC-JP and SJIS are obvious alternatives to IBM Code Page 437, the first auxiliary request does not overcome the objection regarding inventive step that applies above to claim 1 of the main request.

Consequently, claim 1 of the first auxiliary request lacks an inventive step in view of document D7 (Article 56 EPC).

Second auxiliary request

9. Admission into the appeal proceedings

9.1 The second auxiliary request was filed near the end of the oral proceedings before the Board, i.e. at a very late stage. Its admission is therefore at the Board's discretion under Article 13(1) and (3) RPBA.

9.2 Among other things, in justifying inventive step, the appellant argued that decoding and encoding differed in their additional features, in so far as the decoding in the target system environment did not have access to the original file name in the source system.

9.3 In the oral proceedings, the Board noted that the features of dependent claim 2 of the first auxiliary request that had been added to claim 1 of the second auxiliary request had never been discussed in detail in the proceedings before the Examining Division or the Board. Thus, there was no basis for their assessment in the prior proceedings.

Moreover, the appellant's argument concerning the asymmetry between encoding and decoding raised further complex issues. In particular, the decoding aspects had never been a focus of the examination of inventive step until the appellant replied to the Board's summons, and the fact of an asymmetric situation between encoding and decoding had not played a role in the proceedings so far.

9.4 Thus, the second auxiliary request presented the Board with new issues of considerable complexity, at a very late stage in the proceedings. Consequently, the Board exercises its discretion under Article 13(1) and (3) RPBA not to admit the second auxiliary request into the proceedings.

Conclusion

10. Since none of the requests admitted into the appeal proceedings is allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.