T 1288/15 () of 16.6.2020

Summary of Facts and Submissions

I. The appeal is against the decision to refuse European patent application No. 10 713 450.4, published as international application WO 2010/118995 A1.

II. The examining division refused the patent application with a decision according to the state of the file referring to the reasons given in its communications dated 28 May 2013, 12 December 2013 and 11 June 2014.

III. In the first and the last of these communications, the examining division cited the following document:

D2:|WO 2008/017973 A2|

IV. The reason given by the examining division in the latter communication was that the subject-matter of all the claims of the sole request then on file was not new (Article 54(1) EPC) in view of the disclosure of document D2.

V. The applicant ("appellant") filed notice of appeal. With the statement of grounds of appeal, it filed claims 1 to 12 corresponding to the claims of the sole request underlying the impugned decision, except for the correction of an obvious error in claim 12. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of these claims. The appellant indicated why, in its view, the subject-matter of the claims was new over the disclosure of document D2.

VI. The board issued a summons to oral proceedings dated 17 December 2019. In a communication under Article 15(1) RPBA 2007 (Rules of Procedure of the Boards of Appeal in the version of 2007, OJ EPO 2007, 536), the board gave its provisional opinion that:

(a) the subject-matter of independent claims 1, 6, 10 to 12 and dependent claims 2, 3, 5, 8 lacked inventive step (Article 56 EPC) in view of the disclosure of D2 combined with the common general knowledge of the person skilled in the art

(b) dependent claims 4 and 7 contained subject-matter which extended beyond the content of the application as filed (Article 123(2) EPC)

As evidence of the common general knowledge of the person skilled in the art, the board cited, inter alia, the following document:

D8:|INSAM, Edward. TCP/IP Embedded Internet Applications. Elsevier Science & Technology, 4 September 2003, ISBN 0-7506-57359, XP040425964 |

Chapters 7 and 8 (pages 171-242) of D8 were annexed to the board's communication.

VII. By letter dated 13 May 2020, the appellant filed amended claims of a main request, a first auxiliary request and a second auxiliary request. It provided arguments as to why the subject-matter of the amended claims of the requests involved an inventive step.

VIII. On 16 June 2020, oral proceedings were held before the board.

The appellant's final requests were that the decision under appeal be set aside and that a European patent be granted on the basis of the claims of the main request or, in the alternative, the first auxiliary request or the second auxiliary request, all requests filed by letter dated 13 May 2020.

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

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

"Receiver for a text-information signal carrying text-based information content being distributed to information objects (14), comprising:

a transport-layer unit (110) for receiving a transport signal (92) so as to obtain a sequence of transport units;

an application-layer unit (112) comprising: an extractor (114) for inspecting each transport unit and extracting a fragment header (84a) and a corresponding fragment section (14a) therefrom so as to obtain a sequence of fragment sections with associated fragment headers; a de-fragmenter (116) for de-fragmenting the sequence of fragment sections (14a) by use of the fragment headers (84a) to obtain the information objects (14) with, at least for a part of the information objects (14), composing the respective information object (14) from a sub-sequence of fragment sections (14a) of the sequence of fragment sections; and an information object handler (118) for parsing the information object to obtain an object header (16) and an object content section (18) and processing the information objects according to the object header (16),

wherein the transport signal (92) has each transport unit contained therein in a packetized form distributed onto one or more than one transport packet, each transport packet comprising a transport packet header and a transport packet data section, wherein the transport-layer unit (110) is configured to inspect, for each transport packet, the transport packet header in order to obtain a payload extraction information on a length of the transport content section or on a payload portion within the transport packet section and to extract and forward, by use of the payload extraction information, merely bits of the transport packet to the application-level unit (112), which concern at least one of the fragment header and the fragment section,

wherein the fragment headers (84a) associated with the sequence of the fragment sections (14a) are configured such

that the fragment headers reveal as to whether the associated fragment section is the first fragment section of a sub-sequence of fragment sections into which an information object is fragmented;

the fragment headers reveal as to whether the associated fragment section is the last fragment section of a sub-sequence of fragment sections into which an information object is fragmented; and

the fragment headers of a sub-sequence of fragment sections into which an information object is fragmented have a continuity index continuously changing from the first to the last fragment section of the sub-sequence of fragment sections,

wherein the de-fragmenter is configured to perform the de-fragmentation by checking, solely based on the fragment headers, as to whether the fragment sections completely reconstruct the information object which is fragmented into the sub-sequence of fragment sections or as to whether a fragment section of the sub-sequence of fragment sections is missing."

X. Claim 1 of the first auxiliary request was constructed by appending the following features to the features of claim 1 of the main request:

"wherein the de-fragmenter is configured to perform the de-fragmentation by

a) checking the fragment header with which a current fragment section is associated as to whether the current fragment section is the first fragment section of a sub-sequence of fragment sections,

b) if so, check the fragment header of the current fragment section and the fragment headers associated with a run of fragment sections immediately following the current fragment section and ending at the fragment section immediately preceding a fragment section having a fragment header associated therewith which indicates that its fragment section is the first fragment section of a sub-sequence of fragment sections, or at a fragment section that has a fragment header associated therewith that indicates that its fragment section is the last fragment section of a sub-sequence of fragment sections, whatever occurs first in the sequence of fragment sections, as to whether there is a discontinuity in the continuity index of these fragment headers;

c) if there is a discontinuity in the continuity index of these fragment headers or if the run ends at a fragment section that has a fragment header associated therewith that does not indicate that its fragment section is the last fragment section of a sub-sequence of fragment sections, discarding the current fragment section on the run of fragment sections and resuming the de-frequentation (read: de-fragmentation) at step a) with the fragment section immediately following the run of fragment sections as the current fragment section; and

d) otherwise, composing the information object from the current fragment section and the run of fragment sections."

XI. Claim 1 of second auxiliary request was constructed by appending the following features to the features of claim 1 of the first auxiliary request:

"wherein the fragment headers (84a) associated with the sequence of the fragment sections (14a) are configured such that, for each information, object,

the continuity index continuously changes from the first to the last fragment section of the sub-sequence of fragment sections with starting from zero at the first fragment section of the sub-sequence of fragment sections."

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

The "RTP Header", the "Common Payload Header", the "FU Header" and the "Fragment Header" disclosed in document D2 (Figure 5b) must be seen as originating from separate processing layers which, when considered together, cannot be viewed as part of an "application layer" within the meaning of the present patent application. The present patent application does not foresee the distribution of a "first flag", a "last flag" and a "continuity index" over multiple headers. The creation of an RTP header cannot be considered as part of the application layer since it is disconnected from the content generated by the application.

XIII. At the oral proceedings, taking into consideration the conclusion drawn by the board within the context of the main request - namely that the "RTP Header", the "Common Payload Header", the "FU Header" and the "Fragment Header" disclosed in document D2 (Figure 5b) were to be considered as part of an "application layer" within the meaning of the present patent application - the appellant stated that it did not wish to discuss claim 1 of the first auxiliary request because this claim had the same problem as claim 1 of the main request as far as inventive step was concerned.

XIV. The appellant's arguments with respect to claim 1 of the second auxiliary request may be summarised as follows.

Starting the continuity index from zero at the beginning of each information object may increase the probability of detecting a missing fragment for sequences of information objects whose lengths exhibit special properties.

Document D2 teaches to continuously increase the continuity index (or "sequence number") in successive RTP headers irrespective of whether they come from the same or different information objects. Since the creation of an RTP header is disconnected from the application layer, a person skilled in the art would not have modified this numbering approach.

Reasons for the Decision

1. The appeal is admissible

2. The invention

2.1 The present patent application relates to the transmission of text-based information content distributed to information objects. The description as filed gives the example of selectable menu objects (page 1, third paragraph, last sentence; page 4, line 11, to page 9, line 12; Figures 1a and 1b) to be displayed, for example, on a digital radio (page 13, lines 10 and 11).

2.2 The creation of objects is usually considered part of a conceptual layer called the "application layer".

2.3 The transmission of objects requires the use of a transport protocol specifying the syntax of a transport packet. The creation of transport packets is usually considered part of a conceptual layer called the "transport layer".

Each transport protocol defines a maximum size for the payload of a transport packet. If an object to be transmitted is larger than this maximum size, it must be fragmented.

2.4 The present patent application proposes fragmenting an information object at the application layer rather than at the transport layer so that any transport protocol may be used (page 3, third paragraph, and page 12, line 27, to page 13, line 11).

By fragmenting at the application layer, it becomes possible to add information in a fragment header which can help the receiver identify whether all the fragments of an information object have been received (paragraph bridging pages 14 and 15). This information may comprise syntax elements indicating whether a fragment is the first fragment of an information object ("first flag"), whether a fragment is the last fragment of an information object ("last flag"), and the position of a fragment within an object ("continuity index") (see last paragraph of page 11 and first paragraph of page 12).

2.5 Claim 1 of all requests is directed to a receiver.

Claim 1 of the main request essentially defines two levels of encapsulation for a fragment section of an information object: a first level associated to an "application-layer unit" in which a fragment header containing the above-mentioned syntax elements is appended to the fragment section; and a second level associated to a "transport-layer unit" in which the pair of a fragment header and a fragment section (called a "transport unit" in the claims) is packetised into one or more transport packet(s) each having a packet header containing information on the length of the transport content section. The syntax elements in the fragment headers are used to detect whether an information object can be completely reconstructed or whether a fragment section is missing.

Claim 1 of the first auxiliary request further defines how, concretely, the syntax elements in the fragment headers are used to identify a missing fragment. If a missing fragment is identified, the information object is not recomposed.

Claim 1 of the second auxiliary request further specifies that the continuity index starts from zero at the first fragment of each information object.

3. Main request: inventive step (Article 56 EPC)

3.1 According to Article 56 EPC, an invention is to be considered as involving an inventive step if, having regard to the state of the art, it is not obvious to a person skilled in the art.

3.2 It has not been contested by the appellant that document D2 can be considered as the closest state of the art in the context of the established "problem and solution approach" for the assessment of whether an invention involves an inventive step (Case Law of the Boards of Appeal of the European Patent Office ("Case Law"), 9th edition 2019, I.D.2).

3.3 Disclosure of document D2

3.3.1 Document D2 discloses a receiver (paragraph [0076], first sentence) for a text-information signal carrying text-based information content being distributed as information objects.

D2 indeed relates to the fragmentation of XML documents (see Figure 2). An XML document is referred to as a "content sample" (see paragraph [0049]) and can be considered an "information object" within the meaning of the patent application. Figure 4 shows a plurality of content samples.

3.3.2 The receiver of D2 comprises a transport-layer unit for receiving a transport signal to obtain a sequence of transport units.

D2 is indeed concerned with the same problem as the current application, namely that a text-based "information object" may be larger than a maximum transport unit size (see paragraph [0011]). The proposed solution involves fragmenting XML "into fragments that fit a transport packet size" (see paragraph [0010]). The RTP packet shown in Figure 5b represents a "transport unit".

3.3.3 The receiver of D2 also comprises an application-layer unit (paragraph [0012]: "Application-layer fragmentation") comprising:

(a) an extractor for inspecting each transport unit and extracting a fragment header and a corresponding fragment section to obtain a sequence of fragment sections with associated fragment headers. Indeed, the "RTP Header", the "Common Payload Header", the "FU Header" and the "Fragment Header" shown in Figure 5b form, together, a "fragment header" and the "Sample (Payload)" shown in Figure 5b represents a "fragment section". These pieces of information are necessarily extracted from a transport packet at the receiver

(b) a de-fragmenter for de-fragmenting the sequence of fragment sections by use of the fragment headers to obtain the information objects with, at least for a part of the information objects, composing the respective information object from a sub-sequence of fragment sections of the sequence of fragment sections (see paragraph [0049]: "enables a receiver to reassemble the content sample from its fragments when all fragments are received")

(c) an information object handler for parsing the information object to obtain an object header and an object content section and processing the information objects according to the object header (see e.g. Figure 8, the elements "<!xml version [..] ?>" and "<!DOCTYPE [..]>" represent "header" information; the rest represents "content" information)

3.3.4 Additionally, in D2, in an option called "Option 0" (paragraph [0052]), the fragment headers associated with the sequence of the fragment sections are configured such that the fragment headers reveal whether the associated fragment section is the first fragment section of a sub-sequence of fragment sections into which an information object is fragmented (see "Option 0" in Table 1, paragraph [0052]: "Start flag") and whether the associated fragment section is the last fragment section of a sub-sequence of fragment sections into which an information object is fragmented (see "Option 0" in Table 1, paragraph [0052]: "End flag").

3.3.5 The fragment headers of a sub-sequence of fragment sections, into which an information object is fragmented, also have a continuity index continuously changing from the first to the last fragment section of the sub-sequence of fragment sections. The "RTP Header" indeed comprises a syntax element called "sequence number" satisfying this property (see Figure 5a and paragraph [0054]).

3.3.6 The de-fragmenter of D2 is further configured to perform the de-fragmentation by checking, solely based on the fragment headers, whether the fragment sections completely reconstruct the information object which is fragmented into the sub-sequence of fragment sections or whether a fragment section of the sub-sequence of fragment sections is missing.

Indeed, in document D2, missing packets are "solely" detected based on the sequence numbers and the syntax elements of the fragment header (see paragraphs [0051] to [0054]).

3.3.7 The board has not been convinced by the appellant's argument that the "RTP Header", the "Common Payload Header", the "FU Header" and the "Fragment Header" disclosed in document D2 could not be considered part of an application layer within the meaning of the patent application.

At the oral proceedings, the appellant could not identify any feature in the patent application as filed which excluded that the application layer comprised separate conceptual layers.

The appellant could also not provide any reasons for not giving the expression "application layer" the meaning and scope it normally has in the field of data transmission.

Document D8 is a textbook on data transmission. The RTP protocol is presented in Chapter 8. This chapter is entitled "Application Layer Protocols" (pages 233 to 236). The RTP protocol is therefore recognised in the field of data transmission as being part of the application layer. The creation of an RTP header - and, consequently, any header encapsulated within an RTP packet - is therefore to be associated to an "application-layer unit" within the meaning of the patent application.

3.4 Distinguishing features

3.4.1 In view of the above, the board comes to the conclusion that the receiver defined in claim 1 solely differs from the receiver disclosed in document D2 in that the transport signal contains each transport unit in a packetised form distributed into one or more than one transport packet(s), each transport packet comprising a transport packet header and a transport packet data section and in that the transport-layer unit is configured to inspect, for each transport packet, the transport packet header to obtain payload extraction information on a length of the transport content section or a payload portion within the transport packet section and to extract and forward, by use of the payload extraction information, merely bits of the transport packet to the application-level unit, which concern at least one of the fragment header and the fragment section ("Features (a)").

3.5 Assessment of inventive step

3.5.1 Features (a) have the technical effect that a transport unit is distributed to one or more transport packet(s), a transport packet having a header comprising information on a length of the transport content section or a payload portion within the transport packet section.

3.5.2 In its statement of grounds of appeal, the appellant indicated that the "idea of the present invention is to render such a text-based information object transmission scheme capable of accommodating a broad variety of downlink paths" (page 2, point 4).

The board interprets this argument in light of the passage of the description from page 2, line 7, to page 3, line 4, to mean that, in the appellant's view, the claimed invention enables to generate fragments, at a given ("application"-) layer, having a size smaller than a size supported by a (any) higher ("transport"-) layer.

The board has not been convinced that this effect is actually achieved by the claim because the claim does not indicate how an information object is fragmented and thus does not ensure that the generated fragments will be of a size smaller than the size supported by a (any) higher ("transport"-) layer.

The only technical effect that can be acknowledged by the board is therefore the one identified in point 3.5.1.

3.5.3 In view of this effect, the board formulates the objective technical problem to solve starting from D2 as how to transport the RTP packets from the transmitter to the receiver.

3.5.4 The following features are part of the common general knowledge of the person skilled in the art:

(a) The RTP protocol is typically used on top of the UDP protocol (see document D8, page 234, line 15: "they are mostly used on top of UDP" and line 38: "The format is carried as a UDP payload").

(b) A UDP packet has a header comprising, inter alia, information about its total length, and hence about the length of its payload (see document D8, page 187, Figures 7-10: "16-bit UDP total length").

3.5.5 The person skilled in the art starting from D2, and faced with the problem of how to transport the RTP packets from the transmitter to the receiver, would therefore have encapsulated an RTP packet into a UDP packet. By doing so, the skilled person would have arrived at a transport signal containing each transport unit (i.e. each RTP packet) in a packetised form distributed into one or more than one transport packet(s), each transport packet comprising a transport packet header and a transport packet data section (document D8, page 187, Figures 7-10), the transport packet header having payload extraction information on a length of the transport content section or a payload portion within the transport packet section (document D8, page 187, Figures 7-10: "16-bit UDP total length").

The receiver of D2 receiving such transport packets would thus necessarily have to extract and forward, by use of the payload extraction information, merely bits of the transport packet to the application-level unit which concern at least one of the fragment header and the fragment section (i.e. the "Data" part of the UDP packet which would "merely" contain information concerning an RTP packet, i.e. the "RTP Header", the "Common Payload Header", the "FU Header", the "Fragment Header" and the "Sample (Payload)").

3.5.6 The board notes that the background part of document D2 (paragraphs [0002] to [0017]) focuses on IP based streaming applications (see paragraphs [0004], [0011] and [0012]). The invention described in D2 has thus been developed in the framework of a transport system based on the IP protocol. This would have been an incentive for the skilled person to apply the protocols typically used in such transport systems which are the focus of document D8.

3.6 In view of the above, the board has come to the conclusion that the subject-matter of claim 1 lacks inventive step within the meaning of Article 56 EPC because it would have been obvious to the person skilled in the art having regard to the disclosure of D2 and their common general knowledge as evidenced by document D8.

4. First auxiliary request: admission into the proceedings (Article 13(1) RPBA 2007)

4.1 According to Article 25(3) of the revised version of the Rules of Procedure of the Boards of Appeal (RPBA 2020, OJ EPO 2019, A63), where the summons to oral proceedings has been notified before its date of entry into force (i.e. 1 January 2020, see Article 24(1) RPBA 2020), Article 13(2) RPBA 2020 does not apply. Instead, Article 13 RPBA 2007 continues to apply.

4.2 Under Article 13(1) RPBA 2007, any amendment to a party's case after it has filed its grounds of appeal or reply may be admitted and considered at the board's discretion. The discretion is exercised in view of, inter alia, the complexity of the new subject-matter submitted, the current state of the proceedings and the need for procedural economy.

4.3 At the oral proceedings, taking into consideration the conclusion drawn by the board within the context of the main request - namely that the "RTP Header", the "Common Payload Header", the "FU Header" and the "Fragment Header" disclosed in document D2 (Figure 5b) were to be considered part of an "application layer" within the meaning of the patent application - the appellant stated that it did not wish to discuss claim 1 of the first auxiliary request because this claim had the same problem as claim 1 of the main request as far as inventive step was concerned.

4.4 In the oral proceedings, the board considered that it would be against procedural economy to examine a request which, according to the appellant itself, did not overcome the issues raised with respect of a higher-ranking request. It therefore exercised its discretion under Article 13(1) RPBA 2007 and decided not to admit the first auxiliary request into the proceedings.

5. Second auxiliary request: inventive step (Article 56 EPC).

5.1 Distinguishing features

5.1.1 In points 3.3.4 and 3.3.5, the board came to the conclusion that in document D2, in the option called "Option 0" (paragraph [0052]), the fragment header contained (i) an indication of whether its associated fragment section was the first fragment section of a sub-sequence of fragment sections into which an information object is fragmented, (ii) an indication of whether its associated fragment section was the last fragment section of a sub-sequence of fragment sections into which an information object is fragmented and (iii) a continuity index.

5.1.2 It is clear that the "Start flag" and the "End flag" of "Option 0" are used to identify, at the receiver, the set of fragment sections that makes up a content sample in view of its re-composition (paragraph [0049]: "the syntax enables a receiver to reassemble the content sample from its fragments when all fragments are received"). It is therefore implicit that the de-fragmenter of the receiver disclosed in document D2 is configured to perform the de-fragmentation by:

(a) checking the fragment header with which a current fragment section is associated as to whether the current fragment section is the first fragment section of a sub-sequence of fragment sections

(b) if so, checking the fragment header of the current fragment section and the fragment headers associated with a run of fragment sections immediately following the current fragment section and ending at a fragment section that has an associated fragment header that indicates that its fragment section is the last fragment section of a sub-sequence of fragment sections

(c) composing the information object from the current fragment section and the run of fragment sections

5.1.3 However, document D2 does not disclose:

(a) Features (a) (see above point 3.4.1)

(b) discarding the current fragment section if there is a discontinuity in the continuity index of the fragment headers in the analysed run of fragment sections or if the run ends at a fragment section that has an associated fragment header that does not indicate that its fragment section is the last fragment section of a sub-sequence of fragment sections, and resuming with the fragment section immediately following the run of fragment sections as the current fragment section ("Features (b)")

(c) for each information object, starting the continuity index from zero at the first fragment section of the sub-sequence of fragment sections ("Features (c)")

5.2 Technical effects

5.2.1 Features (a) have the technical effect that a transport unit is distributed into one or more transport packet(s), a transport packet having a header comprising information on a length of the transport content section or a payload portion within the transport packet section (see points 3.5.1 and 3.5.2).

5.2.2 In its letter dated 13 May 2020 (page 3, point 13), the appellant submitted that, compared to "Option 0" of document D2 (Table 1 on page 13), Features (b) made "less likely [a] further process[ing] [of] error-effected fragmented transport units".

This merely reflects the primary effect of Features (b), namely, that a run of fragments is not processed if it has a missing fragment or, in other words, that an information object is not reconstructed if one of its fragments is not received.

This is in contrast with document D2 which focuses on error recovery and error concealment (paragraphs [0013], [0049] to [0054]).

Discarding a run of fragments when some fragments are missing is simpler than recovering or concealing the missing fragments.

5.2.3 With respect to Features (c), the board has not been convinced by the appellant's statement that re-starting the continuity index at the beginning of each information object increases the probability of detecting a missing fragment for sequences of information objects with lengths exhibiting special properties. The appellant was not able to give an example of circumstances under which the probability of detecting a missing fragment was increased. The board came to the conclusion that if these circumstances were not self-evident to the person skilled in the art, then the alleged effect could not be considered as a credible technical effect. The search for the "special properties" under which a detection of missing fragments is improved is considered as a technical problem on its own not addressed by the patent application.

The board has also not been convinced that re-starting the continuity index at zero at the beginning of each information object ensures that a lower number of bits is used for the continuity index (see point 17 on page 4 of the appellant's letter dated 13 May 2020). According to Figure 8-3 on page 235 of document D8, 16 bits are used to represent a sequence number in an RTP header. Claim 1 does not contain any feature that limits the number of fragments in an information object or the number of bits needed to represent the continuity index. Claim 1 does therefore not contain any feature that ensures that fewer than 16 bits are required for representing the continuity index.

The board therefore comes to the conclusion that Features (c) merely represent an alternative way of numbering a sequence of fragments coming from different information objects.

5.2.4 The appellant did not identify any effect achieved by Features (a), Features (b) and Features (c) that goes over and above the sum of their respective individual effects. The board cannot find such effects either.

5.3 Assessment of inventive step

5.3.1 It is established case law that if the features or sets of features of a claim are a mere aggregation of these features or sets of features which are not functionally interdependent, i.e. do not mutually influence each other to achieve a technical success over and above the sum of their respective individual effects, it is to be established whether each set of features is separately obvious in the light of the prior art (see Case Law, 9th edition 2019, I.D.9.2.2).

5.3.2 Features (a) are obvious in the context of claim 1 for the reasons given in point 3.5.

5.3.3 The objective technical problem solved by Features (b) can be formulated as how to find an alternative, simpler, way of dealing with lost packets.

Giving up a task whenever a problem arises is, for any person, an obvious way of dealing with the problem. Discarding an information object when a fragment of this information object is not received is therefore an obvious alternative way of dealing with the problem of missing fragments in the context of the transmission scheme disclosed in document D2. To implement this obvious solution, the person skilled in the art would have had to find a manner of detecting whether (at least) one of the fragments constituting an information object had not been received. Such a detection can be easily implemented in any of "Option 0", "Option 1" and "Option 2" of document D2 (Table 1 on page 13) since, on the one hand, the syntax elements included in the "Fragment Header" in each of these options enable identifying the borders of a content sample and, on the other hand, the sequence number present in the RTP header enables detecting a missing packet within these borders (paragraph [0054], lines 5 to 7).

In point 14 of its letter dated 13 May 2020, the appellant submitted that the person skilled in the art would have been encouraged by document D2 to use "Option 2" which, according to Table 1 on page 13, "helps the receiver in error recovery".

The board notes that claim 1 does not contain any feature directed to error recovery, hence this effect cannot be taken into account when assessing the presence of an inventive step. Moreover, the fact that, according to D2, only "Option 2" helps in error recovery would not have deterred the person skilled in the art from considering other viable options for detecting missing fragment(s) within an information object. If pursuing the obvious option of discarding the information object if a fragment of this information object is not received, "Option 0" in D2 is a viable option even though it does not help in error recovery.

Hence, Features (b) are obvious in the context of claim 1.

5.3.4 The objective technical problem solved by Features (c) can be formulated as finding an alternative way of numbering a sequence of fragments coming from different information objects.

The skilled person faced with this problem would have considered any alternative numbering of the sequence number which reflects obvious attributes of the fragments. The origin of a fragment - i.e. the information object it comes from - would have been an obvious attribute among others. Reflecting the logical separation of information objects in the numbering of the sequence number, by re-starting it at the first fragment of each information object, would have been, therefore, an obvious alternative among others.

The board has not been convinced by the appellant's argument that the creation of an RTP header was disconnected from the application layer and therefore that the person skilled in the art would not have modified the numbering of the sequence number disclosed in document D2 to take into account the origin of the fragments. As shown in Figure 8-3 on page 235 of document D8, an RTP header comprises a syntax element SSRC which identifies the source of an RTP payload. Lines 15 and 16 on page 236 further state that all RTP packets with a common SSRC have a common sequence reference. The RTP protocol therefore gives the possibility of associating different sequences of sequence numbers to different sources. There is, therefore, no intrinsic property of the RTP protocol which would have deterred the skilled person from modifying the numbering of sequence numbers chosen in document D2.

For the sake of completeness, the board notes that the last sentence on page 235 of document D8 indicates that the sequence number can start at zero or at some other random number. Hence, also the specific initialisation value chosen in document D2 ("1") is not a standard feature fixed by the RTP protocol.

Hence, Features (c) are obvious in the context of claim 1.

5.4 In view of the above, the board comes to the conclusion that the subject-matter of claim 1 lacks inventive step within the meaning of Article 56 EPC because it would have been obvious to the person skilled in the art having regard to the disclosure of D2 and the common general knowledge as evidenced by document D8.

6. Since none of the appellant's requests is allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.