T 2083/13 (Acessing locked files/LENOVO) 09-09-2019

1. Summary of the invention

1.1 The claimed invention relates to a (user level) computer process reading a part of a file (see original description, [60] and [34], in particular the last sentence; figure 2: 218) which is already open (210). Repeating these reads at different offsets until the end of the file is reached will yield a full copy of the file ([64]; not claimed). Whether the file was opened by said computer process or another one is specified neither in the claims nor in figure 2. However, the description ([2] and [4]) outlines an exemplary situation where a backup program is to save a file that has already been opened by another process. In this case, some versions of the Microsoft Windows operating system prevent the open file from being read by the backup program (while producing a "sharing violation" error). According to the grounds of appeal (page 2, last paragraph), these versions comprise Windows NT (released in July 1993) and its successors. The appellant's statement in this regard, that all versions of Microsoft Windows released after 1993 were based on Windows NT, is inaccurate. Rather, according to https://de.wikipedia.org/wiki/Microsoft_Windows#DOS-Linie_f%C3%BCr_32-Bit-Rechner there were seven DOS-based versions of Windows released after 1993, including Windows 95 and 98. However, the board accepts that the invention is intended to be used with an NT-based Windows operating system which provides file locking at file-open time.

In the following, the abbreviation "NT" is meant to designate an "NT-based Microsoft Windows operating system".

1.2 The invention uses four programs:

- a [user level] program: e.g. a so-called "bam.exe", see [34], [53], [64]; figure 2: 210 and 214; claim 1 (of all requests): e.g. the steps of obtaining and identifying;

- a "kernel [level] program": e.g. a so-called "wam.sys", see [34], [53], [60];

- "the file system driver of the operating system": see [62] and [65]; claim 1: in the steps of sending and receiving; figure 2: 216 and 218;

- "the kernel of the operating system": see [36] and [50]; claim 1: step of determining; figure 2: 212.

1.3 Data is sent several times between the user level program and the kernel level program ([36], [50], [53], [60], [61]) in order to retrieve the NT data structure FILE_OBJECT which belongs to the file to be read (i.e. the target file). This data structure is then passed to the file system driver (via an NT IRP request), which obtains the file data and provides it to the user level program (process).

1.4 It is noted that, contrary to the appellant's allegation (see the grounds of appeal, paragraph bridging pages 10 and 11), an "Interrupt Request Packet (IRP)" (see claim 1, last step of requesting, and [61]) does not seem to exist in the NT driver models, but only an "I/O Request Packet (IRP)" (see D2, page 64, last paragraph, and e.g. https://en.wikipedia.org/wiki/I/O_request_packet). During the oral proceedings, the appellant stated that the Interrupt Request Packets are a subset of the I/O Request Packets, without however providing evidence that the term "Interrupt Request Packet" was used in the art at all, or indicating any specific characteristics that distinguished Interrupt Request Packets from I/O Request Packets. Thus, the board interprets the claimed Interrupt Request Packets as ordinary I/O Request Packets.

2. Inventiveness

2.1 The board agrees with the decision that the invention lacks inventive step. However, it is of the opinion that no document is needed for establishing that. As the starting point for the problem-solution approach, an NT-based Windows operating system (NT) is chosen.

2.2 In the following, only auxiliary request 3 is discussed, since it is narrower and more concrete than the other requests. Therefore, an argument showing lack of inventive step of this request also applies to the other requests.

2.3 The method as defined by claim 1 reads a part of an open target file using NT functions. This is not possible with the usual file reading routine of NT if the file was opened by another process (which is not specified in the claims). The reason is that NT provides a rather strict file locking mechanism which forbids access to a file opened by another process.

2.4 Thus, the objective technical problem to be solved is how to read a part of an open (target) file while using NT.

2.5 In this context, it is understood that some sort of identifier of the target file (e.g. a file name) must be given.

2.6 During the oral proceedings, the appellant argued that the claimed invention had to be construed as implying the purpose of accessing the file, namely backup. This purpose was disclosed in paragraph [4], even though it related to the background art. The appellant pointed out that paragraphs [5] to [10] disclosed backup methods for open files as did two further US patents (US6415300, US8074069) which the appellant referred to but did not formally introduce. In contrast, NT did not specifically relate to backup. Therefore, NT was not a suitable starting point for the assessment of inventive step, which should rather start from any of the known backup methods.

2.7 However, the application discloses (see paragraph [4]) that it is important for many applications to read data from a file opened by a different process. Backup applications are amongst them, but are mentioned only as an example. Although other applications are not specifically identified, at least one comes to mind: in order to debug a program writing into a file, it might be important for the debugger to access that file while it is open. The board concludes that the discussion of backup methods in the background art section does not imply that the only purpose of the claimed method is backup and that, therefore, this purpose is not an implicit feature of the method.

2.8 In passing, it is noted that even if backup was specified in the claim, this would not disqualify NT as closest prior art. Firstly, the board takes the view that the assessment of inventive step can start from essentially any document (see T 1742/12, section 9). Secondly, the board considers that providing a reading method for producing a backup in an NT system is a realistic objective technical problem, and that the skilled person addressing this problem would not be bound to modify the reading method of a known backup method, but would also assess the possibility of providing a reading method from scratch.

2.9 Finally, the board notes that the appellant itself, in its letter of 21 May 2019, proposed an objective technical problem which was not limited to backup.

2.10 Thus, the board sticks with the technical problem as formulated above.

2.11 Over NT, the specifically claimed steps for carrying out the claimed method are all new.

2.12 However, in order to solve the technical problem, the invention uses programs and a data structure intended for this purpose, such as the existing NT kernel routine NtQuerySystem­Infor­mation (see [36], [50]), the NT file system driver and the IRP data structure for the packet-driven I/O ([61]-[64]; see also D2, page 64 last paragraph).

2.13 The skilled person, who must be considered knowledgeable about the details of NT system routines, would know that the file system driver does not test whether the accessed file is already open and thus cannot and does not prohibit reading from open files. Thus, the skilled person would know that direct access to the file system driver is useful for solving the problem posed.

2.14 As the file system driver requires the NT data structure FILE_OBJECT to access an open file, the skilled person would obviously query the existing data structures in the kernel to retrieve this data. Likewise, the skilled person would have to obtain and provide the "offset" and "length" parameters if, and since, they are required by the file system driver (see the end of claim 1). Since some kernel data structures can only be accessed from the kernel space, the skilled person would program this kernel-specific part in a kernel level program without exercising any inventive activity.

2.15 Splitting a kernel-related task into a user level program and a kernel level program is considered by the decision (section 16) to be a well-known programming methodology. In its letter dated 21 May 2019 (page 3, paragraph 3), the appellant challenges this assumption, and in its grounds of appeal (page 7, third paragraph), it argues that even if D1 was taken to disclose such splitting, at least the "specific interaction between the user level program and the kernel level program as anticipated by claim 1" was not disclosed in D1.

2.16 The board agrees that the specifically claimed split of work between the user level and the kernel level is not disclosed in D1 nor implied by NT. However, since, as mentioned, some kernel data structure can only be accessed from the kernel space, the skilled person would have to program this kernel-specific part in a kernel level program. The rest can be done in a user level program that is more easily accessible. This renders the claimed split between user level and kernel level programs obvious, irrespective of whether co-operation between user level and kernel level programs are, in general, a known programming concept.

2.17 In passing, the board also notes that nothing in the description hints that the application would have invented the concept of co-operating user level and kernel level programs, suggesting at least that the application was relying on this as a known concept.

2.18 The appellant states in its letter dated 21 May 2019 (page 3, paragraph 5) that there are several different ways to access these kernel data structures. For example, the computer could be rebooted into a preboot environment in order to access them.

2.19 The board disagrees. This is not possible, since these data structures (as they are disclosed in description sections [37]-[49]) are held in the main memory (RAM; during the run-time of the program), and after a reboot they do not exist anymore. Thus, they cannot be accessed after reboot.

2.20 The appellant further argues (page 3, paragraph 6) that the development of an NT is very complex wherefore it is disputed that the splitting is a well-known programming methodology for NT.

2.21 The board cannot see why the complexity of developing an operating system should have anything to do with the way of organising the interaction between user level functionality and kernel-specific functionality.

2.22 Therefore, claim 1 of auxiliary request 3 is not inventive, in violation of Article 56 EPC. It follows that broader claim 1 of each of the other requests is not inventive, either.