T 1864/15 () of 1.10.2020

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division to refuse European patent application No. 09 824 007.0, published as international patent application WO 2010/051169 A2.

II. The documents cited in the decision under appeal included the following:

D1: NIKOLAUS FÄRBER ET AL: "Adaptive progressive download based on the MPEG-4 file format", Journal of Zhejiang University Science A; An International Applied Physics & Engineering Journal, Springer, Berlin, DE, Vol. 7, No. 1, 1 January 2006, pages 106-111, XP019385056, ISSN: 1862-1775, DOI: 10.1631/JZUS.2006.AS0106

D2: US 2007/0162568 A1

D5: "INTERNATIONAL STANDARD ISO/IEC 14496-12 Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", 1 January 2005, XP007914375, Retrieved from the Internet: URL: http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics_htm?csnumber=41828, [retrieved on 2009-10-19]

III. The decision under appeal was based on the ground that claims 1, 10, 14 and 15 of the main request and of the first auxiliary request did not meet the requirements of Article 84 EPC. Furthermore, the decision under appeal was based on the ground that the subject-matter of claim 1 according to the main request, the first auxiliary request and the second auxiliary request did not involve an inventive step within the meaning of Article 56 EPC and the requirements of Article 52(1) EPC were therefore not met.

IV. The applicant (hereinafter: appellant) filed notice of appeal. With the statement of grounds of appeal, the appellant maintained the main request, the first auxiliary request and the second auxiliary request underlying the decision under appeal. The appellant requested that the decision under appeal be set aside and that a European patent be granted on the basis of the claims of the main request, first auxiliary request or second auxiliary request underlying the decision under appeal.

V. The board issued a summons to oral proceedings. In a communication under Article 15(1) RPBA 2020 (Rules of Procedure of the Boards of Appeal, 2020 version, OJ EPO 2020, supplementary publication 2) annexed to the summons, the board expressed the preliminary opinion that claim 1 of the main request and the first auxiliary request was clear (Article 84 EPC) but the subject-matter of claim 1 according to all requests did not involve an inventive step (Article 56 EPC).

VI. On 1 October 2020 the board held oral proceedings. The appellant's final requests were the same as those set out in the statement of grounds of appeal. At the end of the oral proceedings, the chairman announced the board's decision.

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

"A method for providing media fragmentation, the method comprising:

receiving (210) a request for a manifest (300) from a client (110);

sending (220), in response to the received request for the manifest (300), the manifest (300) to the client (110), the manifest describing a URL, Uniform Resource Locator, convention of how a request for a file fragment is to be formatted in a URL;

receiving (230) from the client (110) a request for a file fragment (125, 130, 135), the request indicating a start time and an end time corresponding to the file fragment (125, 130, 135), the request being in a URL format defined by the manifest (300);

querying (240) a lookup table (140) for a first byte location in a media file (115) corresponding to the start time and a second byte location in the media file (115) corresponding to the end time;

extracting (250) from the media file (115) a portion of the media file (115) between the first byte location and the second byte location, the portion comprising the file fragment (125, 130, 135); and

sending (260) the file fragment (125, 130, 135) to the client (110)."

VIII. Claim 1 of the first auxiliary request reads as follows (added features with respect to claim 1 of the main request are underlined and deleted features are struck-through):

"A method for providing media fragmentation, the method comprising:

receiving (210) a request for a manifest (300) from a client (110);

sending (220), in response to the received request for the manifest (300), the manifest (300) to the client (110), the manifest describing [deleted: a URL, Uniform Resource Locator, convention of] how a request for a file fragment is to be formatted in a URL, Uniform Resource Locator;

receiving (230) from the client (110) a request for a file fragment (125, 130, 135), the request indicating a start time and an end time corresponding to the file fragment (125, 130, 135), the request being in a URL format defined by the manifest (300);

querying (240) a lookup table (140) for a first byte location in a media file (115) corresponding to the start time and a second byte location in the media file (115) corresponding to the end time;

extracting (250) from the media file (115) a portion of the media file (115) between the first byte location and the second byte location, the portion comprising the file fragment (125, 130, 135); and

sending (260) the file fragment (125, 130, 135) to the client (110)."

IX. Claim 1 of the second auxiliary request reads as follows (added features with respect to claim 1 of the main request are underlined and deleted features are struck-through):

"A method for providing media fragmentation, the method comprising:

receiving (210) a request for a manifest (300) from a client (110);

sending (220), in response to the received request for the manifest (300), the manifest (300) to the client (110), the manifest describing [deleted: a URL, Uniform Resource Locator, convention of how a request for a file fragment is to be formatted in a URL] available quality levels (310) for a file fragment (125, 130, 135);

receiving (230) from the client (110) a request for a first file fragment (125, 130, 135), the request indicating a start time and an end time corresponding to the first file fragment (125, 130, 135), the request being in a [deleted: URL] format defined by the manifest (300) and indicating a quality level for the first file fragment (125, 130, 135);

querying (240) a lookup table (140) for a first byte location in a media file (115) corresponding to the start time and a second byte location in the media file (115) corresponding to the end time;

extracting (250) from the media file (115) a portion of the media file (115) between the first byte location and the second byte location, the portion comprising the first file fragment (125, 130, 135); and

sending (260) the first file fragment (125, 130, 135) to the client (110),

wherein the method further comprises:

receiving from the client a subsequent request for a second file fragment (125, 130, 135) having a start time being the same as the end time of the first file fragment (125, 130, 135), said subsequent request indicating a quality level for the second file fragment (125, 130, 135) different from the quality level for the first file fragment (125, 130, 135)."

X. The appellant's arguments relevant to the present decision may be summarised as follows:

Main request and first auxiliary request

(a) Claim 1 specified that the "querying" step was performed after the "receiving" step because this "querying" step referred to the terms "the start time" and "the end time" which were introduced in the "receiving" step.

(b) The feature "the request indicating a start time and an end time" in claim 1 was not anticipated by a request containing a byte range.

(c) Document D1 taught a streaming architecture based on only two standards, namely the MPEG-4 file format and HTTP (see D1, page 108, left-hand column, last paragraph). Hence, starting from document D1 the person skilled in the art would not have considered document D2 because this would be contrary to these standards and thus contrary to the specific teaching of document D1.

(d) A URL convention of how a request for a file fragment is to be formatted in a URL required significantly less data to be transmitted between a server and a client than a list of specific URLs (see statement of grounds of appeal, page 4, penultimate paragraph).

(e) A set of specific URLs as specified in a moov box according to document D1 was huge. According to the MPEG-4 file format specified in document D5, for every track in the moov box specific URLs for every file fragment needed to be specified in a data reference box (see D5, Table 1 on page 11 and section 8.13 on page 23). Hence, a URL convention always required less data to be transmitted than a set of specific URLs, except in extraordinary cases.

(f) Specifying a URL convention instead of a list of specific URLs entailed fewer changes in the event that a client needed to address another server.

Second auxiliary request

(g) Document D1 did not disclose that a manifest described available quality levels for a file fragment.

(h) Document D1 did not disclose that a request received from a client indicated a quality level for a file fragment. In a client-server system according to document D1 there was no need to indicate a requested quality level because the requested track was already specified by means of a URL.

Reasons for the Decision

1. The appeal is admissible.

2. Main request, inventive step (Article 56 EPC)

2.1 According to Article 56 EPC, "[a]n invention shall be considered as involving an inventive step if, having regard to the state of the art, it is not obvious to a person skilled in the art". It is established case law that the "problem and solution approach" is an appropriate tool for assessing whether claimed subject-matter fulfils the requirements of Article 56 EPC (see Case Law of the Boards of Appeal of the European Patent Office, 9th edition 2019, I.D.2).

2.2 The examining division identified document D1 as the closest prior art for the assessment of inventive step (see decision under appeal, reasons, point 5.1). This was not contested by the appellant and the board agrees with the examining division.

2.3 The board accepts the appellant's argument that claim 1 specified the "querying" step as to be performed after the "receiving" step (see point X(a) above).

The board also considers, in the appellant's favour, that the feature "the request indicating a start time and an end time" in claim 1 is not anticipated by a request containing a byte range (see point X(b) above).

2.4 Hence, the board considers that the subject-matter of claim 1 differs from the disclosure of document D1 by the following distinguishing features:

(a1) the manifest describing a URL, Uniform Resource Locator, convention of how a request for a file fragment is to be formatted in a URL;

(a2) the request being in a URL format defined by the manifest;

(b1) the request indicating a start time and an end time;

(b2) querying a lookup table for a first byte location in a media file corresponding to the start time and a second byte location in the media file corresponding to the end time.

2.5 Re distinguishing features (a1) and (a2)

2.6 It is established case law of the boards of appeal that features which do not contribute to achieving a technical effect are to be ignored when assessing inventive step (see Case Law of the Boards of Appeal of the European Patent Office, 9th edition 2019, I.D.9.1.3(b)).

2.7 The board construes distinguishing features (a1) and (a2) as meaning that a rule is specified on how to construct URLs such that the constructed URLs are accepted by a server, without any limitation as to which part of a URL is further specified or how the overall URL is composed.

Because this URL construction rule is completely unspecified, the board cannot see any credible technical effect achieved by distinguishing features (a1) and (a2) for the reasons given below.

