T 1270/11 () of 25.4.2016

European Case Law Identifier: ECLI:EP:BA:2016:T127011.20160425
Date of decision: 25 April 2016
Case number: T 1270/11
Application number: 05711648.5
IPC class: H04N 7/173
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 352.115K)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: INTERACTIVE TELEVISION SYSTEM WITH AUTOMATIC SWITCHING FROM BROADCAST MEDIA TO STREAMING MEDIA
Applicant name: Rovi Guides, Inc.
Opponent name: -
Board: 3.5.04
Headnote: -
Relevant legal provisions:
European Patent Convention 1973 Art 56
Keywords: Inventive step - main request (no)
Inventive step - auxiliary request (no)
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. The appeal is directed against the decision to refuse European patent application No. 05 711 648.5, published as international application WO 2005/071936 A2.

II. The patent application was refused by the examining division on the grounds that the subject-matter of the independent claims of the main request and first to fourth auxiliary requests lacked inventive step in view of document:

D1: WO 00/33568 A1.

III. The applicant appealed against this decision and with the statement of grounds of appeal submitted further requests, namely the fifth to ninth auxiliary requests.

IV. The board indicated in a communication annexed to a summons to oral proceedings that it had doubts whether the subject-matter of the independent claims of all pending requests involved an inventive step.

V. In response with a letter dated 25 March 2016, the appellant withdrew the first, fifth, sixth, seventh and eighth auxiliary requests and filed a tenth auxiliary request.

VI. Oral proceedings were held before the board on 25 April 2016. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of one of the following requests:

- Main Request, as filed on 12 March 2008;

- Second Auxiliary Request, as filed on 14 May 2010;

- Third Auxiliary Request, as filed on 14 May 2010;

- Fourth Auxiliary Request, as filed on 14 May 2010;

- Ninth Auxiliary Request, as filed on 27 May 2011;

- Tenth Auxiliary Request, as filed on 25 March 2016.

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

"A method for providing a user with playback control functions while viewing a broadcast television program on user equipment, the method comprising:

providing the broadcast television program to the user equipment;

receiving a request from the user to perform a playback control function while viewing the television program that is currently being broadcast;

and providing a streaming version of the broadcast television program to the user equipment instead of the broadcast television program in response to the received request, characterised in that the streaming version of the broadcast television program is generated before the broadcast of the television program."

VIII. Claim 1 of the second auxiliary request differs from claim 1 of the main request in that the following additional feature has been inserted after the phrase "... that is currently being broadcast":

"wherein the playback control function is selected from the group consisting of: fast forward, slow forward, jump to another time point and skip".

IX. Claim 1 of the third auxiliary request corresponds to claim 1 of the second auxiliary request, with the additional feature of the second auxiliary request having been modified to read:

"wherein the playback control function is selected from the group consisting of: fast forward, slow forward and skip".

X. Claim 1 of the fourth auxiliary request differs from claim 1 of the main request in its second feature which reads (amendments highlighted in bold):

"receiving a request from the user to perform a fast-forward playback control function while viewing the television program that is currently being broadcast;".

XI. Claim 1 of the ninth auxiliary request is identical to claim 1 of the fourth auxiliary request, with the following additional features appended to the claim:

"... and providing the streaming version comprises determining the time point in the broadcast television program at which the user requests to perform the playback control function and providing the streaming version of the television program starting at substantially the same time point."

XII. Claim 1 of the tenth auxiliary request corresponds to claim 1 of the ninth auxiliary request, with the following additional feature appended to the claim:

"... and receiving and displaying portions of the streaming version in advance of the broadcast version in response to a user request to fast-forward playback of the program in advance of the broadcast version."

