T 1540/09 () of 3.5.2013

Summary of Facts and Submissions

I. The appeal is directed against the decision to refuse European patent application No. 99 909 877.5, published as international application WO 99/52279 A1.

II. The patent application was refused by the examining division on the grounds that claim 1 then on file did not comply with Articles 84 and 56 EPC.

III. The applicant appealed against this decision and submitted claims according to a main request and an auxiliary request with the statement of grounds of appeal.

IV. The board issued a communication annexed to a summons to oral proceedings indicating inter alia that in its preliminary opinion the amended claims according to both requests lacked clarity. With letter of 3 April 2013 the appellant submitted new claims of a main request and a first auxiliary request. In a further letter of 22 April 2013 the appellant presented arguments in support of both of these requests.

V. Oral proceedings were held before the board on 3 May 2013. At the end of the oral proceedings the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request or of the first auxiliary request, both filed with letter of 3 April 2013; alternatively, as a second or third auxiliary request, on the basis of the claims filed with the statement of grounds of appeal and designated as main request and auxiliary request, respectively.

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

"A method for providing pass through or capture of continuous linear streams of digital audio/video information represented in various formats while providing the appearance of locally stored streams, comprising the steps of:

copying blocks of data from said information streams to at least two media caches (10), wherein data in said at least two media caches can be viewed as a snapshot of said continuous streams of digital audio/video information;

providing, for each media cache of said at least two media caches, an associated current block indicator, each associated current block indicator adapted to select an associated portion of said each media cache, on said device, wherein said each associated current block indicator varies within said each media cache to select said associated portion of said each media cache that is to be accessed to provide playback functions including any of pause, rewind, fast forward, play, play faster, play slower, and play in reverse;

wherein said information streams are composed of a plurality of discrete blocks of data;

providing a stream clock (202) on said device for synchronizing said functions on said at least two media caches by generating time-based clock events;

wherein each media cache of said at least two media caches delivers a block of data pointed to by said each associated current block indicator to an associated decoder upon receipt of a clock event from said stream clock at a rate that is proper for a selected function for each stream of data delivered from said each media cache;

wherein said each media cache delivers blocks of data at delivery rates that are consistent with the selected function;

moving said each associated current block indicator in a direction consistent with the selected function through said each media cache by one block for each clock event received by said each associated media cache from said stream clock;

controlling a clock rate of said stream clock using a buffer controller (201) on said device;

wherein the proper rate at which said stream clock delivers clock events to said each media cache is based on a rate specified by said buffer controller; and

wherein said buffer controller requests said stream clock to adjust its clock rate according to the selected function."

VII. Claim 1 according to the first auxiliary request differs from claim 1 of the main request by the following additional feature inserted after the phrase "moving said each associated current block indicator ... for each clock event received by said each associated media cache from said stream clock;":

"designating one media cache of said at least two media caches as a key stream media cache;

synchronizing current block indicators of media caches of said at least two media caches other than said key stream media cache with a current block indicator of said key stream media cache;".

VIII. Claim 1 according to the second auxiliary request reads as follows:

"A method for providing pass through or capture of continuous linear streams of digital audio/video information represented in various formats while providing the appearance of locally stored streams, comprising the steps of:

providing on a device at least two media caches (10) for copying blocks of data from said information streams, wherein data in said at least two media caches can be viewed as a snapshot of said continuous streams of digital audio/video information;

providing, for each media cache of said at least two media caches, an associated current block indicator, each associated current block indicator adapted to select an associated portion of said each media cache, on said device, wherein said each associated current block indicator varies within said each media cache to select said associated portion of said each media cache that is to be accessed to provide playback functions including any of pause, rewind, fast forward, play, play faster, play slower, and play in reverse;

wherein said underlying information streams are composed of a plurality of discrete blocks of data;

providing a stream clock (202) on said device for synchronizing said functions on said at least two media caches by generating a time-based clock event, wherein multiple streams of data from said at least two media caches which must be presented in a synchronized fashion are correctly synchronized by said stream clock distributing clock events at a rate that is proper for each stream of data for a selected function, and wherein said multiple streams of data present their data at delivery rates that are consistent with the selected function;

wherein said each media cache delivers a block of data pointed to by said each associated current block indicator to an associated decoder upon receipt of a clock event from said stream clock;

wherein a reverse function is implemented by moving said each associated current block indicator backwards through said each media cache by one block for each clock event generated by said stream clock;

providing a buffer controller (201) on said device that is responsible for controlling a clock rate of said stream clock;

