T 1224/17 (Epoll optimisation/XILINX) 25-07-2022

1. Summary of the invention

The application relates to an improvement of an operating system program for managing input/output (I/O) event notifications, such as the system call "epoll" of the Linux operating system (OS) kernel (see https://en.wikipedia.org/wiki/Epoll) which is the only embodiment of the claimed subject-matter disclosed in the patent application. Epoll monitors sets of file descriptors for events to see if I/O is possible on resources/devices represented by any of these file descriptors. A resource/device may be a file, socket, FIFO, block or character device, or other I/O resources maintained by the OS (see A2 publication, [2], first sentence). Epoll is "relatively inefficient when the set of monitored file descriptors and I/O events changes because this additionally requires calls to epoll_ctl()" ([4], third sentence). The invention consists in intercepting epoll_ctl() system calls (figure 2: 208; [38], fifth sentence) at the user-level interface (210) in the user space (207). When several epoll_ctl() system calls (208) have been intercepted and their parameters stored, the user-level interface makes a single combined system call (212; [40], first sentence) to the kernel, needing only one context switch from user space (207) to kernel space (201). Then in the kernel space (201), the epoll_ctl() system calls (214) represented by the single system call (212) are made within the kernel without the need for time-consuming context switches for each of them, as would have been the case with the many original system calls (208; see also figure 1: 108) from user space to kernel space ([41]). In doing so, the applications (202, 203) that make the epoll_ctl() system calls do not have to be modified ([38], sentences 1-4) because the invention works transparently.

2. Original disclosure

2.1 The examining division did not raise any objections under Article 123(2) EPC in its decision and the board concurs that there was no reason to do so.

2.2 The amendments in independent claims 1 and 16 of auxiliary request 1 are based on original claim 5 and description paragraph [41], first sentence.

3. Inventiveness

3.1 In the two communications to which the examining division referred in its decision according to the state of the file (see point II above), it took D1 as the starting point for assessing inventive step (see summons, 3.1). The subject-matter of the then main request differed from D1 in the last three steps steps (i.e. intercepting configuration calls, storing parameter sets of the configuration calls, effecting configuration calls by a first system call). These steps were disclosed in D2 (summons, 3.5).

3.2 The board agrees with the appellant (grounds of appeal, 6.11) that D2 does not disclose an interception of calls (i.e. at runtime and transparent to the applications). Instead, according to the method of D2, the programmer of the applications is instructed to make sure that the application process (AP) stores its "medium size" data into a shared memory allocated by an IO process (IOP), see page 37, right column, third paragraph, third sentence:

"The IOP creates a shared memory region that can be accessed by all application processes (APs)."

fourth paragraph, first sentence:

"1) Application processes: When taking a checkpoint, an AP will perform a series of data writes as described below."

and sixth paragraph:

"(3) If the data is regarded as "medium size", then we [i.e. the AP] will store this data into the share memory created by IOP."

3.3 The AP furthermore sends a signal to the IOP to notify it of the pending data, see page 38, left column, second paragraph, fifth sentence:

"After an AP finishes copying data to the shared memory, it checks if the share memory has accumulated enough dirty data. If it finds enough data there, then it sends a signal to the IOP to notify it of the pending dirty data."

3.4 It is furthermore not disclosed in D2 whether the IOP is in user space or kernel space. In the board's view, the skilled person would assume it to be in kernel space, since it is concerned with I/O. This additionally puts in question the argument of the examining division that the IOP corresponds to the "user-level interface", which is in user space (see the summons to oral proceedings of the examining division, dated 19 March 2015, page 3, firth paragraph).

3.5 However, without interception in user space, the method of D2 cannot produce the technical effect of reducing the context-switches between user space and kernel space in the same way as the invention, regardless of whether it reduces context switches at all.

3.6 As to the argument in the summons of the examining di­vi­sion (3.5, last but one paragraph) that the aggrega­tion of data writes in D2 implied an interception in user space, the board notes that the aggregation is achieved by programming the applications accordingly (i.e. by construction), and not by interception (i.e. at run-time).

3.7 Therefore, the subject-matter of claim 1 of auxiliary request 1 involves an inventive step over the combination of D1 and D2, Article 56 EPC.

4. Remittal

4.1 The appellant did not file application documents adapted in view of the claims of auxiliary request 1. The board agrees that it is reasonable to postpone the adaptation of the description until after agreement on an allowable set of claims has been reached. The board also considers the common practice for boards of appeal to leave the adaptation of the description to the applicant (or proprietor) in dialogue with the department of first instance, as part of the grant (or maintenance) procedure that is to be carried out. The board considers this to be a special reason within the meaning of Article 11 RPBA 2020 for remitting this case to the first instance.

4.2 In this context, the board notes that dependent claim 5 of auxiliary request 1 seems to be redundant, since its additional features are contained in claim 1 of auxiliary request 1.