XIII. The examining division accepted that the subject-matter of claim 1 of the main request differed from the disclosure of D1 in that the former specified that the streaming version of the broadcast television program was generated before the broadcast of the television program. However, D1 described a prior-art file server used for streaming in which the fast forward and fast reverse streams were pre-encoded and stored in the server. D1 solved the problem that such encoding could not be used for producing fast forward and fast reverse streams in real time such that a real-time program might be stored for almost immediate use of VCR-like functions. Thus, D1 established a clear link between the real-time (simultaneous) encoding of the trick play streams and the fact that the program was a real-time program (e.g. a live sports event). It was generally known that real-time video encoding was processor-intensive. Therefore, the skilled person would have considered generating the trick play streams for any other program (such as series, films, etc...) before the broadcast. Moreover, for any repeat showing of a program, the skilled person would not have generated the trick play streams again, but simply retrieved the available (previously stored) streams from memory. Therefore, in case of a repeat, the trick play streams would have been generated after the first broadcast but before the second broadcast. Hence, the subject-matter of claim 1 of the main request did not involve an inventive step (see point 2 of the communication dated 2 July 2010, which was referred to in a decision according to the state of the file issued by the examining division).

With respect to the second to fourth auxiliary requests, the examining division held that D1 disclosed a fast forward command and that the further choices of playback control were obvious alternatives for the known trick play (see point 4 of the communication dated 2 July 2010).

XIV. The appellant's arguments may be summarised as follows:

With respect to the main request, the appellant argued that D1 failed to disclose the encoding of a storage bit stream in advance of the broadcast. D1 disclosed that a video sequence was simultaneously encoded into two streams - a broadcast bit stream for broadcasting and a storage bit stream to enable trick play. In contrast, the present application proposed to generate the streaming version before the broadcast of the television program which allowed a user to view a portion of the streaming version in advance of the broadcast.

Hence, starting from D1, the claimed invention solved the problem of how to provide improved trick play functionality for a broadcast program.

D1 did not disclose how the signal from the video source could be obtained prior to it being encoded for broadcasting. In addition, since in D1 the storage bitstream was generated in parallel with the broadcast bit stream, the transition was inherently more or less seamless, without any need for referencing of respective positions between the bit streams. Hence, there was no provision in D1 for coordinating the two streams, other than the reliance on their simultaneous generation. The prior art referred to in D1 was of no assistance in arriving at the claimed solution, since it related to video-on-demand systems which had no real-time capabilities and it was not concerned with broadcasting. D1 clearly taught limiting playback functions to the point reached in the real-time broadcast bitstream. A person skilled in the art would not be motivated to provide a viewer with the capability of viewing and/or performing playback controls in advance of a point reached in a currently broadcast program, because D1 did not envisage or suggest that such capability would be desirable or even possible. D1 specifically referred to the trick play bitstream reaching an end-of-file indicator (see D1, page 14, lines 8 to 11). Such reliance on the end-of-file indicator would be incompatible with the use of a pre-generated trick play stream.

The independent claims of the second to fourth auxiliary requests specified particular trick play functions which allowed to advance beyond the broadcast. The arguments with respect to the main request applied equally to these requests. The particular trick play functions which advanced the streaming version beyond the broadcast program required an ability to predict the future if they were to be used in conjunction with live broadcasts.

The independent claims of the ninth auxiliary request additionally emphasized the synchronisation that was necessary for seamless switching between the broadcast television program and the streaming version of the program. In D1 there was no need to determine a time point at which the user requested to perform the playback control function. Instead, D1 could directly switch from the broadcast stream to the stored stream, while relying on the real-time coupling between them to ensure synchronisation as described in D1, page 13, lines 3 to 10.

Claims 1 and 14 of the tenth auxiliary request additionally specified the feature of receiving and displaying portions of the streaming version in advance of the broadcast version in response to a user request to fast-forward playback of the program in advance of the broadcast version. This feature further distinguished the claimed subject-matter from the simultaneous encoding of broadcast and storage streams disclosed in D1.

Reasons for the Decision

1. The appeal is admissible.

The invention

2. The present invention relates to an interactive television system in which the user may perform playback control functions (also called trick play or VCR-like functions) such as pause, rewind, fast-forward, etc. while watching a broadcast television program. When the user requests such a function, the user equipment switches from displaying the broadcast television program to displaying a streaming version of the program. The streaming version, which is generated before the broadcast of the television program, may be provided by a television distribution facility in response to the user request. If the user requests to fast forward a program, portions of the program in advance of the broadcast version may be displayed to the user (see paragraphs [0010], [0011], [0156] to [0158] and [0169]).

