Bundespatentgericht, Urteil vom 15.06.2023, Az. 2 Ni 24/21 (EP)

[X.]ie Beklagte ist Inhaberin des auch mit Wirkung für die [X.] in [X.] Verfahrenssprache erteilten [X.] Patents EP 2 661 696 ([X.] Aktenzeichen [X.] 2011 066 777) (Streitpatent), das [X.] [X.]ezember 2011unter Inanspruchnahme der Prioritäten [X.] vom 5. Januar 2011, [X.] und [X.] 201113221682 jeweils vom 30. August 2011, angemeldet worden ist und das die Bezeichnung „Adaptive Bitrate Streaming Of Media Stored In [X.] Protocol“(Adaptives Bitraten-Streaming von in [X.] gespeicherten Medien mit [X.]) trägt.

[X.]er Hinweis auf die Erteilung des Streitpatents wurde am 6. Mai 2020 veröffentlicht. [X.]as Streitpatent geht zurück auf eine beim [X.] eingereichte [X.]eldung mit der [X.]eldenummer 11855237.1, die aus der internationalen [X.]eldung PCT/[X.]2011/066927, publiziert als WO 2012/094171 [X.], hervorgeht.

[X.]as Streitpatent betrifft das sogenannte Streaming von kodierten Medien (encoded media) mit Adaption der Bitrate ([X.], Abs. [0001]).

[X.]as in vollem Umfang angegriffene Streitpatent umfasst 13Patentansprüche,den unabhängigen Anspruch 1sowie die abhängigen [X.] bis 13.

[X.]er erteilte Patentanspruch 1 lautet gemäß EP 2 661 696 [X.] (mit an die Anlage [X.] der Klägerin angelehnter Merkmalsgliederung):

[X.]ie Klägerin stützt ihre Klage auf die Nichtigkeitsgründe der mangelnden Patentfähigkeit mit Blick auf fehlende Neuheit und fehlende erfinderische Tätigkeit sowie der unzulässigen Erweiterung.

Zur Stützung ihres Vorbringens hat die Klägerin die folgenden [X.]okumente genannt:

[X.]1 3GPP [X.] 26.234 V9.5.0 (2010-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service ([X.]); Protocols and codecs (Release 9);

[X.]2 Beitrag zum Treffen der Arbeitsgruppe [X.]/[X.] [X.]/[X.]/WG11MPEG/N11578 in [X.], [X.], Oktober 2010,im Rahmen der Standardisierung des [X.] Standards. Titel: „Text of [X.]/[X.] 23001-6: [X.]ynamic adaptive streaming over [X.] ([X.]ASH)“;

[X.]3 WO 2011/059274 [X.], angemeldet am 12. November 2010, veröffentlicht am 19. Mai 2011;

NK1 Verletzungsklageschrift der Beklagten an das [X.] vom 30. September 2020;

[X.] [X.] EP 2 661 696 [X.];

[X.] [X.], [X.] zum Aktenzeichen 60 2011 066 777.7, Stand am 19. Mai 2021;

[X.] [X.] zum Streitpatent;

NK5 Merkmalsgliederung Anspruch 1;

NK6 Hauptantrag [X.] vom 5. November 2019;

[X.] Protokoll der mündlichen Verhandlung am [X.] vom 19. [X.]ezember 2019;

[X.] Prioritätsanmeldung [X.] 2011 61/430,110 P vom 5. Januar 2011;

[X.] Prioritätsanmeldung [X.] 2011 13/221,794 vom 30. August 2011;

NK10 Prioritätsanmeldung [X.] 2011 13/221,682 vom 30. August 2011;

NK11 [X.]PTO „Patent Assignment“ zu[X.] (application number 13 221 794);

[X.] [X.]PTO „Patent Assignment“ zuNK10 (application number 13 221 682);

[X.] 3GPP [X.] 26.244 [X.] (2010-09), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end packet-switched streaming service ([X.]); [X.] (3GP) (Release 9);

NK14 Engineering Guideline H.264 / AVC Coding and Multiplexing vom 14. Mai 2009;

NK15 [X.]/[X.] 14496-14 “Part 14: [X.] format” von 2003;

[X.] Urteil des [X.] vom 11. März 2022 (Aktenzeichen: [X.]; [X.]. des Senats: betrifft nicht das [X.] 2 661 696, sondern das Patent EP 3 467 666);

NK17 Berufungsschriftsatz der Klägerin vom 14. März 2022an das [X.] (betrifft das Streitpatent);

[X.] Wikipedia-Artikel „Parser“, zuletzt bearbeitet am 12. Juli 2010, 13:01 Uhr;

NK19 Schaubild zu [X.] ([X.]) und [X.] nach [X.] 1;

[X.]0 Firmenschrift der [X.], [X.], [X.], et al.: „Portable encoding of audio-video objects, [X.] ([X.])“. Revised 2010-03-09;

[X.]1 Mitteilung des [X.]-Prüfers vom 28.Juni2022;

[X.]2 Protokoll der mündlichen Verhandlung am [X.] vom
9.September 2022;

[X.]3 [X.]-Mitteilung vom 16.September 2022.

[X.]ie Klägerin stellt den Antrag,

das [X.] Patent EP 2 661 696 mit Wirkung für das Hoheitsgebiet der [X.] in vollem Umfang für nichtig zu erklären.

[X.]ie Beklagte stellt den Antrag,

die Klage abzuweisen

hilfsweise

das [X.] Patent EP 2 661 696 unter Klageabweisung im Übrigen mit Wirkung für das Hoheitsgebiet der [X.] insoweit für nichtig zu erklären, als es über die Fassung eines der [X.] vom 15. Februar 2022, II bis V jeweils vom 27. März 2023 und [X.] jeweils vom 2. Mai 2023 – in dieser Reihenfolge – hinausgeht.

[X.]ie Beklagte erklärt in der mündlichen Verhandlung vom 15. Juni 2023, dass sie die Patentansprüche gemäß Hauptantrag und [X.] als jeweils geschlossene Anspruchssätze ansieht, die jeweils insgesamt beansprucht werden.

[X.]ie Beklagte, die das Streitpatent mit einem Hauptantrag und hilfsweise beschränkt mit 8 [X.] verteidigt, tritt der Argumentation der Klägerin in allen wesentlichen Punkten entgegen und erachtet den Gegenstand des Streitpatents für patentfähig. Hierbei komme es maßgeblich auf das im Wege der Auslegung zu ermittelnde zutreffende Verständnis der Lehre des Patentanspruchs 1 an. Auf dieser Grundlage sei der Gegenstand des Streitpatents neu gegenüber der Lehre jeder der drei [X.]ruckschriften [X.]1 bis [X.]3. Ferner sei der Gegenstand des erteilten Patentanspruchs 1 gegenüber der [X.] [X.] nicht unzulässig erweitert. [X.]ie beanspruchte Lehre sei jedenfalls in einer der Fassungen der Hilfsanträge patentfähig.

Zur Stützung ihres Vorbringens hat die Beklagte die folgenden [X.]okumente genannt:

ES-NK1 Wikipedia-Artikel „Client“, zuletzt am 12. Oktober 2010 um 10:11 Uhrgeändert;

ES-[X.] Wikipedia-Artikel „Server“, zuletzt am 21. November 2010 um 23:13 Uhr geändert;

ES-[X.] Wikipedia-Artikel „Server (Software)“, zuletzt am 26. Februar 2010 um 19:14 Uhr geändert;

ES-[X.] Wikipedia-Artikel „Client-Server-Modell“, zuletzt am 16. Oktober 2010 um 10:00 Uhr geändert;

ES-NK5 Internet-Beitrag „[X.]“, MPEG2[X.] Stream - Transport Stream, 17. [X.]ezember 2014;

ES-NK6 Webseite Cambridge [X.]ictionary zum Begriff „retrieval“;

ES-[X.] [X.] – [X.], [X.]: „[X.]“, September 2006;

ES-[X.] [X.] ([X.]. des Senats: Autor unbekannt) „Turn your iPhone into a Web server“, 9. Februar 2009.

Hilfsantrag I vom 15. Februar 2022 lautet:

Hilfsantrag I (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that contain the streams available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

[X.] an [X.] encoded [X.];

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved at least a portion of the top level index file;

using the top level index file to request the portions of the container file that include the [X.] the [X.] encoded [X.] file, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream.

2. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

3. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

4. The playback device (20) of claim 3, wherein the playback device supports different rates of accelerated visual search.

5. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

6. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

7. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

8. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

9. The playback device (20) of claim 8, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

10. The playback device (20) of claim 8, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container file containing a stream.

11. The playback device (20) of claim 1, wherein the container files are Matroska container files, wherein preferably each Matroska container file contains a single stream.

12. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Hilfsantrag II vom 27. März 2023 lautet:

Hilfsantrag II (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that contain the streams available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

each container file includes (i) [X.] ([X.]) an [X.] encoded [X.] file, and the top level index file indicates the portions of each container file containing this information;

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved top level index file;

using the top level index file to request the portions of the container file that include (i) the [X.] ([X.]) the [X.] encoded [X.] file;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream.

2. The playback device (20) of claim 1, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video.

3. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

4. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

5. The playback device (20) of claim 4, wherein the playback device supports different rates of accelerated visual search.

6. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

7. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

8. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

9. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

10. The playback device (20) of claim 9, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

11. The playback device (20) of claim 9, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container file containing a stream.

12. The playback device (20) of claim 1, wherein the container files are Matroska container files, wherein preferably each Matroska container file contains a single stream.

13. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Hilfsantrag III vom 27. März 2023 lautet:

Hilfsantrag III (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that contain the streams available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

each container file includes (i) [X.] ([X.]) an [X.] encoded [X.] file, and the top level index file indicates the portions of each container file containing this information;

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved top level index file;

using the top level index file to request the portions of the container file that include (i) the [X.] ([X.]) the [X.] encoded [X.] file, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream.

2. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

3. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

4. The playback device (20) of claim 3, wherein the playback device supports different rates of accelerated visual search.

5. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

6. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

7. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

8. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

9. The playback device (20) of claim 8, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

10. The playback device (20) of claim 8, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container file containing a stream.

11. The playback device (20) of claim 1, wherein the container files are Matroska container files, wherein preferably each Matroska container file contains a single stream.

12. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Hilfsantrag IV vom 27. März 2023 lautet:

Hilfsantrag IV (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that each contain a stream available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored as a single stream in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

each container file includes (i) [X.] ([X.]) an [X.] encoded [X.] file, and the top level index file indicates the portions of each container file containing this information;

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved top level index file;

using the top level index file to request the portions of the container file that include (i) the [X.] ([X.]) the [X.] encoded [X.] file;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream.

2. The playback device (20) of claim 1, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video.

3. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

4. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

5. The playback device (20) of claim 4, wherein the playback device supports different rates of accelerated visual search.

6. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

7. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

8. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

9. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

10. The playback device (20) of claim 9, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

11. The playback device (20) of claim 9, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container file containing a stream.

12. The playback device (20) of claim 1, wherein the container files are Matroska container files.

13. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Hilfsantrag V vom 27. März 2023 lautet:

Hilfsantrag V (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that each contain a stream available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored as a single stream in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

each container file includes (i) [X.] ([X.]) an [X.] encoded [X.] file, and the top level index file indicates the portions of each container file containing this information;

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved top level index file;

using the top level index file to request the portions of the container file that include (i) the [X.] ([X.]) the [X.] encoded [X.] file, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream.

2. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

3. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

4. The playback device (20) of claim 3, wherein the playback device supports different rates of accelerated visual search.

5. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

6. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

7. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

8. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

9. The playback device (20) of claim 8, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

10. The playback device (20) of claim 8, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container file containing a stream.

11. The playback device (20) of claim 1, wherein the container files are Matroska container files.

12. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Hilfsantrag VI vom 2. Mai 2023 lautet:

Hilfsantrag VI (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files from a remote server via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that each contain a stream available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored as a single stream in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

each container file includes (i) [X.] ([X.]) an [X.] encoded [X.] file, and the top level index file indicates the portions of each container file containing this information;

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved top level index file;

using the top level index file to request the portions of the container file that include (i) the [X.] ([X.]) the [X.] encoded [X.] file;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream.

2. The playback device (20) of claim 1, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video.

3. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

4. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

5. The playback device (20) of claim 4, wherein the playback device supports different rates of accelerated visual search.

6. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

7. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

8. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

9. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

10. The playback device (20) of claim 9, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

11. The playback device (20) of claim 9, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container  file containing a stream.

12. The playback device (20) of claim 1, wherein the container files are Matroska container files.

13. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Hilfsantrag VII vom 2. Mai 2023 lautet:

Hilfsantrag VII (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files from a remote server via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that each contain a stream available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored as a single stream in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

each container file includes (i) [X.] ([X.]) an [X.] encoded [X.] file, and the top level index file indicates the portions of each container file containing this information;

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved top level index file;

using the top level index file to request the portions of the container file that include (i) the [X.] ([X.]) the [X.] encoded [X.] file, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream.

2. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

3. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

4. The playback device (20) of claim 3, wherein the playback device supports different rates of accelerated visual search.

5. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

6. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

7. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

8. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

9. The playback device (20) of claim 8, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

10. The playback device (20) of claim 8, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container file containing a stream.

11. The playback device (20) of claim 1, wherein the container files are Matroska container files.

12. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Hilfsantrag [X.] vom 2. Mai 2023 lautet:

Hilfsantrag [X.] (Reinschrift)

1. A playback device (20) configured to perform adaptive bitrate streaming, the playback device comprising a processor configured, via a client application, to request a top level index file and container files from a remote server via a network;

wherein the client application further configures the processor to:

commence [X.] that identifies a plurality of container files that each contain a stream available to the playback device for use in adaptive bitrate streaming, where

the available streams include a plurality of alternative video streams,

[X.] (32) is the same source video content encoded at a different bitrate and is stored as a single stream in a separate container file as a plurality of portions of video,

each portion of video is encoded as at least one closed group of pictures starting with an [X.] ([X.]) frame, and

each container file includes (i) [X.] ([X.]) an [X.] encoded [X.] file, and the top level index file indicates the portions of each container file containing this information;

select one or more streams including one of the plurality of alternative video streams to utilize in the playback of media based upon the retrieved top level index file;

using the top level index file to request the portions of the container file that include (i) the [X.] ([X.]) the [X.] encoded [X.] file, wherein the retrieved portion of the container file of the selected alternative video stream that contains the [X.] encoded [X.] file includes sufficient index information to stream the entirety of the selected alternative stream of video;

configure a video decoder to playback the encoded [X.];

retrieve encoded [X.] encoded [X.] file;

playback the retrieved portions of video from the selected alternative video stream using the decoder; and

when a change in streaming conditions is detected, select a new alternative video stream that is more appropriate for the streaming conditions than the previously selected alternative video stream,

wherein the client application configures the playback device to request portions of the top level index file and the container files from remote servers via [X.] ([X.]) [X.] range requests.

2. The playback device (20) of claim 1, wherein the client application further configures the processor to request all of the index information for the lowest bitrate stream from the plurality of alternative video streams prior to the commencement of playback.

3. The playback device (20) of claim 1, wherein at least one of the streams available for playback is a trick play track stream in which the same source video content is encoded at a lower frame rate than the frame rates of the plurality of alternative video streams and the playback device performs a trick play function using the trick play track stream.

4. The playback device (20) of claim 3, wherein the playback device supports different rates of accelerated visual search.

5. The playback device (20) of claim 1, wherein the encoding parameters utilized to decode the encoded [X.], frame height, frame width, sample aspect ratio, maximum bitrate, and minimum buffer size.

6. The playback device (20) of claim 1, wherein the playback device requests a top level index file and container files via the network using a stateless protocol.

7. The playback device (20) of claim 1, wherein the plurality of alternative video streams are encoded with different resolutions and/or different frame rates.

8. The playback device (20) of claim 1, wherein the top level index file is a SMIL file.

9. The playback device (20) of claim 8, wherein the SMIL file comprises a list of URIs describing each of the streams and the container files that contain the streams.

10. The playback device (20) of claim 8, wherein the SMIL file comprises a "header-request" [X.] element that specifies the size of a header section of the container file containing a stream.

11. The playback device (20) of claim 1, wherein the container files are Matroska container files.

12. The playback device (20) of claim 1, wherein at least two of the alternative streams of encoded video are encoded at the same display aspect ratio, but with different resolutions using different sample aspect ratios.

Wegen der weiteren Einzelheiten wird auf den Akteninhalt verwiesen.

Die Klage, mit der der [X.] der fehlenden Patentfähigkeit nach Art. [X.] § 6 Abs. 1 Satz 1 Nr. 1 [X.]. 138 Abs. 1 lit. a) EPÜ, Art. 52, 54und 56 EPÜ sowie der [X.] der unzulässigen Erweiterung nach Art. [X.] § 6 Abs. 1 Satz 1 Nr. 3 [X.] i.V.m. Art. 138 Abs. 1 lit. c) EPÜ und Art. 123 Abs. 2 EPÜ geltend gemacht werden, ist zulässig.

Die Klage ist auch begründet. Denn das Streitpatent hat weder in seiner erteilten Fassung noch in der Fassung der [X.] bis [X.] Bestand, weil ihm der [X.] der mangelnden Patentfähigkeit entgegensteht.

1. Das Streitpatent betrifft das Streaming von kodierten Medien (encoded media) mit Adaption der Bitrate ([X.] Abs. [0001]). Der Begriff Streaming beschreibe die Wiedergabe von Medien durch ein Wiedergabegerät, wobei die Medien auf einem Server gespeichert seien und kontinuierlich über ein Netzwerk zu dem Wiedergabegerät gesandt würden ([X.] Abs. [0002]). Adaptives [X.] beinhalte zudem, die vorliegenden Bedingungen (z. B. Bandbreite) in Echtzeit (real time) zu detektieren und die Qualität der übertragenen Medien entsprechend anzupassen. Dazu seien die Medien üblicherweise mit mehreren Bitraten kodiert, zwischen denen das Wiedergabegerät umschalte ([X.] Abs. [0002]).

Auf einem Medienserver (media server) sei üblicherweise eine [X.] (top level index file) gespeichert, die auf mehrere alternative Datenströme (streams) hindeute ([X.]), welche die eigentlichen Video- und Audio-Daten enthielten. Jeder Datenstrom sei für gewöhnlich in einer oder mehreren [X.] (container files) abgelegt ([X.] Abs. [0004]). Unterschiedliche Lösungen für adaptives [X.] bedienten sich verschiedener [X.]en und [X.] ([X.] Abs. [0004], [0005]).

Aus dem Stand der Technik sei für die Wiedergabe einer Videodatei bekannt, bei sich ändernden [X.] von einer Version mit hoher Bitrate auf eine Version mit niedriger Bitrate umzuschalten ([X.] Abs. [0006]). Ferner sei bekannt, für das Herunterladen dynamisch aus Mediendateien mit unterschiedlicher Qualität auszuwählen, sowie eine auf [X.] beruhende adaptive Streaming-Technologie ([X.] Abs. [0007] bzw. [0008]).

2. Eine Aufgabe wird im Streitpatent nicht ausdrücklich genannt. Jedoch ist vor dem Hintergrund der oben genannten Absätze der [X.] die Aufgabe darin zu sehen, ein Wiedergabegerät anzugeben, das ein Streaming mitverbessertem adaptiven Verhalten verwirklicht.

Diese Aufgabe wird erfindungsgemäß durch ein Wiedergabegerät („playback device“ in der maßgeblichen [X.] Fassung) mit den Merkmalen des Patentanspruchs 1 nach Hauptantrag gelöst, der sich entsprechend dem Vorschlag der Klägerin gemäß Anlage [X.] vorstehend angegeben, gliedert.

3. Als Fachmann, der mit der Lösung dieser Aufgabe betraut wird, ist ein Ingenieur der Fachrichtung Informationstechnik anzusehen, der mehrjährige Berufserfahrung und Fachkenntnisse auf dem Gebiet des Streamings besitzt und mit den einschlägigen Standarddokumenten vertraut ist.

4. Dieser Fachmann legt den Merkmalen des von der Nichtigkeitsklage angegriffenen Patentanspruchs 1 folgendes Verständnis zugrunde:

4.1 Ein anspruchsgemäßes Wiedergabegerät zum [X.] weist als Vorrichtungsmerkmal einen [X.] auf. Dieser ist durch eine Klient-Anwendung dazu eingerichtet, eine [X.] und [X.] über ein Netzwerk anzufordern (Merkmal a; vgl. [X.] Absatz [0022], [X.]. 1).

Die übrigen Merkmale des Patentanspruchs 1 bestimmen die Funktionsweise des Wiedergabegeräts, indem die Klient-Anwendung den [X.] ferner dazu einrichtet (Merkmal c), das [X.] nach den Verfahrensschritten gemäß den Merkmalen c1 bis c7 durchzuführen. Dabei beziehen sich die Verfahrensschritte auf die durch die Merkmalsgruppe b, [X.], [X.]und [X.] festgelegte Datenstruktur, gemäß der die [X.] sowie zugehörige Daten für deren Handhabung, die dem Fachmann als Metadaten geläufig sind, abgelegt und aufgefunden werden sollen. Im [X.] werden Medien- und Metadaten wie nachfolgend erläutert in mehreren Begriffen angesprochen.

4.2 Die [X.] (identifies) eine Vielzahl von [X.] (Merkmal b). Nach der Beschreibung kann die [X.] deren Inhalt beschreiben und Verweise auf die [X.] beinhalten (vgl. Absatz [0023] bzw. [0025]). Demgegenüber lässt das Merkmal b offen, in welcher Weise die [X.] „bezeichnet“ werden sollen.

Die für das [X.] in den [X.] enthaltenen Streams umfassen für den Fachmann die wahlweise wiederzugebenden [X.] (vgl. [X.] [X.]. 2).

4.3 Die Merkmale [X.], [X.] und [X.] bestimmen lediglich ein Video-Streaming näher, während andere Arten von Streams (Audio, Untertitel; Absatz [0015]) im Anspruch nicht genannt sind.

Indem die verfügbaren Streams eine Vielzahl alternativer [X.] mit gleichem Quell-[X.] jedoch unterschiedlicher Bitrate beinhalten sollen (Merkmal [X.]), ist aus fachmännischer Sicht ein adaptives Streaming möglich. Dabei soll gemäß Merkmal [X.] jeder der alternativen [X.] in einer eigenen [X.] gespeichert sein, wobei der Fachmann unter der weiterhin genannten Vielzahl von Stücken von Videomaterial die bei [X.] üblichen Einzelbilder, Frames oder dergleichen versteht.

4.4 In der Anweisung des Merkmals [X.], jedes Stück Videomaterial als zumindest eine geschlossene Gruppe von Bildern beginnend mit einem [X.] (Instantaneous Decoding Refresh) zu kodieren, erschließt der Fachmann die Bedeutung des in der [X.] nicht erläuterten Begriffs [X.] durch sein Fachwissen. Ein [X.] gestattet es beispielsweise [X.]/MPEG-4-kodierten [X.], nachfolgende Bilder zu dekodieren, ohne dabei auf Bilder zurückzugreifen, die vor dem [X.] empfangen wurden. Im Einklang damit entnimmt der Fachmann Absatz [0016] der Beschreibung der [X.], dass eine in einer [X.] gespeicherte geschlossene Gruppe von Bildern wiedergegeben werden kann, ohne dabei auf Videoinhalte in einem anderen Bereich derselben [X.]Bezug zu nehmen.

4.5 Das Merkmal [X.] legt nach seinem ersten Teil weitere Inhalte der [X.] fest und bestimmt nach seinem zweiten Teil die [X.] näher.

4.5.1 Hierbei kann die Anweisung des ersten Teils des Merkmals [X.] auf zwei unterschiedliche Weisen gelesen werden. Denn aus dem Wortlaut der [X.] Fassung „each container file includes information concerning the encoding of the video contained within the container file and an index to the encoded [X.]“ geht nicht eindeutig hervor, ob sich die Angabe „information concerning“ ausschließlich auf das nachfolgende Wort „encoding“ oder zusätzlich auch auf den im weiteren Verlauf genannten „index“ beziehen soll. Bei der [X.] Übersetzung verhält es sich genauso: „Informationen betreffend die Kodierung … und einen Index zu …“.

Deshalb lässt sich der erste Teil des Merkmals [X.] dem breitesten Wortsinn nach dahin verstehen, dass jede [X.] Informationen betreffend die Kodierung des in der [X.] enthaltenen Videomaterials und Informationenbetreffend einen Index zu den kodierten Medien in der [X.] beinhalten soll. Bei diesem Verständnis erfasst das Merkmal [X.] zwar gleichermaßen den Fall, dass eine [X.] den vollständigen Index enthält; das Merkmal ist jedoch bereits dann erfüllt, wenn in der [X.] lediglich auf den Index bezogene Informationen gespeichert sind, wie beispielsweise ein Header der [X.], welcher auf den Index verweist. Ein Ausführungsbeispiel mit einem solchen Header entnimmt der Fachmann der [X.]ur 8 i. V. m. Absatz [0065] der [X.]. Nach demselben Ausführungsbeispiel gibt (Merkmal [X.]: „indicates”) die [X.] mittels einer URI den [X.] der [X.] an, welcher den Ort des Indexes innerhalb der [X.] als eine den Index betreffende Information enthält. Damit erfüllt die [X.] die im zweiten Teil des Merkmals [X.] festgelegte Funktion.

Demzufolge lässt der Wortlaut des Merkmals [X.] ein allgemeines Verständnis des [X.]s zu, welches das Ausführungsbeispiel gemäß [X.]ur 8 mit umfasst und daher hier für sachgerecht gehalten wird (vgl. [X.], Urteil vom 2. Juni 2015, [X.], [X.], 972 – Kreuzgestänge, Leitsatz 2: „Werden in der Beschreibung eines Patents mehrere Ausführungsbeispiele als erfindungsgemäß vorgestellt, sind die im Patentanspruch verwendeten Begriffe im Zweifel so zu verstehen, dass sämtliche Beispiele zu ihrer Ausfüllung herangezogen werden können“).

Doch selbst wenn man dem Einwand der Beklagten folgen wollte, dass der Index zu den kodierten Medien nach Maßgabe des Merkmals [X.] in der jeweiligen [X.] enthalten und unmittelbar aus derselben abrufbar sein müsse, d. h. ohne den Umweg über eine vorherige Anfrage eines Headers der [X.] zu erfordern, käme es darauf im Ergebnis nicht an. Denn für den Vergleich mit dem Stand der Technik ist die Ausführungsform mit einem Header innerhalb der [X.] nicht entscheidungserheblich, wie nachstehend ausgeführt.

4.5.2 Weiterhin lässt der Wortlaut des Merkmals [X.] offen, ob die Informationen zu Kodierung und Index in einem zusammenhängenden Bereich oder in mehreren voneinander getrennten Bereichen der [X.] gespeichert sind. Indem das Merkmal [X.] auf das „in der [X.] enthaltene Videomaterial“ sowie einen „Index zu den kodierten Medien“ Bezug nimmt, ist ferner nicht festgelegt, in welcher konkreten Datenstruktur das Videomaterial bzw. die Medien in der [X.] gespeichert sind. Des Weiteren besagt ein „Index zu den kodierten Medien“ nach Maßgabe des Merkmals [X.] lediglich, dass ein solcher Index es ermöglicht, die kodierten Medien aufzufinden. Dagegen bleibt die Gliederung der [X.] ebenso offen wie die Art und Weise, in der diese Daten in der [X.] gespeichert sind.

Die Beklagte vertritt die Auffassung, der Index gemäß dem Merkmal [X.] nehme aufgrund der Datenstruktur in der [X.] gemäß [X.]ur 6 der [X.] einen zusammenhängenden Bereich in der [X.] ein und könne auf diese Weise mithilfe der entsprechenden Bereichsinformation in der [X.] in seiner Gesamtheit vom Wiedergabegerät abgerufen werden.

Diese Auslegung vermag nicht zu überzeugen. Denn sie stützt sich auf ein einzelnes anhand von [X.]ur 6 erläutertes Ausführungsbeispiel, gemäß dem innerhalb von Matroska-[X.] Stücke von Videomaterial in [X.] und ein Index in [X.]-Elementen gespeichert sind. Matroska-[X.] sind in Absatz [0023]der Beschreibung der [X.] jedoch ausdrücklich als eine von vielen möglichen Formen von [X.] genannt. Auf diesen Umstand weist die Beklagte im Zusammenhang mit Fragen der Zulässigkeit von Änderungen selbst hin. Aus den im Merkmal [X.] lediglich in allgemeiner Form angegebenen Begriffen „Videomaterial“ und „kodierte Medien“ ist nicht ersichtlich, dass die zugehörigen Daten irgendwelchen Formatvorgaben, insbesondere für Matroska-[X.], genügen müssen. Auch durch die Bezugnahme auf „Stücke von Videomaterial“ in den Merkmalen [X.] und [X.] lässt sich eine Einschränkung auf bestimmte Datenformate nicht begründen.

4.5.3 In seinem zweiten Teil bestimmt das Merkmal [X.], dass die [X.] die Bereiche (portions) jeder [X.] „angibt“ (indicates), die Informationen zu Kodierung und Index enthalten. In [X.]ur 2 der [X.] ist durch Pfeile ohne technische Details dargestellt, wie die [X.] auf [X.] „hindeutet“ (indicates). [X.] Angaben hierzu gibt die Beschreibung im Absatz [0067] der [X.]. Dieser vermittelt dem Fachmann, dass in der [X.] enthaltene URIs (Uniform Resource Identifiers) geeignet strukturiert sein können, um byte-weise definierte Bereiche anzufordern, die zumindest Teile des Indexes einer [X.] enthalten. Wie die URIs im Einzelnen zu strukturieren sind und auf welche Weise die byte-weisen Anfragen zu formulieren sind, lässt das Streitpatent offen.

Das Merkmal [X.] ist indessen in seinem zweiten Teil nicht auf eine solche Ausführung beschränkt. Vielmehr versteht der Fachmann unter der Anweisung „the top level index file indicates the portions of each container file containing this information“ die allgemeine Lehre, dass die [X.] in einer Weise auf die [X.] hindeuten soll (indicates), die es ermöglicht, Bereiche der [X.] mit Informationen zu Kodierung und Index anzufordern. Durch welche Mittel das Hindeuten anspruchsgemäß zu erfolgen hat, geht aus Merkmal [X.] nicht hervor.

Die Beklagte vertritt den Standpunkt, dass die [X.]den Ort der [X.] in der [X.]hinreichend genau und direkt angeben müsse, also insbesondere ohne den Umweg über einen Header wie in [X.]ur 8 der [X.]. Sie weist hierzu unter anderem auf die Datenstrukturen [X.] und [X.] sowie [X.] und Tracks hin. Zudem müsse die „Verzeigerung“ von der [X.] hin zur [X.] eine genaue Zuordnung geben, weshalb das Merkmal [X.] technisch eng zu verstehen sei. Auch sei die Leistung der Erfindung darin zu sehen, dass vor allem das Merkmal [X.] lehre, in der [X.] nur einen(einzelnen) Verweis auf den Index in der [X.] vorzusehen.

Einer solch verengenden Auslegung des Merkmals [X.] kann nicht gefolgt werden. Denn die vorgenannten Datenstrukturen sind nicht Bestandteile einer [X.], sondern innerhalb einer [X.] angeordnet (vgl. Abs. [0045], [0055] bzw. [0065] und [0066] der Beschreibung der [X.]). Hierbei dienen [X.], [X.] und [X.] einem Indexieren innerhalb einer [X.], nicht aber einem Hindeuten von einer [X.] zu einer [X.]. Deshalb lassen die genannten Datenstrukturen weder einen Rückschluss darauf zu, wie präzise die [X.] den Ort der [X.] in der [X.] anzugeben hat, noch darauf, dass dies direkt erfolgen muss. Im Übrigen handelt es sich bei den Datenstrukturen [X.] und Tracks um Header-Elemente einer [X.] des im Streitpatent anhand von [X.]ur 8 erläuterten Ausführungsbeispiels, welches die Beklagte ohnehin nicht unter den Wortlaut des Merkmals [X.] subsumiert wissen will.

Um ihr technisch enges Verständnis des Merkmals [X.] zu untermauern, vermag die Beklagte folglich auf keine Stelle in der [X.] hinzuweisen, die eine derartige Auslegung stützen könnte. Eine solche Stelle ist auch nach Überzeugung des Senats nicht auffindbar. Es ist insbesondere kein Umstand ersichtlich, weshalb der allgemein gehaltene Wortlaut des Merkmals [X.] lediglich einen einzelnen Verweis aus der [X.] in eine jeweilige [X.] erfassen soll.

4.6 Das [X.] soll nach den Verfahrensschritten gemäß den Merkmalen c1 bis c7 des Patentanspruchs 1 erfolgen.

Die Wiedergabe beginnt mit einem Abrufen der [X.] (Merkmal c1). Dies kann gemäß [X.]ur 8 der [X.] durch Austausch zweier Nachrichten „Top Level Index Request“ bzw. „… Response“ geschehen.

Aufgrund zumindest des Teils der [X.], der/die abgerufen wurde, ist ein Stream oder sind mehrere Streams zur Nutzung bei der Wiedergabe auszuwählen, worin einer der Vielzahl alternativer [X.] enthalten ist (Merkmal [X.]). Dabei bleibt offen, ob neben einem Video-Stream in einer [X.] auch Streams für beispielsweise Audio und Untertitel enthalten sind (vgl. [X.] [X.]ur 4d).

Die [X.] wird zum Anfordern derjenigen Bereiche der [X.]verwendet, die die Informationen betreffend die Kodierung des in der [X.] enthaltenen Videomaterials und den Index zu den kodierten Medien in der [X.] enthalten (Merkmal c3). Der Wortlaut des Merkmals c3 ist analog zum Merkmal [X.] gehalten und folglich in dem zuvor beschriebenen Sinne auszulegen (vgl. Abschnitt [X.]4.5). Zum Anfordern der Informationen betreffend Kodierung und Index zeigt die [X.] in [X.]ur 8 i. V. m. Absatz [0065] und [0066] die Nachrichten [X.] sowie [X.] Request.

Mithilfe der abgerufenen Informationen betreffend die Kodierung des Videomaterials wird ein Videodekodierer zur Wiedergabe des kodierten Videomaterials konfiguriert, also beispielsweise eine Bildfrequenz und Auflösung eingestellt (vgl. [X.] Absatz [0066] – Merkmal c4).

Die angeforderten [X.]en zu den kodierten Medien in der [X.] dienen dazu, kodierte Medien von der [X.] des ausgewählten alternativen [X.] abzurufen (Merkmal [X.]). Dabei bedeutet die Anweisung „mithilfe der angeforderten [X.]en zu den kodierten Medien“ („retrieve …using the requested index information to the encoded media“) im Einklang mit der oben getroffenen Auslegung des Merkmals [X.], dass der Index entweder indirekt (vgl. [X.] [X.]ur 8: Nachrichtenfolge [X.] und [X.] Request) oder aber direkt zum Wiedergabegerät gelangt ist. Das [X.] zeigt [X.]ur 8 als wiederholende Schleife mit den Nachrichten MKV Cluster Element(s) Request/Download.

Die abgerufenen Stücke Videomaterial aus dem ausgewählten alternativen Video-Stream werden mittels des [X.] wiedergegeben (Merkmalc6).

Wird eine Änderung in den [X.] detektiert, soll ein neuer alternativer Video-Stream ausgewählt werden, der für die [X.] besser geeignet ist als der vorher ausgewählte alternative Video-Stream (Merkmal c7). Auf diese Weise kann reagiert werden, wenn sich die verfügbare Bandbreite erhöht oder verringert (vgl. [X.] Absatz [0070]).

Das Streitpatent ist in der Fassung nach Hauptantrag nicht rechtsbeständig, weil der Gegenstand des Patentanspruchs 1 nicht patentfähig ist. Die von der Klägerin ebenfalls geltend gemachte fehlende Zulässigkeit der erteilten Fassung braucht deshalb nicht beurteilt zu werden.

1. Der Gegenstand des Patentanspruchs 1 nach Hauptantrag ist nicht neu gegenüber der Lehre der Druckschrift [X.]unter Einschluss der dort in Bezug genommenen Druckschrift [X.].

1.1  Aus der Druckschrift [X.] ist ein Wiedergabegerät zum Ausführen von Bitraten-adaptivem Streaming zu entnehmen (vgl. S. 87 Abschnitt 12.1 [X.]ur 12.1: „[X.] Streaming Client“). Hierzu lädt das Wiedergabegerät zunächst die relevanten Metadaten und anschließend die eigentlichen [X.] der Streams über ein Netzwerk herunter (vgl. den letzten Absatz von Abschnitt 12.1). Dabei werden die Mediendaten der Streams in [X.] aufbewahrt (3GPP File Format, vgl. S. 98 Abschnitt 12.4.1 i. V. m. dem dort als Referenz [50] zitierten Dokument, welches als [X.] vorliegt). Ferner können Metadaten in Form von Segment [X.]en in den [X.] gespeichert sein (vgl. Abschnitt 12.4.3 erster Absatz).

Dass das in der [X.] gezeigte Wiedergabegerät in Gestalt eines „[X.] Streaming Clients“ einen [X.] mit zugehöriger Klient-Anwendung umfasst, ist für den Fachmann selbstverständlich. Das Wiedergabegerät kann gemäß Abschnitt 12.1 Absatz 3 eine „Media Presentation Description ([X.])“ genannte Datei über ein Netzwerk (S. 17 [X.]ur 1: „Packet based network interface“) anfordern, die einer [X.] gleichkommt. Nach dem letzten Absatz des Abschnitts 12.1 sind die Mediendaten in [X.] im 3GP-Dateiformat abgelegt und folglich auch diese Dateien anzufordern. Somit ist Merkmal a gezeigt.

Eine Wiedergabe beginnt nach der Lehre von [X.] gemäß Abschnitt 12.1 Absatz 4 („To initiate the streaming service to the user”) durch Abrufen von Metadaten („downloading the relevant metadata”), die nach dem vorangegangenen Absatz von [X.] unter anderem der [X.] [X.] entstammen – Merkmale c und c1.

1.2 In der Datenstruktur der [X.] [X.] sowie der 3GP-[X.] gemäß [X.] sind die Merkmale b, [X.], [X.] und [X.] vorweggenommen:

a) Die [X.] [X.] enthält eine Vielzahl von URLs zu sogenannten „[X.]“, welche Streams repräsentieren (Abschnitt 12.2.5.1 Absatz 1 und 2). Die URLs bezeichnen („identifies“ im Merkmal b) 3GP-[X.] (vgl. Abschnitt [X.], Angabe „source URL=”clip2x.3gp”am Ende des ersten [X.]-Beispiels), welche die für das [X.] verfügbaren Streams enthalten – Merkmal b.

b) Verfügbare Streams ([X.]) sind als eine Abfolge von „[X.]“ gegliedert, von denen jede eine oder mehrere „[X.]“ mit demselben Quell-Inhalt enthält (Abschnitt 12.2.1 S. 88). Dabei enthalten die Representationen beispielsweise denselben [X.] (Abschnitt 7.4 Video) kodiert mit einer unterschiedlichen Bitrate (Abschnitt 12.2.3 Representation Abs. 2).

Die [X.] können ihrerseits aus einem oder mehreren „Segments“ bestehen (Abschnitt 12.2.1 S. 88), die „[X.]“ (Abschnitt 12.4.2.3 Media Segment Format S. 100) enthalten. Solche Segmente umfassen demnach eine Vielzahl von Stücken von Videomaterial.

Das Dateiformat der 3GP-[X.] bestimmt [X.] ausdrücklich (Abschnitt 12.4.3 erster Satz) anhand der Spezifikation [X.] 26.244, die als [X.] im Verfahren ist. Nachdem [X.] durch die Bezugnahme den Inhalt von [X.] aufnimmt, sind auch die Bestimmungen von [X.] beim [X.] zu berücksichtigen (vgl. [X.], Beschluss vom 17. Januar 1980, [X.], [X.], 283 – [X.], Leitsatz 1). [X.] definiert im Abschnitt 5.4.3 (siehe beim ersten Spiegelstrich: „a file shall be self-contained“), dass [X.] nach dem „Basic profile“ in einer eigenen 3GP-[X.] gespeichert sind.

Im Ergebnis sind folglich alle Teile des Merkmals [X.] gezeigt.

c) Jedes Stück Videomaterial eines Segments kann mit einem sogenannten „random access point ([X.])“ beginnen ([X.]: vgl. Abschnitt 12.2.4.1 dritter Unterpunkt; Abschnitt 12.6.4 vorletzter Absatz; [X.]: Seite 49 vorletzter Absatz). Dem Fachmann ist bekannt, dass beim [X.] die [X.] (Instantaneous Decoding Refresh) einen [X.] definieren (siehe zum diesbezüglichen Fachwissen beispielsweise NK14 S. 9 Abschnitt 6.2). Im Fall eines solchen H.264-Video-Codecs ist daher jedes Stück Videomaterial als eine Gruppe von Bildern beginnend mit einem [X.] kodiert. Aus der technischen Funktion eines [X.]s als Beginn einer Gruppe von Bildern, die ohne Kenntnis vorheriger Bilder dekodiert werden kann, ergibt sich zudem, dass diese eine geschlossene Gruppe von Bildern bildet – Merkmal [X.].

d) Die Anweisungen des Merkmals [X.] nach seinem ersten und zweiten Teil sind gleichfalls in [X.] vorbeschrieben.

[X.]) Die im Rahmen des 3GPP Adaptive [X.]-Streaming genutzten 3GP-[X.] entsprechen dem 3GP „Adaptive Streaming Profile“ nach [X.] ([X.] Abschnitt 12.4.3). Daher enthalten die 3GP-[X.] eine [X.] als Datenelement ([X.] Abschnitt 5.4.9 S. 14 erster Unterpunkt). In der [X.] sind Informationen zum Identifizieren der Eigenschaften der Mediendaten beinhaltet ([X.] Abschnitt 12.4.2.2 S. 99 Abs. 4), d. h. Informationen betreffend die Kodierung des enthaltenen Videomaterials.

Außerdem beinhaltet eine 3GP-[X.] als optionales Datenelement eines Media Segments oder eines [X.] eine Segment [X.] (kurz: „sidx“; [X.] Abschnitt 12.4.2.3 S. 100 fünfter Unterpunkt bzw. Abschnitt 12.4.2.4 sechster Unterpunkt). Eine solche [X.] bietet einen kompakten Index zu Medienfragmenten und anderen [X.]en eines Segments ([X.] Abschnitt 13.4) und ist infolgedessen als Index zu den kodierten Medien in der [X.] anzusehen.

Demnach ist in der Lehre der Druckschrift [X.] das Merkmal [X.] nach seinem ersten Teil erfüllt.

bb) Die[X.] [X.] gibt für jedes Segment eines [X.] durch einen URL den Bereich der [X.] an, der das betreffende Segment enthält ([X.] Tabelle 12.2 S. 94). Hierbei definiert ein jeweiliger Parameter „range“ den Anfang und das Ende des Speicherbereichs, den das Segment in der [X.] einnimmt (vgl. Abschnitt [X.] am Ende des [X.]-Beispiels die Angabe „range=“500-2000”“ zu einem Segment innerhalb einer durch „source URL=”clip2x.3gp”“ angegebenen [X.]).

