T 1608/10 (Redirection to local copies/MICROSOFT) of 4.11.2014

Summary of Facts and Submissions

I. This appeal is against the decision of the Examining Division to refuse the European patent application No.07763001.0. The application was published as WO 2007/089854 A1.

II. The Examining Division refused the application on the grounds of lack of novelty (main request) and lack of inventive step (auxiliary request). The Examining Division considered that the term "operating system registry" in claim 1 according to both requests was not limited to the Windows registry, but covered any "storage location that is used to register or store data by the operating system", of which the system tables in D1 (US-A-5893920) were an example. The Examining Division also argued that, even if the claimed invention were limited to the Windows registry, this would have been an obvious alternative in view of the documents:

D9: Ganapathi A. et al: "Why PCs are fragile and what we can do about it: a study of Windows registry problems", Proceedings of the 2004 International Conference on Dependable Systems and Networks, 2004, IEEE; and

D10: Carvey H.: "The Windows registry as a forensic resource, Digital Investigation (2005) 2, pages 201-205, 2005, Elsevier.

III. In the notice of appeal, the appellant requested that the Examining Division's decision be set aside, and that a patent be granted on the basis of a main request, a first auxiliary request, or a second auxiliary request, all filed with the notice of appeal. The main request corresponded to the refused main request. The appellant also requested oral proceedings as a "precautionary measure". In the statement setting out the grounds of appeal, the appellant maintained those requests.

IV. In a communication accompanying a summons to oral proceedings, the Board tended to agree with the Examining Division that "operating system registry" should be interpreted broadly, and that storing the mapping in the Windows registry would have been obvious.

V. With a letter dated 2 October 2014, the appellant filed amended auxiliary requests I to V, and argued in favour of novelty and inventive step.

VI. Oral proceedings took place before the Board on 4 November 2014, with the appellant present. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request filed with the notice of appeal or one of auxiliary requests I to V filed with the letter of 2 October 2014.

VII. Claim 1 of the main request reads:

A method of mapping a server file to a locally stored copy of the server file, comprising:

receiving a selection for opening a server file to a local computing device remote from a server containing the server file;

storing a local copy of the server file at the local computing device;

generating a mapping from the server file at the server to the local copy at the local computing device;

storing the mapping at the local computing device, wherein storing the mapping at the local computing device includes storing the mapping at an operating system registry at the local computing device;

after generating the mapping, receiving a selection for opening either the server file or the local copy of the server file;

in response to receiving the selection for opening either the server file or the local copy of the server file, determining whether a mapping is available from the server file to the local copy of the server file; and

if a mapping is available from the server file to the local copy of the server file, retrieving the local copy at the local computing device via the mapping, and opening the local copy.

VIII. Claim 1 of auxiliary request I differs from the main request by the replacement of the text "at an operating system registry" by "in the Windows registry".

IX. Auxiliary request II adds to claim 1 of the main request the following text at the end of the "storing[...]" feature: "wherein a server file path is stored as a registry key".

X. Like auxiliary request I, auxiliary request III replaces "at an operating system registry" by "in the Windows registry".

XI. Claim 1 according to auxiliary request IV differs from that according to the auxiliary request II by the addition of the following text to the "storing[...]" feature:

and a local copy path is stored as a default value for that registry key, in particular so that subsequent requests for either the server file or the local copy will default to the path for the local copy for first determining whether a path to the local copy exists before determining whether the server file must be opened.

XII. The fifth auxiliary request again replaces "at an operating system registry" by "in the Windows registry". It also removes the words "in particular" from the feature of "storing ...".

XIII. The appellant argued that the invention defined by claim 1 according to the main request differed from D1 in that the mapping was stored at an "operating system registry", which the skilled person would have understood as referring to a hierarchical database for storing settings and options for the operating system, such as the Windows registry, as explicitly defined in auxiliary requests one, three and five. An operating system registry was different from the conventional files used in D1.

The appellant also argued that storing the mapping in the "operating system registry" allowed "retrieving the mapping data more efficiently and quickly". This effect was due to the indexed structure and the central, fixed location, of the registry.

The appellant also argued that none of the prior art documents cited during the procedure (D1 - D10) disclosed the use of the Windows registry for storing a mapping from a server file path to a local copy path. In fact, D9 taught away from using the Windows registry, because it described the registry as problematic. Thus, in the appellant's view, there was nothing in the prior art which would have prompted the skilled person to modify D1 so as to store the mapping in an operating system registry.

XIV. At the end of the oral proceedings, the Board announced its decision.

Reasons for the Decision

1. The invention

1.1 The invention concerns a system for document sharing which allows multiple users to work on documents stored on a remote server (published application, page 6, lines 10-21). The shared documents may be edited by a user during an offline session (page 7, lines 7-10). Then, a local copy of the server file is stored on the user's computer, as is a mapping from the server file to the local copy.

1.2 When a subsequent request is made to open the server file, it is determined whether a mapping to a local copy is already available (page 10, lines 31 to page 11, line 7). If such a mapping exists, the requesting application is directed to the local copy via the mapping (page 11, lines 8-12). If no mapping exists, the application is directed to the server file, which is then opened (page 11, lines 12-16).

1.3 The mapping includes a path for the server file, and a path for the local copy (page 7, lines 22-24). It is stored in the "operating system registry" of the local computer (page 8, lines 27-29; page 10, lines 3-7). The server path is stored as a "registry key", and the local copy path as a "default value for that registry key" (page 8, lines 29-33). The application does not define the terms "operating system registry", "registry key", and "default value", but they may be understood in the context of the Windows registry. Although the invention is not limited to Windows (see page 4, lines 23-26), the Board accepts that the Windows registry was so well known that an interpretation in terms of it is possible.

1.4 The Windows registry is a hierarchical database for storing information about the Windows operating system, its configuration, attached devices, applications, and users (see, for example, D10, page 201, right column). It is made up of "keys", which contain either "subkeys" or "values" (D10, figure 1), similar to the directory structure of a file system. A value is an item within a key, and comprises a name, a type, and associated data. As the appellant explained, the name "(Default)" is used for those values whose names have not been set.

2. Auxiliary request V - claim 1

2.1 Claim 1 according to auxiliary request V defines the invention most narrowly. In particular, the restriction to the "Windows registry" in claim 1 settles the issue of how the term "operating system registry" should be understood. Therefore, the Board finds it convenient to start with this request.

2.2 D1 discloses a server file system supporting disconnections of clients by caching files from the server on the client machines (see column 5, lines 9-18; column 7, lines 18-54). For this purpose, D1 provides a cache manager that maintains a mapping between the server file and the local, cached copy (see D1, column 8, lines 20-36; and figure 5). The mapping information includes the server file path (FILE/DIRECTORY NAME) and the local copy path (CACHE LOCATION D:\CACHE), and it is stored in the "system tables" shown in figure 5.

2.3 It is common ground that D1 discloses the subject-matter of claim 1 except for the storing of the mapping, in the form of a key and a default value, in the Windows registry.

2.4 The appellant argued that, compared to the system tables in D1, the Windows registry allowed the mapping to be more efficiently and quickly retrieved by a requesting application, an effect mentioned in the published application (page 10, lines 5-7), although not in the context of D1. This effect was a result of the indexed structure of the Windows registry and the use of a fixed, central location for storing the mapping information.

2.5 The Board doubts that these effects are actually achieved. Firstly, it is not clear in what sense the invention is more efficient. The application does not define efficiency or any way of measuring it. Nor is any measure of the efficiency of the prior art provided.

Secondly, the Board is not convinced that the Windows registry is faster than the tables in D1, which also have a hierarchical structure (see D1 figure 5).

Thirdly, the Windows registry being a central repository does not seem technical. As the Board understands it, the effect for which the appellant argued is that other applications that may seek to open the document on the server and which should be redirected to the local copy do not need to look for the mapping information because it is stored in a fixed location; all applications know about that in advance. This seem to be no more than a programming convenience. Any application must know where to find the mapping, and it does not seem to make any difference whether the application is told "it is in the Windows registry" or is told "it is at location X." The application must be informed, either way.

2.6 However, even accepting the effects for which the appellant argued, the Board finds that the use of the Windows registry would have been obvious.

2.6.1 The Windows registry has been used as a central repository for storing configuration information and application data at least since the introduction of Windows 95 in 1995, more than ten years before the priority data of the present application. The Board considers that the structure (keys and values) of this fundamental component of the operating system was well known, and that if it had any advantages in terms of efficiency, the skilled person would have known it.

2.6.2 Indeed, the application does not provide any explanation of the structure or location of the Windows registry, and the Board considers that, in so far as it relies on the Windows registry, the application assumes the skilled person knows what and where it is and how to use it. As it was a fundamental part of the Windows operating system, such knowledge would, in the Board's view, have been part of the skilled person's common knowledge.

2.6.3 Although the examples in D1 are mainly related to IBM OS/2, Windows NT is mentioned as an alternative operating system (see column 4, lines 56-62). The skilled person, therefore, would have considered an implementation under Window NT, and would be faced with the question of how to store the mapping.

2.7 The appellant argued that the skilled person, given the task of implementing the shared file system in D1 on the Windows NT platform, would have stored the mapping in the conventional file system and not in the registry. There was, according to the appellant, no teaching in the prior art which would have prompted the skilled person to use the Windows registry. On the contrary, the prior art taught away from this solution: D1 - D8 did not mention the Windows registry at all; D9 described the registry as problematic, which would have discouraged the skilled person from using it; and D10 only taught that the registry contained forensic information. The passage in D10, which suggested that the registry may be used to store information redirecting an application to a copy of that application (D10, page 203, left-hand column) had to do with redirection to a "Trojaned copy". It was not a teaching to store a mapping from a server file path to a local copy path in the Windows registry.

2.8 The Board cannot see any prejudice in the prior art against storing the mapping in the Windows registry. The fact that a feature is not disclosed in a document does not necessarily mean that this feature was not obvious. In the context of D1, which, as noted above, is concerned mainly with OS/2, with no more than an indication that an implementation on Windows NT would be possible, it is not surprising that the details of where and how to store mapping data in a Windows NT implementation are left to the skilled reader.

2.9 Furthermore, as conceded by the appellant in the oral proceedings, the invention does not overcome any of the problems mentioned in D9.

2.10 Regarding the contested passage in D10, the Board considers that it provides evidence that the skilled person would have known how to store mappings redirecting from one location to another using the Windows registry. The Board's assessment of inventive step does not rely on the skilled person applying some teaching found in D10, but only the fact that the skilled person would have known how to use the registry for redirection. As already stated, that is something the application assumes, and D10 does no more than confirm it.

2.11 The Board, therefore, is satisfied that the skilled person would have considered storing the mapping in the registry. In the Board's view, this amounts to using the registry for what it was designed for. The skilled person would have been aware of any advantages the Windows registry had by virtue of being hierarchical and indexed and having a fixed location.

2.12 Having decided to store the mapping in the Windows registry, one can either store the data as a key (or subkey) or a value. In the Board's view, it is natural to use the server path as an index into the registry because it is the server file that will be requested by an application. Therefore, it would have been obvious to store the server file path as a registry key. Storing the local copy path as a value rather than a subkey would have been a straightforward choice between the only two alternatives, and the skilled person would choose whichever is most convenient. Furthermore, the Board understands that the "default" value is just a value having an empty name. Since a default value is automatically created for every key, it would have been obvious to use it.

2.13 For these reasons, the Board concludes that the invention as defined in claim 1 of the fifth auxiliary request does not involve an inventive step having regard to D1 and the common general knowledge of the skilled person (Article 56 EPC 1973).

3. Since claim 1 of the fifth auxiliary request is within the scope of claim 1 according to each of the higher ranked requests, these requests are no more allowable than the fifth auxiliary request.

Order

For these reasons it is decided that:

The appeal is dismissed.