In order to facilitate seamless switching between the broadcast and the streaming version of the program, the time point at which the user requests to perform the playback control function may be determined and the streaming version may be provided starting at this time point. Seamless switching can be effected using a count of time elapsed or the frame count relative to a reference point in the program (see paragraphs [0013], [0163] and [0174] to [0176]).

Main request

3. It is common ground that D1 may be considered as the closest prior art with respect to the subject-matter of claim 1.

3.1 D1 discloses a method for providing a user with playback control functions such as fast forward and fast reverse. A video frame sequence is encoded in real time into a broadcast bitstream and one or several so-called "storage bitstreams" encoding fast forward, fast reverse or standard play bitstreams. The broadcast bitstream is broadcast to system subscribers as the sequence is encoded, while the storage bitstreams are stored in an information server. At the request of a user pressing a "rewind" button on the remote control, the stored fast reverse bitstream is transmitted to the user equipment, providing the effect of a VCR rewind function. Pressing the "play" button on the remote control then causes the standard play stream to be transmitted to the user (see D1, page 3, line 6 to page 4, line 24; page 11, lines 13 to 15 and page 12, line 18 to page 13, line 33).

Hence, D1 discloses the features of the preamble of claim 1.

3.2 D1 does not disclose that the streaming version of the broadcast television program is generated before the broadcast of the television program.

The appellant argued that this feature provides the technical effect that portions of the program ahead of the broadcast are available to support trick play

functionality, such as fast forwarding, which advances ahead of the broadcast (see statement of grounds, page 2, fifth paragraph). Even though it is accepted that the distinguishing feature is a prerequisite for allowing portions of the program to advance ahead of the broadcast, the board is not convinced that generating the streaming version before the broadcast of the program implies that fast forward commands will result in the display of program portions advancing ahead of the broadcast program. The user equipment could equally switch back to display the broadcast program if a fast forward bitstream caught up with the broadcast program. Nevertheless, since in the board's judgement it makes no difference whether this feature is considered to provide the effect or not, and since the effect will have to be dealt with in the context of the auxiliary requests, the board accepts that this effect is achieved.