Der Anfangsbereich eines jeden Segments bildet jeweils einen Bereich der[X.] mit Informationen zu Kodierung und Index. So steht am Anfang der [X.] eine [X.] ([X.] Abschnitt 5.4.9 S. 14 erster Unterpunkt) als Teil eines Initialisation Segments mit Informationen zur Kodierung (vgl. [X.] Abschnitt 12.4.2.2 Abs. 2) und ebenso eines [X.] (vgl. [X.] Abschnitt 12.4.2.4 erster Unterpunkt zu „[X.] profile“ i. V. m. [X.] Abschnitt 5.4.9 erster Unterpunkt). Weiterhin befindet sich eine [X.] mit [X.]en sowohl in einem Media Segment als auch in einem [X.] Segment jeweils im Anfangsbereich des Segments (siehe [X.] Abschnitt 12.4.2.3 S. 100 fünfter Unterpunkt bzw. Abschnitt 12.4.2.4 sechster Unterpunkt).

Aufgrund dieses Aufbaus der Segmente sind in einer [X.] mit einer Representation eines [X.] ohne vorherige Initialisierung zwangsläufig Informationen zu Kodierung und Index im Anfangsbereich der [X.] abgelegt. Denn die [X.] beginnt entweder mit einem kurzen Initialisation Segment ohne jegliche Mediendaten, welches am Anfang die [X.] enthält, an das sich mindestens ein Media Segment anschließt, das am Anfang die [X.] beinhaltet; oder die [X.] beginnt mit einem [X.] Segment, in dessen Anfangsbereich sowohl [X.] als auch [X.] abgelegt sind (vgl. [X.] Abschnitt 12.4.2.1 letzte zwei Unterpunkte).

Indem die [X.] [X.] durch URLs die vordefiniert strukturierten Segmentbereiche innerhalb der[X.] angibt, deutet (indicates) die [X.] zugleich auf diejenigen Segmentbereiche am Anfang der[X.] hin, welche Informationen zu Kodierung und Index beinhalten, wodurch es ermöglicht wird, ebendiese Informationen anzufordern. So lehrt die [X.] beispielsweise, dass die Klient-Anwendung basierend auf der [X.] Zugang zu einer Media Segment URL eines jeden Segments erhalten und eine [X.] gezielt byteweise abrufen kann (Abschnitt 12.6.4 S. 105 zweiter bzw. letzter Absatz). Infolgedessen vermittelt die [X.] dem Fachmann denselben Lösungsgedanken wie die [X.] im Absatz [0067], gemäß dem es in der [X.] enthaltene URIs gestatten, [X.] mit [X.]en von einem Server anzufordern.

Sonach ist der Druckschrift [X.] auch der zweite Teil des Merkmals [X.], so wie er aus der Auslegung hervorgeht, und gemeinsam mit dem Vorangegangenen schlussendlich das gesamte Merkmal [X.] zu entnehmen.

1.3 [X.] gemäß den weiteren Verfahrensschritten [X.] bis c7 ist in [X.] ebenfalls offenbart:

a) [X.] stehen alternative ([X.] in [X.] unterschiedlicher Bitrate zur Verfügung, von denen sie einen für die Wiedergabe auszuwählen hat (S. 88 Abschnitt 12.2.3 zweiter Absatz). Hierzu enthält die zuvor im Schritt c1 (siehe Abschnitt I[X.]1.1) abgerufene [X.] [X.] für jede Representation ein Element gleichen Namens mit einem Sub-Element „bandwidth“, das Auskunft über die benötigte „minimum bandwidth“ gibt (Tabelle 12.2 S. 93). Aufgrund dieser Informationen der [X.] [X.] wählt die Klient-Anwendung einen der Vielzahl alternativer [X.] aus, zur Nutzung bei der Wiedergabe von Medien – Merkmal [X.].

b) Die [X.] gibt für den Ablauf des Streamings vor (Abschnitt 12.1 letzter Absatz), zunächst die Metadaten herunterzuladen, und erst im [X.] daran die eigentlichen Mediendaten des Streams abzurufen. Der Fachmann versteht unter den in einer 3GP-[X.] gespeicherten Metadaten unter anderem die in der moov- und [X.] enthaltenen Informationen betreffend die Kodierung (moov) bzw. den Index (sidx).

Ausdrücklich zeigt die [X.] in Abschnitt 12.6.4 im letzten Absatz, die [X.] vorab herunterzuladen. An gleicher Stelle gibt die [X.] die Lehre an, hierfür partielle [X.]-Abfragen (partial [X.] requests) einzusetzen, und dass die [X.] der Klient-Anwendung den Zugriff auf jeden Media Segment URL bietet (Abschnitt 12.6.4 zweiter Absatz). Aufgrund des explizit genannten [X.]-Protokolls sieht der Fachmann in den von [X.] genannten partiellen [X.]-Abfragen der [X.] ein konkretes Beispiel für das im Abschnitt 12.3 erläuterte Prinzip, mittels partieller [X.] GET-Abfragen sowohl ganze Media Segmente als auch Teile davon abzurufen (siehe Abschnitt 12.3 letzter Absatz: „to retrieve Initialisation Segments or parts thereof and Media Segments or parts thereof“). Eingeordnet in den Kontext des Abschnitts 12.6.4 vermittelt die [X.] dem Fachmann folglich die Lehre, die[X.] [X.] für den URL-gestützten Zugriff auf das jeweilige Media Segment zu verwenden, und mittels partieller [X.] GET-Abfragen Bereiche der 3GP-[X.] anzufordern, welche die [X.] und mithin den Index enthalten.

Weiterhin lehrt die [X.] entsprechend dem Grundsatz, zuerst die Metadaten abzurufen, vorab das Initialisation Segment herunterzuladen (Abschnitt 12.6.4 erster Absatz letzter Satz). Hierfür wird, wie zu dem Merkmal [X.] ausgeführt, der in der [X.] [X.] abgelegte [X.] verwendet. Das Initialisation Segment beinhaltet die [X.] mit Informationen betreffend die Kodierung. Außerdem sieht die [X.] auch für Initialisation Segments vor (siehe Abschnitt 12.3 letzter Absatz), diese ganz oder teilweise mittels partieller [X.] GET-Abfragen abzurufen. Somit ist der [X.] auch entnehmbar, die [X.] [X.] zu verwenden, um einen Bereich der [X.] anzufordern, der Informationen betreffend die Kodierung – hier die [X.] eines Initialisation Segments (analog: [X.]) – enthält.

Im Ergebnis ist folglich das Merkmal c3 erfüllt.

c) Die Metadaten dienen dem Dekodieren und Wiedergeben der Mediendaten (Abschnitt 12.2.1 S. 88 vierter Unterpunkt) mittels Dekodierern, welche in [X.] auch für [X.] spezifiziert sind (Abschnitt 12.5 i. V. m. Abschnitt 7.4). Dabei ist es für den Fachmann selbstverständlich, dass ein Videodekodierer vor der Wiedergabe des kodierten Videomaterials anhand von Metadaten zu konfigurieren ist, wie sie in der zuvor abgerufenen [X.] enthalten sind – Merkmal c4.

d) Dem in [X.] vorgezeichneten Weg entsprechend (Abschnitt 12.1) werden im [X.] an die Metadaten die Mediendaten des [X.] abgerufen. Die in der [X.] enthaltenen Metadaten sind ein Index zu den Mediendaten im betreffenden Segment (vgl. Erläuterungen zu Merkmal [X.] im Abschnitt I[X.]1.2 d) [X.])). Daher werden mithilfe der angeforderten [X.]en, wie sie durch die [X.] gegeben sind, die kodierten Medien von der [X.] des ausgewählten alternativen [X.] abgerufen – Merkmal [X.].

e) Streaming dient nach Definition von [X.] im Abschnitt [X.] letztendlich einem Wiedergeben von Streams, zu denen beispielsweise [X.] gehören. Dementsprechend werden die zuvor abgerufenen Stücke Videomaterial aus dem ausgewählten alternativen Video-Stream mittels des [X.] (Abschnitt 12.5 i. V. m. Abschnitt 7.4) wiedergegeben – Merkmal c6.

f) Bei der Wiedergabe kann gemäß der [X.] (Abschnitt 12.6.2 S. 102 Unterpunkt 5.) zwischen [X.] gewechselt werden, wobei berücksichtigt wird, wenn sich beispielsweise die verfügbare Bandbreite ändert. Dies schließt mit ein, dass eine Änderung in den [X.] (available bandwidth) detektiert wird. Des Weiteren kommt der Wechsel einer Representation dem Auswählen eines neuen alternativen [X.] gleich, durch den die [X.] berücksichtigt sind, da er besser geeignet ist als der vor der Änderung ausgewählte Video-Stream – Merkmal c7.

2. Der Auffassung der Beklagten, dass der Gegenstand des erteilten Patentanspruchs 1 aus der Druckschrift [X.] nicht hervorgehe, folgt der Senat nicht.

a) Die Beklagte vertritt den Standpunkt, die in der [X.] offenbarte [X.] zeige nicht direkt den Ort der [X.] innerhalb der [X.]. Vielmehr stehe der Fachmann angesichts der Anweisung des Abschnitts 12.6.4, die [X.] vorab herunterzuladen, vor dem ungelösten Problem, die [X.] innerhalb des von der [X.] angegebenen Segments zu finden. Um die [X.] wie in [X.] vorgeschlagen durch „[X.]“ anzufordern, fehle dem Fachmann in [X.] die Größe der [X.]. Im Gegensatz dazu sei in der [X.] genau gezeigt, wie der Bereich mit dem Index zu finden sei. So offenbare die [X.] hierzu insbesondere in Absatz [0055] und [0056] ein [X.]-Datenelement und Cluster-Elemente mit bekannter Größe.

Dieser Einwand vermag nicht zu überzeugen. Das gemäß dem Matroska-Containerformat spezifizierte[X.]-Datenelement kann innerhalb der [X.] gespeichert werden ([X.] Absatz [0054] erster und zweiter Satz) und bildet einen Index zu den kodierten Medien in der [X.] ([X.] Absatz [0055] erster Satz). Somit ist das [X.]-Datenelement mit der in der [X.] als Index angegebenen [X.] vergleichbar. Die Größe des [X.]-Datenelements ist in der [X.] nicht angegeben. Vielmehr lässt die [X.] offen, wie diese Größe ermittelt werden soll. In der Lehre der [X.] verhält es sich zwar ähnlich. Doch der Fachmann wird selbstverständlich die Größe der [X.] aus der Norm [X.]/[X.] 14496-12 ableiten, welche in [X.] als Referenz [104] sowie in [X.] als Referenz [7]genannt ist.

Indessen ist der Beklagten dahingehend beizupflichten, dass der in Tabelle 12.2der [X.] zu den [X.]s angegebene „[X.] nicht mit dem Begriff „range“ in der Wendung „byte range“ des Abschnitts 12.6.4 verwechselt werden darf. Da Letztere wie im Abschnitt I[X.]1.3 b) erläutert vom Fachmann jedoch ohne Weiteres den partiellen [X.] GET-Abfragen zugeordnet wird, ändert sich durch diese Klarstellung am Ergebnis letztlich nichts.

b) Die Beklagte argumentiert ferner, die [X.] zeige in Bezug auf das Merkmal [X.] nicht, wie die [X.] Bereiche innerhalb der [X.] angebe, die Informationen zu Kodierung und einem Index enthielten. Sie weist hierzu auf das in Abschnitt [X.] der [X.] dargestellte Beispiel hin, aus welchem unter anderem 41 [X.]-Einträge für 40 [X.] abzuleiten seien, wohingegen gemäß dem Merkmal [X.] ein einziger Verweis aus der [X.] auf einen Index in der [X.] gefordert sei.

Dieses Argument ist nicht stichhaltig. Denn das Merkmal [X.] schreibt nicht vor, wie viele Einträge eine [X.] enthalten darf, um die Bereiche jeder [X.] mit Informationen zu Kodierung und einem Index anzudeuten (indicates). Wie bereits im Abschnitt [X.]4.5.3 zur Auslegung des Merkmals [X.] ausgeführt, zeigt die [X.] nicht, wie die im Absatz [0067] ausschließlich im Plural genannten URIs auszugestalten sind, anhand derer [X.] aus Matroska-[X.] mit zumindest einem Teil des Indexes angefordert werden können. Dabei ist festzuhalten, dass die [X.] im Abschnitt [X.] ein umfangreiches Beispiel für den Inhalt einer [X.] gibt, dem unter anderem vollständig formulierte URLs und viele weitere Details entnehmbar sind. Demgegenüber offenbart die [X.] a. a. O. lediglich in allgemeiner Form, dass die [X.] URIs – ohne jegliches Detail – für das Anfordern von [X.]n beinhalten kann. Diese im Vergleich zur Lehre der [X.] äußerst knappe [X.] lässt keinen Raum dafür, dem Merkmal [X.] einen technischen Sinngehalt beizulegen, wonach die [X.] im Unterschied zur Lehre der [X.] nur einen einzigen Verweis auf einen Index in der [X.] enthalten darf.

Im Übrigen offenbart die [X.] eine Ausführungsform mit einem einzigen Verweis, wodurch das Merkmal [X.] nach seinem zweiten Teil sogar nach dem – vom Senat nicht geteilten – engen Verständnis der Beklagten erfüllt ist. Denn im Abschnitt 12.4.2.1 (letzte Zeile) nennt die [X.] eine Representation, die aus genau einem [X.]Media Segment besteht. Ein solches Segment kann in einer eigenen [X.] gespeichert sein. Die [X.] [X.] beinhaltet dann für diese [X.] und dessen Segment auch nur eine einzige [X.]. Das entspricht dem zweiten Teil des Merkmals [X.] nach der Auslegung der Beklagten.

Darüber hinaus enthält eine derartige [X.] lediglich eine einzige [X.], welche einen Index zu sämtlichen kodierten Medien in der gesamten [X.] bildet. Diese [X.] befindet sich definitionsgemäß im Anfangsbereich der [X.], welchen die [X.] [X.] durch den vorgenannten [X.] – ohne jeden Zweifel auffindbar – angibt. Außerdem ist eine solche einzelne [X.] kompakt und ohne Header adressierbar, so dass sie selbst nach der Auslegung der Beklagten als Index im Sinne des Merkmals [X.] zu gelten hat.

c) Die Beklagte meint ferner, die in der [X.]-Datei nach [X.]gespeichertenURLs würden einen Index zu den kodierten Medien in der [X.]bilden. Dieser befinde sich folglich in der [X.]-Dateiselbst. Anspruchsgemäß umfasse hingegenjede[X.] einen derartigen Index (Merkmal [X.]).

Mit diesem Einwand vermag die Beklagte nicht durchzudringen. Aus dem Umstand, dass die in der [X.]-Datei enthaltenen URLs es gestatten, Segmente zu finden, in denen unter anderem kodierte Medien abgelegt sind, folgt nicht zwangsläufig, dass die [X.] keine andere Datenstruktur offenbart, welche den Bedingungen des Merkmals [X.]im Hinblick auf den Index genügt. Durch die [X.] ist eine solche Datenstruktur gegeben, wie oben ausgeführt.

d) Die Beklagte wendet außerdem ein, das „Basic Profile“ nach[X.] komme nicht in Betracht, weil [X.] für adaptives Streaming nur solche [X.] zulasse, die die Anforderungen des „Adaptive Streaming Profile“ erfüllten.

Diesem Argument steht entgegen, dass eine [X.] gemäß [X.] mehreren Profilen genügen kann (Abschnitt 5.4.1 „General“). Die Anforderungen gemäß „Basic profile“ und „Adaptive-Streaming profile“ betreffen voneinander unabhängige Sachverhalte (Abschnitt 5.4.3 bzw. 5.4.9). Dementsprechend zählt die [X.] in Tabelle 5.1 (letzte Zeile) für das „Adaptive-Streaming profile“ nach Release 9 („3gh9“) als kompatible Profile ausdrücklich das „Basic profile“ nach Release 6, 7 und 8 auf, indem dort „[X.]“ mit den Bezeichnungen „3gp6, 3gp7, 3gp8“ genannt sind.

e) Weiterhin ist die Beklagte der Ansicht, das Standarddokument [X.]offenbare viele, insbesondere optionale, Elemente eines adaptiven Streaming-Systems, nicht aber eine unter die Vorgaben des Patentanspruchs 1 fallende konkrete Streaming-Variante, weil diese vom Fachmann ausgehend von der [X.] durch mehrfache Entscheidungen erst ausgewählt werden müsse.

Diesem Argument kann nicht gefolgt werden. Die Beklagte scheint aus dem Umfang des Dokuments [X.] zu schließen, es bedürfe über die zahlreichen in der [X.] unmittelbar und eindeutig offenbarten Elemente hinaus noch einer gesonderten Begründung, warum der Fachmann gerade eine bestimmte Untermenge aus dieser Gesamtheit herausgreifen würde. Ein solches Erfordernis sieht das [X.] nicht vor. Die Beklagte hat auch keine Rechtsnorm genannt, auf die sie ihre Auffassung stützt.

Soweit die Beklagte in diesem Zusammenhang auf die[X.]-Entscheidungen Olanzapin ([X.], Urteil vom 16. Dezember 2008,X ZR 89/07,GRUR 2009,382) und [X.] ([X.], Urteil vom 5. April 2011, [X.]/09,GRUR 2011,707) hinweist, geht dieser Versuch fehl. Denn beide Entscheidungen betreffen jeweils einen anderen Sachverhalt.

So befasst sich die Olanzapin-Entscheidung des [X.] mit der Frage, inwieweit eine allgemein offenbarte chemische Strukturformel dem Fachmann durch Mitlesen darüber hinaus konkrete chemische Einzelverbindungen offenbart, die nicht ausdrücklich genannt sind. Vorliegend geht es jedoch um Sachverhalte, die der [X.] durchwegs unmittelbar und eindeutig entnehmbar sind, weshalb sich die Frage eines Mitlesens überhaupt nicht stellt.

In der weiterhin genannten [X.]-Entscheidung des [X.] wird festgehalten, dass ein Gerätesatz nicht bereits deswegen neuheitsschädlich vorweggenommen ist, wenn dessen verschiedene Komponenten im Stand der Technik zwar als Einzelgegenstände vorbekannt waren, jedoch ohne die zusätzliche Angabe, funktionsbestimmt zusammengefügt werden zu können. Demgegenüber ist vorliegend der einem einzelnen [X.]sort, nämlich der [X.] einschließlich [X.], entnehmbare Stand der Technik zu betrachten, der in einem dedizierten Abschnitt 12 der [X.] als ein adaptives Streaming spezifiziert ist, dessen Gestaltungsmöglichkeiten sich sämtlich in ein und denselben funktionalen Bezugsrahmen einordnen.

f) Auch dem Einwand der Beklagten, Patentanspruch 1 sei auf ein Gerät gerichtet, wohingegen die [X.] ein Protokoll beschreibe, kann nicht beigetreten werden. Denn das anspruchsgemäße Wiedergabegerät ist nahezu ausschließlich durch Verfahrensmerkmale bestimmt. Diese gehen, wie erläutert, ohne Weiteres aus der [X.] hervor.

Sofern die Beklagte darüber hinaus argumentiert, die [X.] sei ein noch nicht verabschiedeter Entwurf und daher womöglich unvollständig und widersprüchlich, führt dies zu keiner anderen Beurteilung. Denn die Beklagte hat in der Lehre der [X.] keine Widersprüche aufgedeckt. Zudem sind die Anweisungen der [X.] zumindest im Hinblick auf den [X.] vollständig genug, um diesen nacharbeiten zu können.

Auch die Hilfsanträge bleiben ohne Erfolg. Der [X.] der mangelnden Patentfähigkeit besteht in den Fassungen der [X.] bis [X.] unverändert fort. Im Hinblick darauf kann dahingestellt bleiben, ob die Fassungen jeweils zulässig sind.

1. Der Hilfsantrag I hat keinen Erfolg, weil der Gegenstand seines Patentanspruchs 1 nicht neu ist.

Im Unterschied zur erteilten Fassung ist im Patentanspruch 1 gemäß Hilfsantrag I zwischen den Merkmalen c3 („using the top level index file to request the portions of the container file …“) und c4 („configure a video decoder …“) das folgende Merkmal des erteilten Unteranspruchs 2 (mit vom Senat vergebener Bezeichnung [X.] sowie redaktionellen Änderungen) eingefügt:

[X.]_

Demnach wird für den abgerufenen Bereich ([X.]: „the retrieved portion“) der [X.] des ausgewählten alternativen [X.], der den Index zu den kodierten Medien in der [X.] enthält, über die erteilte Fassung hinaus festgelegt, dass dieser Bereich ausreichende [X.]en enthält, um die Gesamtheit (entirety)des ausgewählten alternativen [X.] zu streamen.

Doch jedenfalls dann, wenn die Gesamtheit der Mediendaten eines ausgewählten alternativen [X.] in einem [X.] Segment nach [X.] und folglich in einer einzelnen [X.] gespeichert ist (d. h. in dem in Abschnitt I[X.]2.b) erläuterten Fall), bildet die [X.] dieses einzigen Segments einen Index mit ausreichenden [X.]en, um die Gesamtheit des Segments und somit auch des darin enthaltenen [X.] zu streamen– Merkmal [X.].

Der Einwand der Beklagten, der [X.] sei keine Lehre dahingehend zu entnehmen, die [X.]en mehrerer [X.] gleichzeitig herunterzuladen, greift daher zumindest bei der vorgenannten Fallgestaltung mit einem einzigen Segment nicht durch.

2. Auch Hilfsantrag [X.] hat keinen Erfolg, weil der Gegenstand seines Patentanspruchs 1 nicht neu ist.

Um einer etwaigen Unzulässigkeitsrüge zu begegnen, ist im Patentanspruch 1 gemäß Hilfsantrag [X.] ein Teil des Merkmals [X.]wie folgt gestrichen:

[X.]_[X.]_

Weiterhin sind in den Merkmalen [X.] und c3 jeweils die Zeichenfolgen „(i)“ und „([X.])“ in folgender Weise eingefügt:

[X.]_[X.]__[X.]_

In den abgeänderten Merkmalen [X.]_[X.] und [X.]soll jeweils klargestellt werden, dass die [X.] (i) Informationen betreffend die Kodierung und zudem ([X.]) einen Index zu den kodierten Medien beinhalten soll.

Die Patentfähigkeit des Gegenstands des gemäß Hilfsantrag [X.] abgefassten Patentanspruchs 1 ist nicht anders zu beurteilen als beim erteilten Anspruch 1 gemäß Hauptantrag. Denn die [X.] offenbart, wie im Abschnitt I[X.]1.2 d) [X.]) ausgeführt, auch einen Index (sidx) zu den kodierten Medien in der [X.] gemäß den geänderten Merkmalen [X.]_[X.] und [X.]; und einen Stream aufgrund der abgerufenen [X.] auszuwählen (Merkmal [X.]_[X.]), geht aus den im Abschnitt I[X.]1.3 a) zu dem Merkmal [X.] erläuterten Stellen der [X.] hervor.

3. Hilfsantrag [X.] kann nicht günstiger beurteilt werden.

Patentanspruch 1 gemäß Hilfsantrag [X.] vereinigt die Änderungen der Hilfsanträge I und [X.] gegenüber der erteilten Fassung. Der dadurch gebildete [X.] gibt wegen der technischen Unabhängigkeit der geänderten Merkmale keinen Anlass, die Patentfähigkeit anders zu beurteilen als bei den jeweils für sich genommen Hilfsanträgen I und I[X.]

4. Hilfsantrag [X.] hat keinen Erfolg, weil der Gegenstand seines Patentanspruchs 1 durch die [X.] in Verbindung mit der [X.] neuheitsschädlich vorweggenommen ist.

Basierend auf Hilfsantrag [X.] sind im Patentanspruch 1 nach Hilfsantrag [X.] die[X.] (Merkmal b, [X.]) durch folgende Änderungen näher bestimmt:

b_[X.]_[X.]_[X.]_

Demnach sollen gemäß dem geänderten Merkmal b_[X.] die [X.] jeweils einen Stream enthalten (container files that each contain a stream), und analog dazu soll gemäß dem geänderten Merkmal [X.]_[X.] jeder der alternativen [X.] als ein einzelner Stream in einer eigenen [X.] gespeichert sein (store das a single stream in a separate container file).

Im Abschnitt I[X.]1.2 b) ist bereits in Bezug auf das Merkmal [X.] erläutert, dass [X.] nach der Lehre der [X.] gemäß dem „Basic profile“ in einer eigenen 3GP-[X.] gespeichert sein können. Für das „Basic profile“ legt die [X.] im Abschnitt 5.4.3 fest, dass die maximale Anzahl an Spuren bei [X.] genau eins betragen soll (maximum number of tracks shall be one for video). Demzufolge geht aus der [X.] hervor, dass in einer dem „Basic profile“ entsprechenden 3GP-[X.] ein Video-Stream nur einzeln gespeichert werden darf. Es ist davon auszugehen, dass diese Eigenschaft auch bei einer Kombination des „Basic Profile“ mit dem „Adaptive-Streaming Profile“ erhalten bleibt, da sich in diesem Fall die Eigenschaften einer 3GP-Containerdatei gemäß Abschnitt 5.4.1 der [X.] nach den Bedingungen beider Profile richten ([X.]). Somit ist der Gegenstand nach den geänderten Merkmalen b_[X.] und [X.]_[X.] gemäß Hilfsantrag [X.] durch die [X.], auf welche die [X.] Bezug nimmt, vorweggenommen.

5. Hilfsantrag V ist nicht günstiger zu beurteilen.

Patentanspruch 1 gemäß Hilfsantrag V weist sämtliche Änderungen der [X.], [X.] und [X.] gegenüber der erteilten Fassung auf. Auch diese geänderten Merkmale sind, wie zu den zugrundeliegenden Hilfsanträgen erläutert, im durch Druckschrift [X.]unter Einschluss der in Bezug genommenen Druckschrift [X.] gegebenen Stand der Technik vorbeschrieben.

6. Auch den Hilfsanträgen VI und V[X.] kann nicht stattgegeben werden.

Patentanspruch 1 in der jeweiligen Fassung gemäß Hilfsantrag VI und V[X.] geht aus vom [X.] nach Hilfsantrag [X.] bzw. V und ergänzt das Merkmal a folgendermaßen:

a_VI_

Demzufolge wird in dem geänderten Merkmal a_VI festgelegt, dass [X.] und [X.] von einem entfernten Server(from a remote server) über ein Netzwerk angefordert werden sollen.

In Abschnitt 12.1 mit [X.]ur 12.1 der [X.] ist offenbart, dass ein [X.] Streaming Client sowohl die [X.] [X.] als auch die übrigen Metadaten und Mediendaten von einem [X.] Streaming Server anfordert. Demnach ist das Merkmal a_VI (… from a remote server …) gleichfalls der [X.] entnehmbar. Infolgedessen ist der jeweilige Gegenstand des Patentanspruchs 1 gemäß Hilfsantrag VI und V[X.] nicht anders zu beurteilen als nach den zugrundeliegenden Hilfsanträgen [X.] bzw. V.

7. Hilfsantrag [X.] kann gleichfalls keinen Erfolg haben.

Ausgehend vom Patentanspruch 1 nach Hilfsantrag V[X.] wird am Ende des Anspruchs Folgendes hinzugefügt:

c9_

In dem neu gebildeten Merkmal c9gemäß Hilfsantrag [X.] wird das Wiedergabegerät dahin näher bestimmt, dass es Teile der [X.] und [X.] von entfernten Servern mittels Hypertext Transfer Protocol([X.]) „[X.]“ anfordern soll.

Der in [X.] spezifizierte Adaptive [X.]-Streaming Client soll gemäß Abschnitt 12.3 [X.] und [X.] oder Teile davon mittels [X.] GET-Abfragen anfordern. Diese sind wie das gesamte [X.]-Protokoll im Internet-Standard RFC2616 normiert, den die [X.] als Referenz [17]benennt ([X.]). An anderer Stelle (S. 19 Abs. 6) lehrt die [X.], 3GP-[X.] herunterzuladen, indem fortschreitend (progressive) „[X.] GET requests with byte ranges“ gemäß dem Standard [17] eingesetzt werden. Damit ist der die [X.] betreffende Teil des Merkmals c9 in [X.] vorbeschrieben.

Weiterhin ist der [X.] entnehmbar (Abschn. 12.2.5.1 [X.] Abs. 4), dass die [X.] [X.] mittels [X.]-Protokoll zum Wiedergabegerät übermittelt werden kann (If the [X.] is delivered over [X.]). Dies kann gemäß dem im Abschnitt 12.6.7 genannten Status Codes 206 mittels partieller [X.] GET-Abfragen, die ebenso als „[X.] GET requests with byte ranges“ bezeichnet werden, erfolgen. Demzufolge ist das auf die [X.] gerichtete [X.] des Merkmals c9 aus [X.] gleichfalls bekannt.

Im Ergebnis offenbart die Druckschrift [X.] auch das mit Hilfsantrag [X.] hinzugefügte Merkmal c9.

Nachdem der Patentanspruch 1 des Streitpatents weder in der erteilten Fassung nach Hauptantrag noch in einer der Fassungen gemäß den [X.] hat und die abhängigen Patentansprüche nicht gesondert verteidigt werden, war das Streitpatent insgesamt für nichtig zu erklären.

Die Kostenentscheidung beruht auf § 84 Abs. 2 Satz 1 und Satz 2 Halbsatz 1 PatG i. V. m.§ 91 Abs. 1 ZPO.

Die Entscheidung über die vorläufige Vollstreckbarkeit beruht auf § 99 Abs. 1 PatG i. V. m.§ 709 Satz 1 und 2 ZPO.