T 0864/15 () of 17.2.2020

European Case Law Identifier: ECLI:EP:BA:2020:T086415.20200217
Date of decision: 17 February 2020
Case number: T 0864/15
Application number: 10717339.5
IPC class: H04N5/76
G11B27/10
H04N7/24
H04N9/82
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 367 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: DIGITAL VIDEO RECORDER RECORDING AND RENDERING PROGRAMS FORMED FROM SPLICED SEGMENTS
Applicant name: ARRIS Enterprises LLC
Opponent name: -
Board: 3.5.04
Headnote: -
Relevant legal provisions:
European Patent Convention Art 56 (2007)
Keywords: Inventive step - (no)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division refusing European patent application No. 10717339.5, published as international patent application WO 2010/123713 A1.

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

D1: "StationRipper**(TM) - The Advanced Internet Radio Recorder V2.30-V2.33 - change log", 22 June 2008 (2008-06-22), XP002588836, Retrieved from the Internet: URL:http://web.archive.org/web/20080622152414/http://www.stationripper.com/version/pages/V2.33_ChangeLog.htm, [retrieved on 2010-06-25]

D2: "Cue Sheet" from Hydrogenaudio Knowledgebase, 22 August 2008 (2008-08-22), XP002588837, Retrieved from the Internet: URL:http://web.archive.org/web/20080822101630/http://wiki.hydrogenaudio.org/index.php?title=Cuesheet [retrieved on 2010-06-25]

D6: US 2008/0092168 A1

D9: SMPTE standard 312M-1999, "SMPTE STANDARD for Television - Splice Points for MPEG-2 Transport Streams", THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS, 1999

III. The decision under appeal was based on the grounds that independent claims 1, 9 and 14 according to each of the main, first and second auxiliary requests did not meet the requirement of clarity of Article 84 EPC and that their subject-matter did not involve an inventive step (Article 56 EPC) in view of prior-art documents D6, D1 and D2.

IV. With the statement of grounds of appeal, the appellant maintained all the requests underlying the decision under appeal.

V. The board issued a summons to oral proceedings and a communication under Article 15(1) of the Rules of Procedure of the Boards of Appeal (RPBA 2007, see EPC 16th edition, June 2016, pages 602 to 629) in which it gave a preliminary opinion which may be summarised as follows:

- Claims 1, 9 and 14 according to the main, first and second auxiliary requests did not meet the requirements of Article 84 EPC (lack of clarity) and Article 123(2) EPC (added subject-matter).

- The subject-matter of claims 1, 9 and 14 according to the main, first and second auxiliary requests did not involve an inventive step (Article 56 EPC) in view of prior-art document D6 and common general knowledge as evidenced by, for instance, document D9.

VI. With a letter dated 16 January 2020, the appellant filed amended claims according to a main request and an auxiliary request replacing all previous requests on file.

VII. The board held oral proceedings on 17 February 2020.

The appellant's final requests were that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request, filed by letter dated 16 January 2020 as auxiliary request, or claim 1 of the auxiliary request filed at the oral proceedings of 17 February 2020.

At the end of the oral proceedings, the Chair announced the board's decision.

VIII. Claim 1 according to the appellant's main request reads as follows:

"A method of recording a program, comprising:

storing (220), in response to a user request, at least one content file (510) that includes first and second program segments, wherein an identification of a splice point is included in an elementary stream associated with at least one of the first and second program segments, the splice point denoting a transition between the first and second program segments;

in a digital video recorder, creating and storing (230) at least one index file (530) that includes program specific information (540) associated with the first and second program segments, wherein the program specific information includes a program's service number that is used to access a program map table stored in the index file, wherein the program map table includes packet identifiers, the index file further including the identification of the splice point; and

in the digital video recorder, creating and storing (240) a splice index record (560) that includes timing information specifying a time at which the splice point occurs;

wherein, during a playback of the content file in a trick play mode, the splice index record (560) is available to the digital video recorder, and the splice index record (560) enables the transition between the first and second program segments, such that the digital video recorder does not need to receive the identification of the splice point from one of the first and second program segments during the playback of the content file in the trick play mode."

IX. Claim 1 according to the appellant's auxiliary request reads as follows:

"At least one non-transitory computer-readable medium encoded with instructions which, when executed by a processor, perform a method including:

receiving user input requesting playback of a recorded program that includes first and second program segments that are stored in at least one content file, wherein an identification of a splice point is included in an elementary stream associated with at least one of the first and second program segments, the splice point denoting a transition between the first and second program segments;

causing a first set of program specific information associated with the first segment of the recorded program to be loaded into a DVR processor, wherein the program specific information includes a program's service number that is used to access a program map table stored in an index file, wherein the program map table includes packet identifiers;

causing the first segment of the recorded program to be retrieved from a content file and rendered using the first set of program specific information;

retrieving timing information from a splice index record (560) that includes a splice point denoting a transition time between the first and second program segments;

determining from the timing information when the splice point in the recorded program being rendered has been reached, wherein, during a playback of the content file in a trick play mode, the splice index record (560) is available to the DVR processor, and the splice index record (560) enables the transition between the first and second program segments, such that the DVR processor does not need to receive the identification of the splice point from one of the first and second program segments during the playback of the content file in the trick play mode;