3.3 The board concurs with the appellant that, starting from D1, the claimed invention solved the problem of how to provide improved trick play functionality for a broadcast program (see appellant's letter dated 25 March 2016, page 2, fourth paragraph).

3.4 In its description of the background art, D1 discloses a video-on-demand (VoD) system used for streaming, in which the fast forward and fast reverse streams were pre-encoded and stored in a server. This system had the disadvantage that fast forward and fast reverse streams could not be generated in real time. Therefore, these streams could not be encoded and stored for almost immediate use of VCR-like functions (see page 1, line 25 to page 3, line 2). Starting from this prior art, D1 solves the problem of providing users with a system for real-time broadcasts, such as for sporting events, allowing VCR-like functions for the broadcast stream. It is against this background of real-time broadcasts that the system of D1 automatically switches back to the real-time bitstream, when the fast forward bitstream "exhausts the available data" (see page 3, line 6 to page 4, line 33).

Based on this understanding of D1, the board agrees with the examining division's reasoning that D1 established a clear link between the real-time (simultaneous) encoding of the trick play streams and the broadcast stream and the fact that the program was a real-time program (e.g. a live sports event). It was obvious that for any repeat showing of a program, the trick play streams did not need to be generated in real time, but could simply be retrieved from memory, as they were in the prior-art system disclosed in D1. Therefore, the skilled person would have considered generating the trick play streams for any other program than a live event (such as series, films, etc...) before the broadcast.

D1 describes that the system switches from the fast forward stream to the real-time bitstream, when the fast forward bitstream "exhausts the available data." For a pre-recorded film such as a series or a movie this point in time would naturally be the end of the film.

Hence, starting from D1 and being faced with the problem of how to provide improved trick play functionality for a broadcast program, the skilled person would have combined the teaching of D1 relating to a real-time broadcast program with that disclosed in its description of the background art to arrive at the claimed solution.

3.5 It follows that the subject-matter of claim 1 of the main request does not involve an inventive step.

3.6 The appellant argued that there was no provision in D1 for a seamless transition between a broadcast bitstream and a storage bitstream. Irrespective of whether this provision can be deduced from the wording of claim 1 of the main request, D1 discloses switching between a broadcast bitstream and a storage bitstream (see page 13, lines 1 to 17) and between two storage bitstreams (see page 13, lines 18 to 33). Moreover, synchronisation of bitstreams pertaining to a single viewing event when using "VCR-like controls" is considered an obvious user desire. Hence, it is obvious that such synchronisation has to be effected between a broadcast and a storage bitstream. There are no technical difficulties in implementing this synchronisation, and the application does not refer to any such difficulties. Indeed, the solution presented in the application is identical to the "frame number" option of D1 (see application, paragraphs [0163] and [0176] and D1, page 13, lines 22 to 29).

3.7 The appellant also argued that D1 taught limiting playback functions to the point reached in the real-time broadcast bitstream. A person skilled in the art would not be motivated to provide a viewer with the capability of viewing and/or performing playback controls in advance of a point reached in a currently broadcast program, because D1 did not envisage or suggest that such capability would be desirable or even possible.

As set out above, D1 establishes a clear link between the real-time encoding of trick play streams and a broadcast stream and the fact that the program was a real-time program (e.g. a live sports event). Hence, for non real-time programs there was at least no technical reason why the playback of trick play streams should be limited to the point reached in a currently broadcast program. Actually, for pre-recorded trick play streams the "end of file indicator" referred to in D1 (see page 14, lines 8 to 13) would only be encountered when the end of the program is reached.

It follows that the appellant's arguments did not convince the board.

Second to fourth auxiliary requests

4. The independent claims of the second to fourth auxiliary requests specify particular playback control functions such as fast forward, slow forward and skip.

4.1 The board agrees with the examining division, which stated that D1 disclosed a fast forward command and that the further choices of playback control commands were obvious alternatives (see point XIII above).

4.2 The appellant argued that the specification of these particular trick play functions emphasised the fact that the streaming version of the program could advance beyond the broadcast program. If applied to real-time programs as in D1, this required an ability to predict the future.

4.3 The reasoning above with respect to claim 1 of the main request was based on an interpretation which took this argumentation into account, i.e. it was assumed that the method supported trick play functionality which advanced ahead of the broadcast (see point 3.2 above). Hence, the arguments of the appellant have to be refuted for the same reasons as for claim 1 according to the main request.

4.4 As a result, the board finds that the subject-matter of claim 1 according to the second to fourth auxiliary requests lacks an inventive step (Article 56 EPC 1973).

Ninth auxiliary request

5. Claim 1 according to the ninth auxiliary request additionally specifies that the streaming version of the television program is provided starting at the time point in the broadcast television program at which the user requested to perform the playback control function.

5.1 As argued by the appellant, this functionality ensures a seamless switching between the broadcast program and the streaming version. The appellant also argued that D1 had no need to determine a time point at which the user requested to perform the playback control function. Instead, D1 could directly switch from the broadcast stream to the stored stream, while relying on the real-time coupling between them to ensure synchronisation as described in D1, page 13, lines 3 to 10.

5.2 Seamless switching is common practice for "VCR-like controls". D1, furthermore, relies on the same technical mechanism as the present application to ensure seamless switching between storage bitstreams (see point 3.6 above). It would therefore have been obvious to employ the same mechanism between non-real-time broadcasts and storage bitstreams.

5.3 Hence, the subject-matter of claim 1 according to the ninth auxiliary request lacks an inventive step (Article 56 EPC 1973).

Tenth auxiliary request

6. Claim 1 of the tenth auxiliary request explicitly specifies the step of "receiving and displaying portions of the streaming version in advance of the broadcast version in response to a user request to fast-forward playback of the program in advance of the broadcast version."

6.1 The reasoning with respect to claim 1 of the main request was based on an interpretation which assumed that the method supported trick play functionality which advanced ahead of the broadcast (see point 3.2 above). Hence, the feature cannot change the board's evaluation of inventive step with respect to the previous requests.

6.2 As a consequence, the subject-matter of claim 1 according to the tenth auxiliary request does not involve an inventive step (Article 56 EPC 1973).

Conclusion

7. It follows from the above that none of the appellant's requests is allowable.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation