Saturday, 21 November 2009

T 1207/05 - Obvious Combination of Internet Drafts

The treatment of Internet sources as state of the art is certainly one of the big challenges for patent offices in the near future. Landmark decision T 1134/06 has provided some fundamental principles, but much remains to be done. 

The present decision is interesting in so far as it deals with a field in which the skilled person is said to be expected to review certain drafts available on the Internet. 

BTW, I think this is the first decision to introduce the notion of 'community of skilled people', which comes dangerously close to the false idea that the skilled person is a real person.
[...] Starting from D2, the problem underlying claim 1 is to provide an alternative multiplexing scheme in which quality-of-service (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 (Internet Engineering Task Force)drafts and IETF Requests for Comments, 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 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 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, 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 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. 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 states that RTP is intended to be tailored through modifications and/or additions to the headers as needed. Moreover, D5 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, 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. [3.3]

To read the whole decision, click here.