2.8 The appellant argued that a URL convention of how a request for a file fragment is to be formatted in a URL required significantly less data to be transmitted between a server and a client than a list of specific URLs (see point X(d) above). Hence, the technical effect achieved by distinguishing features (a1) and (a2) was to reduce the amount of data to be transmitted between a server and a client.

The board is not convinced by this argument because the amount of data needed to send the URL convention referred to in claim 1 is undetermined and may thus be even larger than the amount of data needed to transmit a list of specific URLs.

2.9 More specifically, the appellant argued that a set of URLs as specified in a moov box according to document D1 took up considerable space because, according to the MPEG-4 file format specified in document D5, the moov box had to contain a specific URL for each file fragment of a track (see D5, Table 1 and section 8.13, "data reference box (dref)"). Hence, a URL convention always required less data to be transmitted than a set of specific URLs described in a file according to the MPEG-4 file format, except in extraordinary cases (see point X(e) above).

The board is not convinced that a specific URL for every file fragment of a track is specified in a data reference box according to document D5, section 8.13. Indeed, the data reference box (dref) in Table 1 of D5 contains a URL of a track, not the URL of a track fragment (see hierarchy in Table 1). Moreover, according to sections 8.1 and 8.4 of D5, the moov box corresponds to one presentation and each presentation consists of one or more tracks. As a consequence, the number of URLs in the moov box - which is equal to the number of tracks - is much lower than the number of track fragments. In addition, the URL may be relative rather than absolute, which further reduces the space required for the URLs in the moov box (see last sentence of section 8.13.3 of D5).

The appellant argued that the following text in section 8.13 of D5 implied that the URLs were associated with file fragments of a track: "The data reference object contains a table of data references (normally URLs) that declare the location(s) of the media data used within the presentation. [...] A track may be split over several sources".

The board does not find this argument persuasive for the following reasons.

Firstly, the board notes that the word "may" renders it optional to split a track over several sources, i.e. different URLs. Secondly, the board is not convinced that the expression "several sources" relates to URLs identifying individual file fragments. If the URLs were to relate to individual file fragments, there would be no need for HTTP requests specifying byte ranges, as disclosed in document D1 (page 109, left-hand column, first paragraph), and an HTTP request could simply specify the relevant URL. For these reasons, the board considers that a single URL per track may be specified in the moov box illustrated in document D1, Figure 1.

2.10 For the above reasons, the board is not convinced that the limited number of individual URLs in the moov box according to document D1 generally takes up more space than the unspecified URL convention of claim 1.

2.11 The appellant further argued that specifying a URL convention instead of a URL list entailed fewer changes in the event that a client needed to address another server (see point X(f) above). The appellant regarded this as a further technical effect of distinguishing features (a1) and (a2).

The board is not convinced by this argument because in order to address another server, a URL identifying this server needs to be set in the URL convention. In the same manner, an MPEG-4 file format allowing relative URLs for the different tracks (see D5, section 8.13.3: "Relative URLs are permissible and are relative to the file containing the Movie Box that contains this data reference") requires a change of just one reference URL to address another server. Hence, the board does not consider this to be an additional technical effect of distinguishing features (a1) and (a2).

2.12 Re distinguishing features (b1) and (b2)

2.13 The board regards the technical effect achieved by distinguishing features (b1) and (b2) to be that operation of a client is simplified. A client can then directly request a media fragment between a certain start and end time without being required to map the start and end time to corresponding byte locations.

2.14 Hence, the board considers that the objective technical problem should be formulated as how to simplify the operation of the client.

2.15 The board holds that starting from a streaming system using HTTP as disclosed in document D1 (see D1, page 108, left-hand column, last paragraph) and faced with this problem, the person skilled in the art would consider document D2. The reason is that document D2 relates to the same technical field of streaming media content (see D2, paragraph [0002]) and in particular to an architecture in which a client and a server exchange data over the internet using HTTP (see D2, paragraph [0016]).

2.16 Document D2 discloses that time-based requests may be used as an alternative to byte-based requests from a client to a server (see D2, paragraph [0032]). Document D2 further discloses the particular format of a time-based request indicating a time range in the form of a start time and a length (see D2, paragraph [0035] and Figure 4A). Moreover, document D2 sets out that once a time-based request is received by a server the corresponding start and end byte offsets are computed by lookups to a content index (i.e. querying a lookup table) and a corresponding media fragment is obtained (see D2, paragraphs [0025] and [0036]).

2.17 The board finds that the person skilled in the art would apply these features of document D2 to a client-server system according to document D1 in order to solve the technical problem set out under point 2.14 above. In other words, the skilled person would replace the byte-based client requests described in document D1 with time-based client requests, which are then re-mapped to byte ranges in the server using an index. In so doing, the person skilled in the art would arrive at distinguishing features (b1) and (b2) in a straightforward manner.

2.18 The board is not convinced by the appellant's argument that a person skilled in the art would not consider document D2 because it would be contrary to the HTTP standard and the MPEG-4 file format standard mentioned in D1 (see point X(c) above). Firstly, the board is not convinced that using time-based requests instead of byte-based requests in HTTP requires any modification of the MPEG-4 file format specifying URLs of media data. A change from byte-based to time-based requests only changes the manner in which a sub-part of a file accessible under a URL is requested, not the URL itself (as specified for example in a dref box of the MPEG-4 media file). Secondly, document D2 explicitly refers to the HTTP standard and proposes modifying it (see D2, paragraphs [0035] and [0055]). At the same time, it is common general knowledge that standards evolve and have many different versions. Hence, the board holds that the skilled person is not barred from considering improvements, such as replacing byte-based HTTP requests with time-based HTTP requests as suggested in document D2, merely because they are not part of the current version of a standard.

2.19 Conclusion on inventive step

For the above reasons, the board concludes that the person skilled in the art would arrive at distinguishing features (b1) and (b2) in a straightforward manner and that distinguishing features (a1) and (a2) have no credible technical effect and thus cannot contribute to inventive step. As a consequence, the subject-matter of claim 1 of the main request does not involve an inventive step within the meaning of Article 56 EPC.

3. First auxiliary request, inventive step (Article 56 EPC)

3.1 Claim 1 of the first auxiliary request essentially differs from claim 1 of the main request only in that the term "a URL, Uniform Resource Locator, convention of" was deleted.

3.2 The board finds that the feature "the manifest describing how a request for a file fragment is to be formatted in a URL, Uniform Resource Locator" in claim 1 specifies, in the same way as a "URL convention", a rule on how a request for a file fragment needs to be formatted in a URL.

3.3 The appellant did not present additional arguments.

3.4 Hence, the subject-matter of claim 1 according to the first auxiliary request lacks inventive step under Article 56 EPC for the same reasons as set out in section 2 above for the main request.

4. Second auxiliary request, inventive step (Article 56 EPC)

4.1 The board finds that the subject-matter of claim 1 differs from the disclosure of document D1 by the following features:

(b1) the request indicating a start time and an end time;

(b2) querying a lookup table for a first byte location;

(c) the second file fragment has a start time being the same as the end time of the first file fragment.

4.2 The appellant argued that document D1 did not disclose that a manifest described available quality levels for a file fragment (see point X(g) above).

The board is not convinced by this argument because document D1 discloses that the moov box provides information about the various tracks, each having a different bit rate and thus representing different quality levels (see D1, Figure 1: "trak 1", "trak 2", ... "trak N" inside the "moov" box and D1, Figure 2: "Bit rate of tracks 1~7 for example AVC video sequence used in experiments. Rates in legend are average rate as signalled in moov box").

Furthermore, the appellant argued that document D1 did not disclose that a request received from a client indicated a quality level for a file fragment (see point X(h) above).

The board is not convinced by this argument because document D1 does disclose that a client can request a particular track (see D1, page 109, right-hand column, third paragraph: "the media bit rate is adapted to the available bit rate, i.e., by selecting the appropriate track, the client can assure that the available TCP throughput is twice as big") of a file in an MPEG-4 file format (see D1, page 109, left-hand column, first paragraph: "With the knowledge contained in the moov box and based on the continuous observation of the network throughput, the client requests for the appropriate parts of the file that should be transferred next"). A request for a particular track within the file according to the MPEG-4 file format will then use the URL assigned to that particular track by the dref box (see D5, Table 1 and section 8.13). Requesting specifically this URL from a server is an indication of the requested bit rate and the related quality level.

Hence, the board concludes that the features distinguishing the subject-matter of claim 1 from the disclosure of document D1 are those set out under point 4.1 above.

4.3 The board holds that it would be obvious for the person skilled in the art to arrive at distinguishing features (b1) and (b2) for the reasons set out under points 2.13 to 2.18 above in relation to the main request.

4.4 Furthermore, the boards holds that it would be obvious for the person skilled in the art faced with the problem of enabling seamless playback of streaming data to arrive at distinguishing feature (c).

4.5 Lastly, the board considers the problem of simplifying the operation of the client and the problem of enabling seamless playback of streaming data to be partial problems that the person skilled in the art would address separately.

4.6 For these reasons, the board concludes that the subject-matter of claim 1 according to the second auxiliary request does not involve an inventive step (Article 56 EPC).

5. Conclusion

As a result of the above, none of the appellant's requests is allowable.

Order

For these reasons it is decided that:

The appeal is dismissed.