wherein the rate at which said stream clock delivers clock events to said at least two media caches is based on a rate specified by said buffer controller; and

wherein said buffer controller can speed up or slow down playback of a stream or an entire collection of streams by requesting said stream clock to adjust its clock rate."

IX. Claim 1 according to the third auxiliary request contains the following additional feature inserted after the feature "wherein said each media cache delivers ... upon receipt of a clock event from said stream clock;":

"wherein a forward function is implemented by moving said each associated current block indicator forward through said each media cache by one block for each clock event generated by said stream clock;".

X. The appellant's arguments with respect to clarity of claim 1 according to the main request may be summarised as follows:

The essential idea of the invention as claimed was not the synchronisation of the different streams, but the provision of a single stream clock that supplied clock events to each linear cache (LC). The number of events per time unit generated by the stream clock could be modified using a rate multiplier, which allowed convenient implementation of different playback functions such as reverse and fast forward (see present description, page 12, second and last paragraphs). The meaning of the expressions "at a rate that is proper for a selected function" and "delivery rates that are consistent with the selected function" was clear for the skilled person, given that the playback functions required a certain data delivery rate.

Events were generated independently for each linear cache (see page 9, last paragraph). For each clock event received by the associated LC, the current block indicator of that LC was moved by one block. The rate at which the stream clock needed to send out clock events was determined by the data requirements of the respective playback function and the block size of the data stored in the LCs (see letter of 22 April 2013, section 2).

According to the invention the presentation time stamps (PTS) of the application were "not related to any time stamps defined by the underlying stream encoding technique except that once the LC begins operation, there is a constant offset between the PTS stored in the LC and any time stamps stored within the encoded digital blocks" (page 10, first paragraph). This phrase should be understood to mean that the PTS of the application as compared to those defined in the MPEG-2 standard have a constant offset "to the extent that the constant offset ... could be seen as a relationship between the PTS of the present invention and time stamps defined by the underlying stream encoding technique" (see letter of 22 April 2013, section 2).

The appellant did not provide separate arguments with respect to the clarity of claim 1 of each of the auxiliary requests.

Reasons for the Decision

1. The appeal is admissible.

2. The application relates to a method and an apparatus for buffering (passing through) or capturing continuous linear streams of audio/video information. Its purpose is to provide "the illusion for the consumer that recent portions of the stream are stored locally in some manner, such that typical VCR-like functions can be performed on the stream, e.g. pause, rewind, and fast forward." The invention should also support the ability to capture portions of the data stream. Multiple streams may have to be handled in parallel, which requires that "the blocks of each stream must be decoded at appropriate times for the compression methods involved and synchronized with the presentation of all other streams" (see page 1, penultimate paragraph; page 2, second paragraph; page 3, third paragraph; page 4, second paragraph, and pages 5 and 6: "Summary of the invention").

In order to satisfy these requirements the application proposes an architecture consisting of a buffer controller, a stream clock, several linear caches and a clip capture device (see figure 2). Each linear cache is employed to buffer one continuous stream of data which is segmented into data blocks. A current block indicator points at the actual playback position in a corresponding linear cache. The stream clock schedules a sequence of timer events for the linear caches so as to trigger forwarding of blocks, indicated by their respective current block indicators, to the decoding process. Timer events are scheduled "at the proper rate for that LC" so that the LCs "present their data at consistent delivery rates" for the selected functions. Capturing of a part of the buffered data stream may be achieved using the clip capture device. The buffer controller provides a user interface receiving commands to initiate clip capture operations or commands regarding playback functions such as fast forward, reverse, etc. The playback speed may be modified via a clock rate output from the buffer controller to the stream clock, whereby "A rate multiplier greater than one results in faster playback of the stream, while a multiplier of less than one results in a slower playback of the stream." Thus, by manipulating the clock rate provided to the stream clock, the buffer controller "can speed up or slow down the playback of the entire collection of streams" (see page 7; page 8, second to fourth paragraph; page 9, second and last paragraph; page 11, first paragraph, and page 12, second and last paragraph).

3. Main request

3.1 According to Article 84 EPC 1973, the claims shall define the matter for which protection is sought. They shall be clear and concise and be supported by the description.

3.2 Independent claim 1 specifies the following feature:

"providing a stream clock (202) on said device for synchronizing said functions on said at least two media caches by generating time-based clock events".

This feature is a functional feature. It is established jurisprudence of the boards of appeal that such features may be permissible in a claim if they provide instructions which are sufficiently clear for the expert to reduce them to practice without undue burden (see Case Law of the Boards of Appeal of the European Patent Office, 6th edition, 2010, section II.B.1.2.2).

