T 1453/18 (Offload-device based packet processing/AMAZON) 09-05-2022

Reasons for the Decision

The application

1. The application relates to a method or a system of transmitting packets from and to a virtualized environment, such as cloud environments (international application as published, paragraph 13). It proposes the use of an offload device (e.g. a network interface card NIC - see paragraph 84, original claim 40) according to the SR-IOV standard (Single Root I/O Virtualization) which provides the necessary packet processing at, for example, the "edge" of the cloud, i.e. where the packet enters the cloud (paragraphs 14, 45, 46, 84).

2. It is further explained that the offload device directs packets arriving at the physical function according to predefined rules, e.g. trap, drop and forward, in particular to an internal virtual function (paragraphs 15, 86 to 92, figures 7 and 8). "Opaque" bits are used to match the packet to a specific ingress rule (paragraphs 16 and 17). Opaque fields may be used for a variety of purposes, such as providing protocol information (e.g. GRE), network or virtual machine (VM) identifiers etc. (paragraphs 79 to 82).

3. The SR-IOV PCI standard on which the application relies (application, paragraphs 14, 48-49, 84; DA1, section 3) proposes to provide virtual machines with direct access ("bare metal") to hardware by exposing the hardware to the VM as a plurality of functions, one physical function (PF) per hardware device (see paragraph 85 and original claim 14), exposed to the host OS, and a plurality of virtual functions (VFs; see, e.g., DA1, sections 3.1 and 6.1). The virtual functions are said to be "lightweight", providing hardware access mainly for transferring data in and out (DA1, section 3.1); the device is controlled and configured using the physical function and associated driver (DA1, section 5.2). A layer 2 switch directs packets incoming at the physical port to queues for either the host machine or one of the virtual machines, according to header information and rules configured by said physical function driver (DA1, section 6.3, points 1-3, and figure 11).

Article 13 RPBA 2020

4. The fifth auxiliary request was filed after the summons to oral proceedings, responding to clarity objections raised for the first time by the Board in its preliminary opinion (see points 4 to 6 therein: the SR-IOV standard, "portion of processing", "opaque" bits). In the Board's view, this request alleviates or overcomes some of those objections (at least the latter two) and causes no new issues, i.e. ones not already addressed in the Board's preliminary opinion. Its admittance is therefore not detrimental to procedural economy. The Board regards this set of circumstances as exceptional in the meaning of Article 13(2) RPBA 2020 (see T 1294/16, 18.2 to 18.4) and takes this request into account.

5. The sixth auxiliary request was filed during oral proceedings. The amendments aim solely at overcoming clarity objections which arose only at the oral pro­ceedings during the discussion of the fifth auxiliary request. The Board regards this set of circumstances as exceptional in the meaning of Article 13(2) RPBA 2020 and takes this request into account as well.

Clarity (Article 84 EPC)

Fifth auxiliary request

6. Claim 1 defines that a user packet "received to" a physical function is either trapped to the host domain, dropped, or forwarded to an internal virtual function.

7. In its preliminary opinion, while discussing inventive step in view of D2, the Board had equated this processing with the one performed by the switching layer in an SR-IOV device. It implicitly construed the reference to a packet received to the physical function as effectively meaning a packet received to the physical port.

8. During the oral proceedings, the appellant disagreed with this interpretation stating that the wording "received to a physical function" had to be construed literally. The physical port was different from the physical function (DA1 and figure on page 3 of the grounds of appeal), and the wording meant that ingress packets arriving at the physical port were routed to the physical function, which had the task of processing them according to different rules. This was a modification of the standard. The physical and virtual function were the same as in the standard, but the packet routing was different. Using the physical function to route packets allowed for device configuration with increased security. In particular, the trap rule gave users, especially customers of the cloud service, which would normally access only the virtual functions, a limited and controlled access to the physical functions. Thereby, the customers could make configuration requests which, for security reasons were available only via the physical function. The appellant referred to paragraph 38 of the application as originally filed where the need of providing native hardware access to users was disclosed. The application proposed a solution of doing this without compromising security. Though the trap rule was not explained in that way, the skilled person would understand that this was what it was meant for, taking into account the context provided by the description.

9. The Board remarks that this interpretation defines, as submitted by the appellant, a routing mechanism which deviates from the standard. The description, however, albeit containing language similar to the claim language recited above (paragraph 86 states "received on a physical function"), does not provide any hints or explanations that would lead the skilled person to the understanding that the SR-IOV device implementation is not standard.

9.1 There is no mention of a specific device configuration, in deviation from the standard, to implement routing of all, or a subset of, packets from the physical port to the physical function even when destined to the virtual functions. There is no mention of a specific hardware implementation of a physical function to perform switching either, which would also be required, because the physical function in a standard SR-IOV device does not include switching hardware - as switching is done elsewhere, namely in the layer 2 switch (DA1, section 6.3). If the physical function was meant to use the switch layer for routing, then there would in effect be no difference with the standard, where the packets are switched in the same layer according to rules configured by the physical function.

9.2 There is also no mention of using the trap rule to capture packets for service configuration, as the appellant acknowledged during the oral proceedings. Rather, the only mention of the trap rule functionality is in connection with broadcast traffic (paragraphs 84 and 94), which is not related to the mentioned problem.

9.3 The paragraph cited by the appellant as describing the problem does not, in the Board's view, point to such functionality of the trap function either. The description rather explains that it is desirable to provide users with bare metal access for fast data transfer, but that, for security reasons, access to configuration functions should be restricted (paragraphs 35, 39). This is no different than the standard SR-IOV, which enables configuration only through the physical function.

9.4 As a consequence, the Board cannot find support in the application for the interpretation provided by the appellant.

10. It is for this reason that the Board, in its preliminary opinion, resorted to an interpretation coherent with the packet processing of the SR-IOV standard (see point 7 above). Although this interpretation may deviate from the literal wording of the claim, the Board considers it to be a reasonable one, given that the physical and virtual functions of an SR-IOV device are actually hardware parts thereof. Prior to configuring virtual functions, the physical function is by itself akin to a standard device and by default includes the physical port (DA1, sections 3.1 and 5.2.1).

11. At least, this shows that the claim interpretation is doubtful for the skilled person. It is not clear whether the Board's initial interpretation is the intended meaning, even though the appellant submits it is not. It is not clear either that the literal meaning was the one intended, because this is not supported by the description: it would require a deviation from the standard which is neither described nor hinted at in the description, nor implicitly required in order to solve a technical problem derivable from the description.

12. Thus the Board is unable to determine a clear interpretation of this wording, in combination with the routing claimed. Claim 1 is therefore not clear in the meaning of Article 84 EPC.

Sixth auxiliary request

13. In this request, the device claims are deleted and the method claims are reworded to make clear that the packet originates from the customer of a cloud service.

14. The appellant has argued that the claim was now to a method, and thus not concerned with the hardware configuration of the device. The claim only dealt with customer packets arriving at the physical function, and the method solved the technical problem already set out in connection with the fifth auxiliary request.

15. However, the claim being a method claim does not change the fact that the skilled person needs to interpret the claim in the expressly specified context of an SR-IOV offload device and does not know whether a deviation from the standard is required, let alone which one.

16. Claim 1 of this request is therefore also not clear in the meaning of Article 84 EPC.