T 1236/06 (Workstation registration/NOVELL) of 25.3.2009

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse European patent application 01203778.4 on the grounds that claim 1 and/or claim 14 of the main and first and second auxiliary requests was either not clear (Article 84 EPC 1973), or contained an extension of subject-matter (Article 123(2) EPC 1973). The independent claims of the third auxiliary were considered not to involve an inventive step (Article 56 EPC 1973) over the document Novell: "ZENworksTM for Desktops, Version 3, Deployment", September 2000, Novell, Inc., Provo, UT, USA (D1), in combination with common general knowledge.

II. In the statement setting out the grounds of appeal, the appellant maintained the requests that were refused by the examining division.

III. In the communication accompanying the summons to oral proceedings, the Board summarised the issues to be discussed and concentrated on claim 1 of the third auxiliary request, which it tended to consider to have the same scope as the preceding requests. The Board, however, agreed with the examining division that its subject-matter did not involve an inventive step. In a response, the appellant filed a fourth auxiliary request to take account of the Board's comments. The appellant also filed an amended Figure 1 corresponding to Figure 1 of the priority document.

IV. At the oral proceedings before the Board, the appellant withdrew the former main and first and second auxiliary requests and the newly filed Figure 1, and requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request (former third auxiliary request) or the auxiliary request (former fourth auxiliary request), or that the case be remitted to the examining division based on these requests.

V. Claim 1 of the main request reads as follows:

"A method of registering one or more workstations in a network tree in a computer network, comprising the steps of:

enabling (102) a user at a workstation to access the network;

determining (104) at the workstation whether the workstation comprises the workstation object that defines information about the workstation and users of that workstation;

if the workstation object does exist on the workstation, enabling the workstation to register the workstation using the existing workstation object; or

if the workstation object does not exist on the workstation, performing the further steps of;

locating (116) an import service on a server;

transmitting (118) registration information from the workstation to the import service;

using the import service to create (124) a workstation object based on the registration information and any applied (122) policy criteria;

forwarding (126) the newly created workstation object to the workstation;

enabling the workstation to register the workstation using the newly created workstation object."

Claim 1 of the auxiliary request essentially replaces the third last step ("using the import service ...") of claim 1 of the main request by the following features:

" determining (120) whether criteria exist for the workstation to be registered, including rules specifying how a workstation is to be named, where the workstation is to be created, and how user rights are to be managed;

if said criteria exist, using the import service to create (124) a workstation object based on the registration information and any applied policy criteria by facilitating delegation of server tasks by enabling the user to assign one or more rights to the service using a policy object and specifying the one or more rights in the policy object, comprising the steps of:

a) receiving (402) a delegated task request from the workstation, the task request including requesting that a workstation object be created as a directory representation of the workstation by the import service;

b) determining (404) a directory on the workstation the import service may access to perform (418) the delegated task;

c) determining (406) whether the import service has sufficient access rights to the said directory;

d) accessing (410) the directory on the workstation if a determination is made that the import service has access rights to the said directory;

e) searching (412) a policy governing the import service for criteria related to the delegated task;

f) determining (414) whether the policy criteria identify at least one rule to be applied for performing the delegated task;

g) applying (416) the at least one rule if the at least one rule is identified;

h) performing (418) the delegated task;"

VI. The appellant argued essentially as follows:

The invention concerned improvements to the registration of workstation objects in the network tree and came into effect when logging in. According to the invention, if the workstation object did not exist at the workstation, an import service was called that created it. It was then forwarded to the workstation. Since the information was available locally, registration could be performed in the client. This reduced network traffic and improved security.

There were two technical problems to be overcome:

1. Reduction of network traffic:

"Workstation registration typically includes the following steps. A client may register workstation information about a client. A system administrator may then import the workstation, using the workstation information, and notify the client. The client may then verify that the workstation has been created and record a name assigned to the workstation. Such systems typically require multiple steps and intervention by a plurality of users. This increases communications over the network." (end of paragraph [0003] of the published application)

2. To ensure that the import service did not gain any inappropriate access rights to authenticate to the local directory (since it would require write rights):

"Another problem relates to assigning rights for performing tasks. Task rights may be assigned to a server container. This, however, may permit a broad class of servers and other directory objects to perform one or more tasks. Thus, some of the directory objects may have undesired, but authorized rights (to) have particular tasks performed. This is a drawback. These and other drawbacks exist." (paragraph [0004])

The first problem was overcome by reducing the number of communications necessary between clients and the server, and eliminating communication between the import service and the server, during workstation registration, by virtue of using the import service to push information needed for the workstation registration object from the import service to the client, and enabling the client only to communicate with the server in the registration step. The import service was therefore used only indirectly in the workstation registration step. The prior art only taught using a server side application (e.g. import service in Dl) to create a new workstation object and detect a workstation at the directory tree. It would not have been obvious to localize the workstation object at the client side, enabling the client to perform the workstation registration step.

Localizing a workstation object for registration purposes offered greater atomization and control with respect to local involvement in registering a workstation. One advantage, as indicated in the application, going beyond a reduction in network traffic, was the reduced need for system administrator involvement. The localization allowed the client terminal to manage and administer additional aspects of workstation registration without a system administrator and to do so securely on the local machine by using tasks and policies as disclosed. Localization of workstation tasks might be considered to increase complexity, from a secure network administration viewpoint, and so it was indeed surprising that a solution had been found which permitted the localization of the registration process while maintaining the security and integrity of the network in real time.

Furthermore, the general trend in the industry was to move critical functions to the server side.

The second problem was overcome by giving a client terminal the ability to securely delegate tasks to services while using a policy for ensuring that access to local (e.g. protected) resources was authenticated. This was a novel feature giving rise to a further technical contribution to the art. Thus, the localization accomplished more than a decrease in network traffic and system administrator involvement. None of this was within the teaching of the prior art and would therefore not have been obvious.

Reasons for the Decision

1. The appeal complies with the requirements referred to in Rule 65(1) EPC 1973 and is therefore admissible.

Application

2. The application relates to registering a client workstation with a server on a network. It is a further development (version 3.2) of the appellant's (Novell) system called "ZENworks for Desktops". D1 describes the previous version 3.0.

3. According to the description, connecting a workstation to a network involves the steps of importing and registration. Importing occurs the first time that the workstation is connected to the network and involves creating a workstation object describing the workstation in the network tree that identifies the devices connected over the network (see paragraphs [0002] and [0018] of the published application). Registration occurs each time the workstation is started up and involves gathering information about the workstation, such as its network address (paragraphs [0003] and [0020]).

4. More specifically, according to the first embodiment (shown in Figure 1), when a user logs-in 102, the system checks 104 whether a workstation object exists. If not, an "import service" is located 116 to import the workstation, i.e. to create the object (paragraph [0021]). Certain "criteria" may be used 122 to create the object, such as how to name the workstation, where it is to be created and how user rights are to be managed (paragraph [0022]). An important aspect of the invention is that after the workstation object has been created, it is forwarded to 126 and stored 128 at the client (paragraph [0023], end). If the object already exists, the import service is used 106 to check for any changes to the workstation object, otherwise the workstation is simply registered 112 (paragraphs [0019] and [0020]).

5. According to the appellant, the feature of storing the workstation at the client limits communication between the workstation and the server during registration operations and thus reduces network traffic. For this to be achieved, the workstation object should not be forwarded to the client during the registration operations. However, Figure 1 as filed shows that this occurs by virtue of the link between registering the workstation 112/114 and forwarding the workstation object 126. The appellant attempted to file a modified Figure 1 that, among other things, did not have this link. However, although this aspect of the Figure appeared to be supported by the description, the other changes were not deemed to be unambiguously derivable from the description and the amendment was not allowed by the Board. Nevertheless, the Board concludes from this discussion that the invention indeed solves the problem of reducing network traffic.

6. A second embodiment (shown in Figure 2) is similar in overall function to the first embodiment, but adds no further details about the "criteria" used to create the workstation object.

7. A further embodiment (starting in paragraph [0036]) introduces the concept of "delegating tasks to a service", in particular delegating the creation of the workstation object to the import service. The import service is governed by a "policy" that may define rights (paragraph [0037]). The policy may contain other rules, such as that the system administrator is to be notified by e-mail that the workstation object was created (column 8, lines 10 to 16). In the Board's view, the term "policy" must be interpreted to include all the rules and rights mentioned in the description, in particular the "criteria" for creating a workstation object mentioned in connection with the first embodiment.

Main request

8. It is common ground that the method of registering the workstation of claim 1 of the main request differs from D1 by the above-mentioned feature of "forwarding the newly created workstation object to the workstation" after the import service has created it. As mentioned above, it is also agreed that this solves the problem of reducing the network traffic. The division found the solution obvious, and the appellant considers it to be inventive.

9. The examining division's reasoning at point 4.5 of the decision under appeal was as follows:

Reduction of network traffic is a well-known and recognized problem in the field of networking. A high number of well-known solutions to this problem exist, each depending on the circumstances and requirements. One of such well-known solutions is to change the locality of network objects. Such solution is, for example, proposed in Dl for application objects and application installation packages (see Dl, page 117, section "Location of the Application's Users"). Further, it is regarded as common general knowledge of the person skilled in the art of networking that localizing objects leads to reduction of network traffic. Applying such common general knowledge to workstation objects does not produce any surprising technical effects or unexpected advantages, on the contrary, all the technical effects and advantages of doing so are well-known to the skilled person and would be readily premeditated, should the circumstances so require.

The Board agrees entirely with this reasoning.

10. Moreover, the Board is not convinced that D1 does not rule out the possibility of storing the workstation object in the workstation, making this possibility all the more obvious. It appears from page 78, step 7 (or page 41, step 8) that part of the workstation import policy is to designate where the workstation objects are to be created. Apart from the "Server Container", other options are "Selected Container" and "User Container". According to page 115, lines 1 and 2, such containers can apparently be "at the same site as the application's users", i.e. at the workstation.

11. The Board is also not convinced by the appellant's counter-arguments to this reasoning.

12. The appellant states that the invention additionally solves the problem of improved security by "the ability to securely delegate tasks to services while using a policy for ensuring that access to local (e.g. protected) resources is authenticated" (point 15 of the statement of grounds) and refers to Figure 5 of the application. However, claim 1 of the main request only generally states that the import service uses "applied policy criteria", which, as mentioned above the Board interprets to include such "criteria" as how to name a workstation and where it is to be created. Similar criteria are already known from D1 (see e.g. page 34) and they do not imply any authentication aspects.

13. In the Board's view, the additional effect of reduced administrator involvement is a bonus effect following from the decision to locate the workstation object at the client side for the reasons given in the decision.

14. Concerning the argument that the trend in the industry was to move critical functions to the server, the Board notes that this is simply the other possibility that the skilled person has available. Both possibilities of locating critical functions and their respective advantages and drawbacks (e.g. "fat"/"thin" client trade-off) are known so that there is no prejudice against one of them. The skilled person would simply choose one depending on the problem to be solved. If, as here, the problem is to reduce network traffic on registration, the skilled person would in the Board's view consider locating the required data in the client as concluded by the examining division.

15. Accordingly, the Board judges that claim 1 of the main request does not involve an inventive step (Article 56 EPC 1973).

Auxiliary request

16. Claim 1 of the auxiliary request essentially adds two aspects. Firstly, before using the import service to create a workstation object, determining whether criteria exist for the workstation to be registered, including rules specifying how a workstation is to be named, where the workstation is to be created, and how user rights are to be managed. The second aspect is rather vaguely formulated, but at least defines assigning rights to the import service using a policy object and defines a set of steps to "delegate" the task of creating the workstation object by the import service.

17. However, in the Board's view, both of these aspects are covered by the workstation import policy disclosed in D1 at pages 34 and 40 to 42. In particular, this policy has rules for specifying how a workstation is to be named (page 42, step 10), where the workstation is to be created (above-mentioned page 41, step 8), and how user rights are to be managed (step 6).

18. As far as the steps of the second aspect are concerned, D1 discloses at page 34, first paragraph that the workstation registration program in the client accesses the import service, which creates the workstation object. Although this passage does not disclose that the workstation object is created at the client, it shows that the task of creating the workstation object falls under the definition of being "delegated" because it is carried out by the import service on behalf of another, i.e. the client. Thus D1 discloses step a), namely receiving a delegated task request from the workstation, the task request including requesting that a workstation object be created as a directory representation of the workstation by the import service. Moreover if, as found to be obvious, the workstation object is to be stored at the workstation, the import service must inevitably involve the steps of: b) determining a directory on the workstation that the import service may access to perform the task (the container where the workstation object is to be created), c) checking rights (it is self-evident that the service needs sufficient rights to access any directory), d) accessing the directory (implicit), e) searching a policy for criteria related to the task (page 55, "Understanding ZfD Policies" describes policies, such as the workstation import policy that have various criteria, such as login restrictions and those mentioned on pages 40 to 42), f) to h) determining whether there are any rules to be applied and applying them and performing the task (these are all implicit consequences of the previous steps). The Board is unable to discern any further differences in the claimed method.

19. When questioned at the oral proceedings before the Board how the "delegated" task differed from the task of importing a workstation by the import service in D1, the representative effectively applied argument given in connection with the main request and replied that the import service in D1 only imported workstation objects and that delegating a task enabled more precise control over the rights and better authentification. However, as is apparent from the above, the Board finds the fact that the task is "delegated" as claimed has no consequences on aspects of rights control or authentification other than those that would follow from using the conventional import service to create the workstation object at the workstation.

20. Accordingly, the Board judges that claim 1 of the auxiliary request does not involve an inventive step (Article 56 EPC 1973).

21. There being no other requests, it follows that the appeal must be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.