upon reaching the splice point, causing a second set of program specific information associated with the second segment of the recorded program to be loaded into the DVR processor; and

causing the second segment of the recorded program to be retrieved from the content file and rendered using the second set of the program specific information presently loaded in the DVR processor."

X. The reasons given in the decision under appeal, as far as relevant for the appeal proceedings, may be summarised as follows:

The claimed subject-matter was merely an aggregation or juxtaposition of features in the context of receiving two different programs which were spliced to form a single program. A first feature concerned the collection of metadata in an index file and was known from D6. A second feature concerned the collection of timing information for allowing easier trick play functionality and was known from D1.

Reasons for the Decision

1. The appeal is admissible.

The invention

2. The present invention relates generally to recording devices such as a digital video recorder and more specifically to a method and apparatus in which content that is spliced from two or more segments is to be rendered as a single program during playback from the digital video recorder. In particular, it concerns the problem of ensuring that the segments are spliced properly, not only in the normal playback mode but also during trick play mode, e.g. in the reverse playback and fast-forward modes.

Main request - inventive step (Article 56 EPC)

3. Closest prior art

3.1 The examining division held that the method of claim 1 consisted of a juxtaposition of two sets of features with no synergy between them and regarded document D6 to be the closest prior art for the first set of features (on the collecting of metadata in an index file) and document D1 as the closest prior art for the second set of features (on the collecting of timing information for allowing easier trick play functionality).

The board concurs with the appellant that the above division of the subject-matter of claim 1 into two completely separate inventions goes too far because there is at least some degree of synergy between them (see statement of grounds of appeal, page 2, second to fourth paragraphs). The board regards prior-art document D6 to be the closest prior art for the subject-matter of claim 1 because it belongs to the same technical field as the invention and discloses the most features of the method of claim 1.

3.2 The appellant has not disputed that document D6 represents the closest prior art for the method of claim 1.

4. Disclosure of D6

4.1 Document D6 discloses an audio and/or video program recording and playback system using metadata (see title of D6). D6 describes various advantages of dividing audio and/or video programs into segments, recording the segments, storing metadata about the segments and using the metadata during playback of the segments. The metadata may be used for splicing segments, e.g. for inserting an advertising segment into a recorded program during playback (see paragraphs [80] and [395]).

4.2 D6 discloses the following features of claim 1:

A method of recording a program (see paragraph [56], first sentence, and paragraph [271]), comprising:

- storing, in response to a user request, at least one content file that includes first and second program segments; (see paragraph [10], first sentence)

- in a digital video recorder, creating and storing at least one index file that includes program specific information associated with the first and second program segments (the metadata of D6 is program specific information associated with program segments that may be stored in a separate file, i.e. in an index file: see paragraphs [44], [47], [72] and [73]), the index file further including the identification of the splice point (see paragraphs [80] and [395])

5. Distinguishing features

5.1 The method of claim 1 thus differs from that of D6 by the following distinguishing features.

(a) An identification of a splice point is included in an elementary stream associated with at least one of the first and second program segments, the splice point denoting a transition between the first and second program segments.

(b) The program specific information includes a program's service number that is used to access a program map table stored in the index file, wherein the program map table includes packet identifiers.

(c) In the digital video recorder, the creating and storing of a splice index record that includes timing information specifying a time at which the splice point occurs, wherein, during playback of the content file in a trick play mode, the splice index record is available to the digital video recorder, and the splice index record enables the transition between the first and second program segments such that the digital video recorder does not need to receive the identification of the splice point from one of the first and second program segments during playback of the content file in the trick play mode.

5.2 The appellant did not dispute that the method of claim 1 differed from that of D6 by the above distinguishing features.

6. Objective technical problem

6.1 The appellant stated during the oral proceedings that the objective technical problem should be generally formulated as "how to facilitate trick play".

6.2 The board has no objection to this formulation of the objective technical problem.

7. Obviousness

7.1 Re distinguishing feature (a)

D6 mentions that the video signal may be compressed according to the MPEG standard, i.e. that the program segments may be transmitted and stored as MPEG elementary streams (see paragraph [72]). The insertion of an identification of a splice point in an MPEG elementary stream associated with at least one segment to be spliced is acknowledged as commonly known on page 2, lines 1 to 7, of the description of the application. It is also common general knowledge, as evidenced by D9, which describes a splice information table associated with a given program for notifying downstream devices of splice events in advance of those events (see page 1, right column, first paragraph, and point 7.1).

Hence, the skilled person would have arrived at distinguishing feature (a) without inventive activity.

The appellant did not dispute that distinguishing feature (a) would have been obvious to the skilled person.

7.2 Re distinguishing feature (b)

Program specific information (PSI), a program number and a program map table (PMT) including packet identifiers (PID) are standard features of streams according to the MPEG-2 standard. Program specific information is metadata about a program (which is identified by a number) and includes a program map table for each program. Since D6 discloses that the video signal may be compressed with MPEG, these pieces of additional information about the program segments, i.e. metadata for the program segments, would also have been stored in the digital video recorder so they would have been available for playing back the stored program segments.

Hence, the skilled person would have arrived at distinguishing feature (b) without inventive activity.

The appellant did not dispute that distinguishing feature (b) would have been obvious from D6 and common general knowledge.

7.3 Re distinguishing feature (c)

7.3.1 According to D6, the stored metadata comprises information specifying the order in which the program segments are to be spliced (see "playlist metadata which identifies a selected set of the stored segments ant [sic] the ordered sequence in which those segments are to be reproduced in the absence of an intervening control command from the viewer" in paragraph [10]). According to D6, the stored metadata also comprises information on the splice point(s) including timing information specifying the time(s) at which the splice point(s) occurs (see paragraphs [80] and [395]).

It was common general knowledge that metadata associated with an audio-visual program segment contained much less information than the program segment itself and was typically stored in a separate file.

During playback of a stored program, the metadata associated with a program segment would be read before the program segment itself so that it could be used for controlling the decoding of the program segment. The file storing the metadata in D6 would thus have all the features of the "splice index record" of distinguishing feature (c). The metadata would contain all the necessary information, i.e. the order in which the program segments were to be spliced and timing information specifying the time(s) at which the splice point(s) occurred, for allowing the digital video recorder to correctly schedule the splice point(s).

It should be noted that the metadata of D6 allows the digital video decoder to correctly schedule the splice point(s) regardless of whether the playback is performed in the normal mode (forward direction at normal speed) or in a trick play mode (reverse mode and/or faster speed). Trick play modes, in particular the reverse and fast-forward modes, are explicitly disclosed in D6 (see paragraphs [54], [311] and [399]).

For the above reasons, the skilled person would have arrived at distinguishing feature (c) without an inventive step.

7.3.2 The appellant's arguments may be summarised as follows.

(1) The skilled person would not have used the metadata in D6 to schedule the splice points. Instead, they would have used the well-known technique described on page 2, lines 1 to 7, of the description of the application, i.e. the technique of using a data packet indicating that a splice point was about to be reached (illustrated by the "splice point notification" in figures 3 to 5). In other words, the skilled person would have had no reason to use the metadata for scheduling splice points when starting from D6.

(2) The problem solved by the invention of missed splice points during playback in the reverse and fast-forward modes (see figures 3 to 5) was mentioned neither in D6 nor in any other prior-art document. The skilled person would not have been aware of this problem.

7.3.3 The board did not find these arguments persuasive for the following reasons.

Re argument (1)

The technique of using a data packet indicating that a splice point is about to be reached is not mentioned in D6. Nor was it the sole known technique for informing the decoder of an incoming splice point. D9, for instance, discloses under point 7.1 that "Splice events may be communicated in three ways: they may be scheduled ahead of time, a preroll warning may be given, or a command given to execute the splice event at specified Splice Points". The technique referred to by the appellant corresponds only to one of these three techniques (the "preroll warning").

The appellant's argument that the skilled person would have only used that technique because it was the only known one is thus not persuasive. In the board's view, the skilled person would have been more inclined to use the "scheduled ahead of time" technique of D9 because the metadata in D6 contains all the necessary information (timing information and segment-order information) for scheduling the splice points ahead of time.

Re argument (2)

In D6, by using the timing information and segment-order information in the metadata for scheduling the splice points ahead of time, the skilled person would have automatically solved the problem of the invention of correctly identifying splice points during playback in the reverse and fast-forward modes, regardless of whether they would have been aware of the problem.

Moreover, the argument that the person skilled in the art would not have been aware of the problem is not persuasive. The problem of missing splice points occurs potentially every time trick play is used on a digital video recorder having recorded segments which are spliced in a targeted manner.

8. Conclusion on the main request

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

Auxiliary request - inventive step (Article 56 EPC)

9. Claim 1 of the auxiliary request concerns at least one non-transitory computer-readable medium encoded with instructions which, when executed by a processor, perform a method, the steps of which are laid out in the claim. This is a method essentially for playing back a program which was recorded by the method of claim 1 according to the main request. The steps of the method may be summarised as follows.

- A user requests playback of a recorded program.

- The program specific information of a first program is read and used for playing back the first program segment.

- It is determined from the timing information stored in the splice index record when a splice point in the recorded program is reached. This is also done during playback in a trick play mode.

- Upon reaching the splice point, the program specific information of a second program is read and used for playing back the second program segment.

In the board's view, the method performed by the instructions encoded on the computer-readable medium of claim 1 amounts to the straightforward manner in which the skilled person would have used, during playback of MPEG-2 program segments, the information on a splice point stored in the metadata of D6, i.e., in essence, by reading in the metadata information indicating where the splice point is located in time and which program segments are to be played before and after the splice point in the normal playback mode or a trick play mode.

The appellant had no further arguments beyond those already presented with respect to claim 1 of the main request.

10. Conclusion on the auxiliary request

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

Conclusion

Since neither of the appellant's main and auxiliary requests is allowable, the appeal must be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation