T 1207/05 (Multiplexing header for RTP Packets/LUCENT) of 28.8.2008

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division dispatched 29 April 2005, refusing European patent application No. 00 301 583.1 for the reasons that independent claims 1 and 6 lacked inventive step having regard to the disclosure of

D1: J. Rosenberg et al: "An RTP Payload Format for User Multiplexing", IETF Internet Draft, 6 May 1998 (1998-05-06);

D4: H. Schulzrinne: "RTP Profile for Audio and Video Conferences with Minimal Control", IETF Internet Draft, [Online], 26 February 1999 (1999-02-26), pages 1-30;

D5: H. Schulzrinne et al: "RTP: A transport protocol for Real-Time Applications", IETF Request for Comments 1889, January 1996, pages 1 to 38.

II. Notice of appeal was filed on 27 June 2005. The appeal fee was paid on the same day. The statement of grounds of appeal was filed on 4 August 2005 with letter of 27 July 2005. The appellant requested that the appealed decision be set aside and that a patent be granted based on claims 1 to 9 filed with the statement setting out the grounds of appeal.

III. The board issued an invitation to oral proceedings accompanied by a communication. In the communication the board expressed the preliminary view that claims 5 to 9 were not clear, contravening Article 84 EPC 1973, that claims 1 and 5 did not comply with the provisions of Article 123(2) EPC for various reasons and that independent claims 1 and 5 lacked inventive step having regard to the disclosure of

D2: B. Subbiah et al: "User Multiplexing in RTP payload between IP Telephony Gateways" IETF Internet Draft, 21 August 1998 (1998-08-21), work in progress;

D1, D4 and D5 and that the dependent claims did not add any inventive matter.

IV. With its letter of 28 July 2008, in response to the communication, the appellant filed claims 1 to 9 of a new main request and claims 1 to 9 of an auxiliary request, replacing the claims on file.

V. The appellant announced that it would not attend the oral proceedings set for 28 August 2008 and requested that the oral proceedings be cancelled and the procedure continued in writing. The board informed the appellant that the oral proceedings would take place as scheduled.

VI. Oral proceedings took place as scheduled on 28 August 2008. Neither the appellant nor its representative attended the hearing. After deliberation on the basis of the submissions and requests of 28 July 2008 the board announced its decision.

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

"A method for use in a packet server, the method comprising the steps of:

receiving a number of incoming data packets; and CHARACTERIZED BY:

formatting (210) each incoming data packet into a formatted packet comprising a multimedia data portion and a multiplexing header portion, the header portion including a user identifier field of more than 7 bits, a length indicator field, a more packets field, a sequence number field and a class-of-service (CoS) field wherein the CoS field comprises a number of bits representative of a quality-of-service (QoS) and separate payload type bits; and

multiplexing (210) each of the formatted packets into a single User Datagram Protocol/Internet Protocol "UDP/IP" transport session."

Independent claim 5 of the main request reads as follows:

"Apparatus for transporting packets CHARACTERIZED BY:

a formatter operable to;

receive a number of incoming data packets;

format each incoming data packet into a formatted packet comprising a multimedia data portion and a multiplexing header portion, the formatting utilizing the analyzed header information; and

multiplex the formatted packets into a single User Datagram Protocol/Internet Protocol "UDP/IP" transport session,

wherein the header portion includes a user identifier field of more than 7 bits, and length indicator field, a more packets field, a sequence number field and a class-of-service (CoS) field wherein the CoS field comprises a number of bits representative of a quality-of-service (QoS) and separate payload type bits."

Claims 1 and 5 of the auxiliary request correspond to claims 1 and 5 of the main request, replacing the user identifier field of more than 7 bits by a user identifier field of at least 16 bits.

Reasons for the Decision

1. Admissibility

The appeal complies with the provisions of Articles 106 to 108 EPC 1973, which are applicable according to J 10/07, point 1 (see Facts and Submissions point II above). Therefore it is admissible.

2. Procedural matters

According to Article 116(1) EPC 1973, oral proceedings shall take place either at the instance of the European Patent Office if it considers this to be expedient or at the request of any party to the proceedings. Oral proceedings are considered as an effective way to discuss cases mature for decision, because the appellant is given the opportunity to present its concluding comments on the outstanding issues (Article 113(1) EPC 1973), and a decision based on the appellant's requests may be given at their end (Rule 68(1) EPC 1973).

The need for procedural economy requires that the board should reach its decision as quickly as possible while giving the appellant a fair chance to argue its case.

The appellant gave no reasons to support the request to cancel the oral proceedings scheduled by the board and to continue the procedure in writing. The board considered that, despite the appellant's announced intention not to attend, the twin requirements of fairness and procedural economy were still best served by holding the oral proceedings as scheduled. The request to cancel oral proceedings and to continue in writing was therefore refused.

Article 15(3) RPBA stipulates that the Board shall not be obliged to delay any step in the proceedings, including its decision, by reason only of the absence at the oral proceedings of any party duly summoned who may then be treated as relying only on its written case. Allowing an appellant to delay a decision by filing amended requests which are not allowable and not attending oral proceedings at which they could be discussed, would also be contrary to Article 15(6) RPBA, which stipulates that a Board shall ensure that each case is ready for decision at the conclusion of the oral proceedings, unless there are special reasons to the contrary. An appellant's request to continue the procedure in writing without giving reasons for not attending the oral proceedings already arranged, does not comply with this regulation.

In the present case, the amendments filed contain several deficiencies as outlined below. Due to the appellant's absence in the oral proceedings these deficiencies could not be discussed with him. Since the aim of oral proceedings is to come to a final decision by its end and since the appellant did not appear in order to explain why these amendments should be allowable the board can only rely on the appellant's written submissions filed together with the amendments on 28 July 2008. By filing amended claims in response to the communication accompanying summons to oral proceedings and subsequently not attending these proceedings, the appellant must expect that the board will have to examine whether the amendments newly introduced in the claims comply with the provisions of Articles 123(2) EPC and 84 EPC 1973 and further whether the objections which have already been communicated are overcome with respect to the amended claims.

However, the submissions filed together with the amendments on 28 July 2008 are not convincing, for the following reasons (see points 2 and 3).

3. Main request

3.1 Article 123(2) EPC

Claims 1 and 5 specify the size of the user identifier field as being "more than 7 bits". In the application as originally filed, the length of the user identifier field is disclosed as being 16 bits, see column 2, line 31; column 4, lines 35 and 44; column 7, line 58 and column 8, line 4. A length of more than 7 bits does not have a basis in the application as filed.

The appellant argued in its letter of 28 July 2008 that because the application discloses that the UID field is 16 bits long it is inherently more than 7 bits in length. The board notes that, although a UID field of 16 bits in length fulfils the requirement of being more than 7 bits in length, the claimed feature that the user identifier field be more than 7 bits comprises and discloses the whole range of lengths greater than 7 bits. Such a range, which includes e.g. 8, 10, 20, 100, etc. bits, was clearly not disclosed in the application as filed. As stated by the Enlarged Board in its decision G 1/93, point 9, the underlying idea of Article 123(2) EPC is that an applicant shall not be allowed to improve his position by adding subject-matter not disclosed in the application as filed, which would give him an unwarranted advantage and could be damaging to the legal security of third parties relying on the content of the original application.

Thus, claims 1 and 5 do not comply with the provisions of Article 123(2) EPC. For this reason the main request is not allowable. However, the board notes the following further defects.

3.2 Article 84 EPC 1973

Moreover, as the feature of a user identifier field of more than 7 bits is not supported by the description, claims 1 and 5 do not comply with the provisions of Article 84 EPC 1973.

3.3 Novelty and inventive step

D2 proposes a method to multiplex a number of low bit rate audio streams into a single RTP/UDP/IP connection between IP telephony gateways, see abstract. D2 in the paragraph bridging pages 2 and 3 discloses formatting each incoming data packet comprising a mini packet with data of a low bit rate connection into a formatted packet such that a MINI-header is prepended to each of the mini packets before it is assembled with other mini packets into a RTP payload. Assembling the formatted mini packets into a RTP payload corresponds to multiplexing each of the formatted packets into a single User Datagram Protocol/Internet Protocol "UDP/IP" transport session.

The MINI-header corresponds to a multiplexing header portion and comprises a channel identification field, a length indicator field, a transition bit field and a reserved bit field (see page 3, point 2.1). The channel identification field is used for identification of the users, it corresponds to the user identifier field. It is a field of 8 bits, i.e. more than 7 bits.

D2 discusses in the last paragraph of page 3 that a Sequence Number field and a Marker field in the MINI-header might be useful at the receiving gateway and that the task of the sequence number of guaranteeing the order of packet arrival at the receiver might be provided by the sequence number field of the RTP header. Although D2 prefers using the sequence number field in the RTP header, it still discloses the possibility of a Sequence Number field in the MINI-header.

The method of claim 1 differs from the method disclosed in D2 in that the header additionally comprises a more packets field and a class-of-service field wherein the class-of-service field comprises a number of bits representative of a quality-of-service and separate payload type bits. The method of claim 1 is novel.

Starting from D2, the board considers that the problem underlying claim 1 is to provide an alternative multiplexing scheme in which QoS is addressed, data packets of different class-of-service types may be multiplexed and data packets exceeding a given length may be transmitted. The problem includes three independent objectives.

D2 mentions several IETF drafts and IETF Requests for Comments in section 13 "Bibliography", among which are documents D1 and D5 and Request for Comment 1890, of which D4 is a revision.

D5 specifies an Internet standards track protocol for the internet community describing the real-time protocol RTP. D1, D2 and D4 are working documents of the IETF (Internet Engineering Task Force) Audio-Video Transport Working Group. These documents are Internet-Drafts published on the Internet. The community of skilled people in the field is expected to review these documents and to comment on them. The documents are work in progress and are valid for a maximum of six months. They may be replaced by revisions. They are a basis for technical discussions necessary in the working groups for the creation process of standardized technical solutions. A skilled person would consider them and combine parts of them, if appropriate.

D2 explicitly quotes D1 (see point 9) and compares the proposals of D1 and D2.

The skilled person looking for a solution of the partial problem that data packets of different class-of-service types may be multiplexed would consider D1 which discloses a user header including a payload type field, see figure 4, and would include the payload type field in the header portion.

Moreover, D1 discloses with reference to figure 4 that the user header comprises a marker bit, which has the same definition as in document D4. D4 in point 5 "Video" discloses that, if a video image occupies more than one packet, the marker bit is set to one for the last frame and otherwise set to zero (see page 20, lines 10 and 11). This implies that the marker bit is used to indicate whether an additional formatted packet for transporting the incoming packets is used. The skilled person would understand, that the use of the marker bit solves the partial problem of transmitting data packets exceeding a given length. The marker bit thus has the same function as the claimed more packets field. Thus, the use of a more packets field in the header portion is disclosed in D1 when taking into account its reference to D4.

The skilled person would further consider D5, which specifies an Internet standards track protocol describing the real-time protocol RTP. D5 is a basic reference document providing general information and details of RTP. It is mentioned as a reference document in D1 and D2.

D5 in the first paragraph of page 4 states that RTP is intended to be tailored through modifications and/or additions to the headers as needed. Moreover, D5 in point 5.3.1 discloses an extension mechanism to allow individual implementations to experiment with new payload-format-independent functions that require additional information to be carried in the RTP data header. The skilled person would understand that, if a QoS field was needed, it would be possible to add it to the header.

The skilled person would further understand from the discussion in D2, page 3, last paragraph which concerns using a sequence number field in the MINI-header instead of in the RTP header, that fields of the RTP header may be transferred to the MINI-header and vice versa depending on the particular circumstances. Thus, it is considered to be obvious to place a QoS field in the header portion of the formatted packet.

Thus, the method of claim 1 does not involve an inventive step.

Similar arguments apply to apparatus claim 5, mutatis mutandis.

4. Auxiliary request

4.1 Article 123(2) EPC

Claims 1 and 5 of the auxiliary request refer to a user identifier field of at least 16 bits instead of more than 7 bits as specified in claims 1 and 5 of the main request. In the application as originally filed, the length of the user identifier field is disclosed as being 16 bits, see column 2, line 31; column 4, lines 35 and 44; column 7, line 58 and column 8, line 4. A length of at least 16 bits does not have a basis in the application as filed.

The board notes that, although a UID field of 16 bits in length fulfils the requirement of being at least 16 bits in length, the claimed feature comprises and discloses the whole range of lengths greater than or equal to 16 bits. Such a range, which includes e.g. 17, 18, 19, 20, 100, etc. bits, was clearly not disclosed in the application as filed.

Thus, claims 1 and 5 do not comply with the provisions of Article 123(2) EPC. For this reason the auxiliary request is not allowable. However, the board notes the following further defects.

4.2 Article 84 EPC 1973

Moreover, as the feature of a user identifier field of at least 16 bits is not supported by the description, claims 1 and 5 do not comply with the provisions of Article 84 EPC 1973.

4.3 Novelty and inventive step

Claim 1 differs from claim 1 of the main request in replacing the length of the user identifier field of more than 7 bits by at least 16 bits.

D2 discloses that the size of the channel identification field, which corresponds to the user identifier field, limits the number of users sharing a single transport session, see page 3, Purpose of the field Channel Identification, lines 13 to 16. The skilled person would understand, that the choice of the size of the field is linked to the intended number of users. The size of the channel identification field is an implementation choice being part of the normal professional activity of the skilled person. Thus, the differing feature of claim 1 of the auxiliary request does not add any inventive matter to claim 1 of the main request.

Similar arguments apply to apparatus claim 5, mutatis mutandis.

5. There being no allowable requests, the appeal must be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.