Information
This decision is only available in German.
T 2402/16 09-06-2021
Download and more information:
METHOD AND APPARATUS FOR RECEIVING MULTICAST VIDEO USING A PLAYLIST
Main request, first auxiliary request, second auxiliary request - amendments - added subject-matter (yes)
Third auxiliary request - amendment after summons - cogent reasons (no)
I. The appeal is against the examining division's decision to refuse European patent application No. 11 791 723.7, published as international application WO 2012/074874 A1.
II. The decision under appeal was based, inter alia, on the ground that the subject-matter of claim 1 of the then main request and the then auxiliary request extended beyond the content of the application as filed (Article 123(2) EPC).
III. With the statement of grounds of appeal, the appellant filed amended claims of a main request and first and second auxiliary requests. The appellant indicated a basis in the application as filed for the claimed subject-matter and provided reasons as to why the claims of all requests met the requirements of Articles 54, 56 and 84 EPC.
IV. 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 in the 2020 version (RPBA 2020, OJ EPO 2019, A63). In this communication, the board expressed, inter alia, the preliminary opinion that claim 1 of all requests contained added subject-matter, contrary to the requirements of Article 123(2) EPC. In points 3.4, 3.6 and 3.7 of its communication the board raised three different added-matter objections. The second objection related only to claim 1 of the main request.
V. By letter dated 12 May 2021, the appellant requested that the oral proceedings be held by videoconference.
VI. On 9 June 2021, the board held oral proceedings by videoconference.
During the oral proceedings, the appellant filed amended claims according to a third auxiliary request.
The appellant's final requests were that the decision under appeal be set aside and a European patent be granted on the basis of the claims of the main request filed with the statement of grounds of appeal or, alternatively, on the basis of the claims of the first or the second auxiliary request filed with the statement of grounds of appeal, or on the basis of the claims of the third auxiliary request filed during the oral proceedings held before the board.
At the end of the oral proceedings, the Chair announced the board's decision.
VII. Claim 1 of the main request reads as follows:
"A method for operating a client device, comprising:
requesting a presentation playlist from a first server, wherein the playlist identifies a plurality of chunks to be combined to form a video stream;
receiving the playlist from the first server;
determining whether a second server that can generate a multicast stream of the presentation exists;
determining to receive the presentation by multicast, wherein the presentation may be received as either multicast or unicast;
sending a message to the second server to request an initiation of a multicast stream of the presentation from one or more multicast groups;
requesting to join one of the multicast groups to receive the presentation;
receiving the presentation via multicast;
locating boundaries of the chunks based on the playlist; and
reconstructing the video stream based on the chunk boundaries."
VIII. Claim 1 of the first auxiliary request reads as follows:
"A method for operating a client device, the method comprising the steps of:
requesting a presentation playlist from a first server;
receiving the playlist from the first server;
determining whether additional servers can provide a multicast stream of the presentation;
determining to receive the presentation by multicast based further on the received playlist, wherein the presentation may be received as either multicast or unicast;
sending a message to the additional servers to request an initiation of a multicast stream of the presentation from one or more of multicast groups;
determining channel conditions;
requesting to join the one or more multicast groups to receive the presentation at different resolutions based on the channel conditions;
receiving the presentation as chunks via multicast;
locating boundaries of the chunks based on the playlist; and
reconstructing the chunks of the video stream based on the chunk boundaries for each of the different resolutions."
IX. Claim 1 of the second auxiliary request reads as follows:
"A method for operating a client device, comprising:
requesting a presentation playlist from a first server, wherein the playlist identifies a plurality of chunks to be combined to form a video stream;
receiving the playlist from the first server;
based on the received playlist, determining that the video stream is live or scheduled;
responsive to determining that the video stream is live or scheduled, determining that a second server can provide a multicast stream of the presentation via a plurality of multicast groups, each multicast group having a modulation and encoding rate that is different from those of the other multicast groups;
determining to receive the presentation by multicast, wherein the presentation may be received as either multicast or unicast;
joining one of the multicast groups to receive the presentation;
determining channel conditions; and
joining a second multicast group to receive the presentation at a different modulation and encoding rate than that provided by the first multicast group, based on the channel conditions;
wherein receiving the presentation via multicast from the first and second groups comprises:
locating boundaries of the chunks based on the playlist;
reconstructing the video stream based on the chunk boundaries; and
performing a switch to the second multicast group from the first multicast group at one of the chunk boundaries."
X. Claim 1 of the third auxiliary request reads as follows (features added compared with claim 1 of the second auxiliary request are underlined and deleted features are [deleted: struck through]):
"A method for operating a client device, comprising:
requesting a presentation playlist from a first server, wherein the playlist identifies a plurality of chunks to be combined to form a video stream;
receiving the playlist from the first server;
based on the received playlist, determining that the video stream is live or scheduled;
responsive to determining that the video stream is live or scheduled, determining that a second server can provide a multicast stream of the presentation via a plurality of multicast groups, each multicast group having a modulation and encoding rate that is different from those of the other multicast groups, wherein the second server receives the presentation via unicast from the first server;
determining to receive the presentation by multicast, wherein the presentation may be received as either multicast or unicast;
joining one of the multicast groups to receive the presentation;
determining channel conditions; and
joining a second multicast group to receive the presentation at a different modulation and encoding rate than that provided by the first multicast group, based on the channel conditions;
wherein receiving the presentation via multicast from the first and second groups comprises:
locating boundaries of the chunks based on [deleted: the playlist] a chunk information message received with the presentation via multicast;
reconstructing the video stream based on the chunk boundaries; and
performing a switch to the second multicast group from the first multicast group at one of the chunk boundaries."
XI. The appellant's arguments relevant to the present decision may be summarised as follows:
Main request and first and second auxiliary requests
(a) The Adaptive Multicast Gateway Router (AMGR) acted as a server because it redistributed video chunks to clients using multicast transmission. The AMGR and its function were disclosed in the following passages:
- page 9, lines 7 to 10
- page 13, line 30 to page 14, line 16
(b) Claim 1 specified a method for operating a client device. From the perspective of the client device the "second server" could be any server capable of generating a multicast stream of the presentation. Its relationship with the first server was immaterial.
(c) According to the passage from page 22, line 19 to page 23, line 12 of the application as filed, a switch from unicast to multicast could occur in general and did not need to be based on channel conditions. Hence, the features "determining channel conditions" and "based on the channel conditions" of claim 1 were not essential and could be deleted.
(d) Claim 1 should not be construed as meaning that the client device itself uses the received playlist to locate chunk boundaries. Rather, it should be interpreted as meaning that the client device receives information about the chunk boundaries from the second server, this information being obtained by the second server on the basis of the playlist. The passages on page 25, lines 1 and 2, page 2, line 20 and page 5, lines 16 and 17 specified that additional information based on the playlist was needed to reconstruct the chunks from the multicast data, and provided a basis for this interpretation.
Third auxiliary request
(e) The third auxiliary request filed during the oral proceedings before the board was to be admitted because it addressed all outstanding objections. It was not until the oral proceedings that it became apparent that the appellant's arguments had not convinced the board that the higher-ranking requests complied with the requirements of Article 123(2) EPC.
1. The appeal is admissible.
2. Main request - added subject-matter (Article 123(2) EPC)
2.1 Claim 1 specifies a method for operating a client device comprising, inter alia, steps of "requesting a presentation playlist from a first server" and "determining whether a second server that can generate a multicast stream of the presentation exists".
The step of "determining whether a second server that can generate a multicast stream of the presentation exists" was added in the course of the examination proceedings.
2.1.1 As a basis for this amendment the appellant referred to page 9, lines 7 to 10 and page 13, line 30 to page 14, line 16 of the application as filed. The appellant argued that the cited passages disclosed an AMGR which acted as a server because it redistributed video chunks to clients using multicast transmission. Hence, this AMGR provided a basis for a second server that can generate a multicast stream of the presentation (see section XI(a) above).
2.1.2 The board acknowledges that the AMGR acts as a server. However, this "second server" is not just any server - it has a specific relationship with the "first server" specified in claim 1 (from which a presentation playlist is requested).
In particular, the AMGR obtains both the playlist (see description, page 14, lines 7 and 8: "The AMGR then requests the variant playlist to learn of the number of multicast gears that it will support") and the video chunks from the "first server" (see description, page 9, lines 7 and 8: "The AMGR implements the HLS protocol with the server to request and receive video chunks").
2.1.3 The appellant submitted that claim 1 specified a method for operating a client device. The appellant argued that from the perspective of the client device the "second server" could be any server capable of generating a multicast stream of the presentation. Its relationship with the first server was immaterial (see section XI(b) above).
2.1.4 The board is not convinced by this argument for the following reasons. The description (see page 14, lines 3 to 13) sets out how a client determines an entity which can generate a multicast stream of the presentation: "The request for multicast service (e.g. AVMS JOIN) is sent as a unique message from client 212 to its AMGR [...] The message is sent to a well-known multicast address that is handled by designated routers of an AVMS, such as the AMGR". Hence, the client specifically sends a message to a router such as an AMGR. The term router implies that the AMGR is not an independent server but obtains its data from another server. Hence, also from the perspective of a client device, the aim of the feature "determining whether a second server that can generate a multicast stream of the presentation exists" in claim 1 is not to find any server in general - it is to find a router having an additional server function. In other words, the aim is to find a "second server" having the specific relationship with a "first server" set out under point 2.1.2 above.
2.1.5 Hence, there is no basis in the application as filed for a general "second server" in claim 1.
2.2 The method defined in claim 1 of the main request further comprises the following steps:
"determining to receive the presentation by multicast, wherein the presentation may be received as either multicast or unicast [...]
requesting to join one of the multicast groups to receive the presentation".
The step of "determining channel conditions" and the expression "based on the channel conditions" - present in claim 1 as originally filed - were deleted in the course of examination proceedings.
2.2.1 As a basis for this generalisation the appellant referred to the passage from page 22, line 19 to page 23, line 12 of the application as filed. The appellant argued that according to this passage a switch from unicast to multicast could occur in general and did not need to be based on channel conditions. Hence, the features "determining channel conditions" and "based on the channel conditions" were not essential and could be deleted (see section XI(c) above).
2.2.2 The board is not convinced that the cited passage of the application as filed is a valid basis for the generalisation.
The deleted features considered together with the feature "requesting to join one of the multicast groups to receive the presentation" originally specified that the decision of which one of multiple multicast groups to join was based on the determined channel conditions.
The passage cited by the appellant states: "the first AMGR Client to request a particular program may be instructed to use unicast [...] Then as more AMGR Clients join the program, the AMGR may determine that it would be more efficient to switch to multicast mode, and an AVMS Mode message would be sent the AMGR Clients with an instruction to switch to multicast mode".
This passage thus states that a client is instructed to switch from unicast to multicast; it does not address the question of which specific multicast group to join once multicast is selected.
Therefore, this passage cannot be a valid basis for the generalisation of "requesting to join one of the multicast groups to receive the presentation" without this request being based on the determined channel conditions.
2.2.3 In summary, there is no basis in the application as filed for deleting the expressions "determining channel conditions" and "based on the channel conditions".
2.3 Claim 1 further comprises steps of "receiving the playlist from the first server" and "locating boundaries of the chunks based on the playlist". The latter step was added in the course of the examination proceedings.
2.3.1 According to the appellant, these steps should not be construed as meaning that the client device itself uses the received playlist to locate chunk boundaries. Rather, they should be interpreted as meaning that the client device receives information about the chunk boundaries from the second server, this information being obtained by the second server on the basis of the playlist (see section XI(d) above).
2.3.2 For the board, this interpretation of claim 1 is incorrect. The person skilled in the art reading the following features of claim 1:
- "A method of operating a client device",
- "receiving the playlist from the first server" and
- "locating boundaries of the chunks based on the playlist"
together would understand that the boundaries of the chunks are located by the client device itself on the basis of the playlist it received directly from the first server.
2.3.3 The appellant referred to page 25, lines 1 and 2, page 2, line 20 and page 5, lines 16 and 17. According to the appellant, these passages specified that additional information based on the playlist was needed to reconstruct the chunks from the multicast data.
2.3.4 The board agrees that additional information is needed to reconstruct at the client device the chunks from the data arriving via a multicast stream. However, according to the application as filed, this additional information is based not on the playlist obtained from the first server but on information embedded in the multicast data (see description, page 39, lines 20 to 23: "The step of identifying chunk information for the received presentation comprises receiving the multicast data, identifying chunk boundaries from chunk boundary information embedded in the multicast data, and reconstructing the chunk").
2.3.5 In view of the above, the board concludes that there is also no basis in the application as filed for the feature "locating boundaries of the chunks based on the playlist" in claim 1.
2.4 It follows from points 2.1.5, 2.2.3 and 2.3.5 above that claim 1 of the main request does not meet the requirements of Article 123(2) EPC.
3. First and second auxiliary requests - added subject-matter (Article 123(2) EPC)
3.1 Claim 1 of the first auxiliary request was amended to specify: "determining whether additional servers can provide a multicast stream of the presentation".
3.2 Claim 1 of the second auxiliary request was amended to specify: "determining that a second server can provide a multicast stream of the presentation".
3.3 Therefore, claim 1 of both the first and the second auxiliary request specifies at least one additional server or a second general server without indicating its relationship with the "first server".
3.4 Hence, the same objection under Article 123(2) EPC as raised under points 2.1 to 2.1.5 above applies.
The appellant has not submitted any further arguments in this respect.
3.5 Claim 1 of both the first and the second auxiliary request contains the same amendment - "locating boundaries of the chunks based on the playlist" - as claim 1 of the main request.
3.6 Hence, the same objection under Article 123(2) EPC as raised under points 2.3 to 2.3.5 above applies.
The appellant has not submitted any further arguments in this respect.
3.7 In view of the above, claim 1 of both the first and second auxiliary request does not meet the requirements of Article 123(2) EPC.
4. Third auxiliary request - admittance (Article 13(2) RPBA 2020)
4.1 The third auxiliary request was filed during the oral proceedings before the board, i.e. after the notification of the summons to oral proceedings. The third auxiliary request is therefore an amendment within the meaning of Article 13(2) RPBA 2020.
4.2 According to Article 13(2) RPBA 2020: "Any amendment to a party's appeal case made [...] after notification of a summons to oral proceedings shall, in principle, not be taken into account unless there are exceptional circumstances, which have been justified with cogent reasons by the party concerned."
4.3 The appellant argued that it went to the oral proceedings before the board believing that there was no added subject-matter in the claims of the main request and the first and second auxiliary requests. It was not until the hearing that it realised it had been unable to persuade the board in this respect. Although it was still convinced that there was no added subject-matter in the higher-ranking requests it filed the third auxiliary request during the oral proceedings for reasons of procedural efficiency (see section XI(e) above).
4.4 For the board these are not cogent reasons for waiting until the oral proceedings to file the third auxiliary request.
All objections under Article 123(2) EPC had been raised in the board's communication under Article 15(1) RPBA 2020. The first objection (see points 2.1 to 2.1.5 above) and second objection (see points 2.2 to 2.2.3 above) were already present in the decision under appeal.
Appellants should always plan for the eventuality that their arguments do not convince the board. Therefore, the fact that the arguments presented by the appellant during the oral proceedings did not convince the board cannot be considered to be exceptional circumstances justifying the filing of the third auxiliary request.
4.5 Hence, the board exercised its discretion under Article 13(2) RPBA 2020 and decided not to admit the third auxiliary request into the appeal proceedings.
5. Conclusion
The main request and the first and second auxiliary requests are not allowable because claim 1 of none of these requests meets the requirements of Article 123(2) EPC. The third auxiliary request was not admitted into the appeal proceedings. Since none of the appellant's requests is allowable, the appeal must be dismissed.
For these reasons it is decided that:
The appeal is dismissed.