3.3 According to the description, the stream clock "provides a central synchronization facility that distributes time-based events to a number of LCs", the apparatus being "independent of the format of the underlying digital data stream". "The Stream Clock uses a single queue for managing events to be distributed using standard, prior art techniques that are familiar to those skilled in the art of building time-based software systems" (see page 8, fourth and fifth paragraph and page 6, penultimate paragraph).

These passages and, in particular, the chapter relating to the "Stream Clock" (see pages 8 and 9) provide information on how synchronisation is maintained on the basis of a single queue of events. However, there is no information in these passages as to how this queue of clock events is determined in order to synchronise the linear caches. It is also not apparent from which source the information concerning relative ordering of clock events could be extracted for the general case of an apparatus which is independent of the format of the underlying data stream.

3.4 The application provides the further information that each block within the stream is marked with a presentation time stamp. It is known in the art that according to the MPEG-2 transport protocol, embedded presentation time stamps may be employed for synchronisation of different streams. The application specifies that a presentation time stamp (PTS) indicates "when that block should be presented to the decoding process, be it hardware or software. The PTS is a monotonically increasing value initialized to zero when the LC first begins operation on a stream, and is not related to any time stamps defined by the underlying stream encoding technique except that once the LC begins operation, there is a constant offset between the PTS stored in the LC and any time stamps stored within the encoded digital blocks" (see page 10, first paragraph). The board concludes from this passage that the PTS of the present application differ from those of the "underlying stream encoding technique". The exact relationship between these time stamps, in particular how they can be unrelated and at the same time have "a constant offset" "once the LC begins operation", is not clear. Hence, it is not clear how the PTS according to the present application can be employed to establish a single queue of events and ultimately how to achieve synchronisation of playback functions on the media caches.

3.5 In addition, the board infers from the passage from page 11, third paragraph, to the bottom of that page that the buffer controller - and not the stream clock - is involved in the initial positioning, and hence in the synchronisation of the different streams. However, this passage also fails to provide information as to how the single queue of events is determined to ensure proper synchronisation of streams.

3.6 In view of the above, the board considers that the description also fails to give general guidance as to how time-based clock events should be generated for a proper synchronisation of blocks of data of different format. Therefore the feature of providing a stream clock does not contain sufficiently clear instructions as to how this feature has to be reduced to practice.

3.7 The appellant's arguments did not convince the board. In particular, the appellant argued that the PTS of the application as compared to those defined in the MPEG-2 standard have a constant offset "to the extent that the constant offset ... could be seen as a relationship between the PTS of the present invention and time stamps defined by the underlying stream encoding technique" (see point X above). However, this does not explain how the time-based clock events are generated to establish a single queue of events. The appellant also argued that the rate at which the stream clock needed to send out clock events was determined by the data requirements of the respective playback function and the block size of the data stored in the LCs. However, this argument relates to the variation of the clock events; it does not explain how the clock events are generated and a queue is determined in the first place. Moreover, as specified in the description (see first paragraph on page 4), block data sizes may vary in an unpredictable way.

3.8 The board therefore concludes that the feature of providing a stream clock for synchronising the playback functions on at least two media caches by generating time-based clock events is not clear.

3.9 It follows from the above that claim 1 of the appellant's main request does not meet the requirements of Article 84 EPC 1973.

4. Further requests

4.1 Claim 1 of the first auxiliary request contains the same unclear feature as claim 1 of the main request. The appellant has not submitted arguments as to how the additional feature of designating a key stream media cache gives clear instructions as to how the time-based clock events have to be generated. Although this may further specify how different streams are aligned (see for instance page 8, first paragraph), the board cannot see how this feature clarifies the generation of time-based clock events in general. Claim 1 therefore also lacks clarity for the same reasons as claim 1 of the main request.

4.2 Claim 1 of both the second and third auxiliary requests contains the following feature:

"providing a stream clock (202) on said device for synchronizing said functions on said at least two media caches by generating a time-based clock event".

This feature is identical to the unclear feature of claim 1 according to the main request, except for the use of the singular for the clock events in the expression "a time-based clock event". Self-evidently, this difference does not clarify how synchronisation is achieved. The additional features relating to a reverse function (second auxiliary request) and both a reverse and forward function (third auxiliary request) relate to the different aspect of how the rate of the clock events is varied for different playback functions. Hence, claim 1 according to both the second and third auxiliary requests also lacks clarity.

5. 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.