|European Case Law Identifier:||ECLI:EP:BA:2018:T187212.20181018|
|Date of decision:||18 October 2018|
|Case number:||T 1872/12|
|IPC class:||G06F 9/445
|Language of proceedings:||EN|
|Download and more information:||
|Title of application:||A system and method for automatically establishing a resource grid|
|Applicant name:||Oracle America, Inc.|
|Relevant legal provisions:||
|Keywords:||Inventive step - (no)|
Summary of Facts and Submissions
I. The appeal is directed against the decision of the examining division, dated 16 February 2012, to refuse application No. 04255302.4 for lack of clarity (Article 84 EPC) and lack of inventive step (Article 56 EPC). For its reasons, the decision ("according to the state of the file") referred back to the annex to the summons for oral proceedings, dated 2 December 2011.
II. A notice of appeal was received on 20 March 2012. The appeal fee was paid on the same day. A statement of grounds of appeal was received on 8 June 2012. Claim sets according to a main and an auxiliary request were filed.
III. In a communication dated 19 February 2018, the rapporteur raised an objection of lack of inventive step.
IV. In a letter dated 30 April 2018, the appellant submitted arguments and deleted several dependent claims in the auxiliary request.
V. In its summons to oral proceedings, the board maintained the objection of lack of inventive step.
VI. Oral proceedings were held on 18 October 2018. At their end the board announced its decision.
VII. The appellant requests that the decision be set aside and that a patent be granted based on the main request filed with the grounds of appeal or the auxiliary request filed on 30 April 2018. The other application documents are the same as in the appealed decision.
VIII. Claim 1 of the main request reads as follows:
"1. A method implemented by a grid establishment component for automatically establishing a resource grid for a plurality of nodes (206) coupled together via an interconnect (204), the method comprising:
determining (104), from the plurality of nodes, a set of grid nodes to include in a resource grid, wherein each grid node provides zero or more resources; and establishing (108) the resource grid, wherein said establishing comprises: configuring (112) each grid node to enable that grid node to participate as part of the resource grid; andestablishing (116) one or more grid masters to manage access to the resources provided by the grid nodes, such that the resource grid formed by the grid nodes behaves as a single pool of resources accessible through the one or more grid masters;wherein configuring a grid node to enable that grid node to participate as part of the resource grid comprises:causing the grid node to execute a grid facilitation agent (210) thereon;deploying a grid participation module (212) to the grid facilitation agent executing on the grid node; and instructing the grid facilitation agent to run the grid participation module on the grid node to enable the grid node to participate as part of the resource grid."
IX. In claim 1 of the auxiliary request, the following wording is added at the end:
"[to enable the grid node to participate as part of the resource grid;]
wherein causing the grid node to execute a grid facilitation agent thereon comprises:
deploying a grid facilitation agent to an operating system running on the grid node; and
instructing the operating system to run the grid facilitation agent on the grid node;
and wherein each of the plurality of nodes has an operating system running thereon,
and wherein determining the set of grid nodes comprises:
determining, for each of the plurality of nodes, whether the grid establishment component has sufficient privileged access to the operating system running on that node to deploy the grid facilitation agent to that operating system; and
in response to a determination that the grid establishment component has sufficient privileged access to that operating system, selecting that node as one of the grid nodes."
Reasons for the Decision
1. Summary of the invention
1.1 The application relates to configuring a so-called "resource grid". The term "grid" is commonly known to designate a system of loosely coupled, distributed, geographically dispersed, interconnected and potentially heterogeneous computers (see for example https://en.wikipedia.org/wiki/Grid_computing). A "resource grid" is defined to be a collection of cooperating "nodes" (A2-publication, section , second sentence). A node may be a computer or a peripheral (, fourth sentence). The interpretation of a node being a "software process" (same sentence) is not consistent with the claimed invention, since a process can neither be rebooted (claim 2 of the main request), nor does it have ports (claim 3). Therefore, the board understands a node to be a computer or to contain a computer, since a node executes a program (the so-called "grid facilitation agent"; claim 1). It follows that a "resource grid" is essentially a grid.
1.2 The configuration is performed by a so-called "grid establishment component" (GEC; , first sentence) which is interconnected to the nodes (see figures 2A-4B). A GEC can be an ASIC (i.e. an application-specific integrated circuit; see , second sentence) or a computer (same sentence: "one or more processors") running a specific program (same sentence: "a set of instructions") for "automating ... the process of establishing a resource grid" (, first sentence). In figure 5, a computer is shown which may be used for a GEC (see , second sentence). However, even if the GEC is implemented as an ASIC, it behaves like a computer. For example, it is interconnected to the nodes and deploys software to them ( and ).
1.3 In order to enable a node to participate in a grid, two-part software is installed on a grid node: the so-called "grid facilitation agent"/GFA for receiving, installing, configuring and running the second part, namely the so-called "grid participation module"/GPM. This is shown in three embodiments (called "sample implementations").
1.3.1 First embodiment (-): The node receives via "network reboot" from the GEC an operating system (OS) image containing a GFA and boots it (see , sentences 1-8). The GEC then deploys the GPM to the running GFA (i.e. via the GFA on the node; , third sentence; , first sentence; , seventh sentence).
1.3.2 Second embodiment (-; claimed in the auxiliary request): The node has already an OS running on it which is capable of allowing other computers to install and run programs on the node (, fifth sentence). The GEC first deploys the GFA and then the GPM to the node (, fourth sentence; , first sentence).
1.3.3 Third embodiment (-; not claimed): The node already has an OS and a GFA running on it (, last sentence; , sentences 4-6; , second sentence). Only a GPM is deployed to the node by the GEC (, third sentence).
This embodiment is not claimed, since in claim 1 of both requests the GEC causes the grid node to execute the GFA, whereas in the embodiment there is no such step (the GFA is already running before the GEC communicates with the node; see for example , second and third sentence: determining which node belongs to the grid is done by determining the nodes on which the GFA is already installed and running).
2. Overview of the board's decision
2.1 The board agrees with the appealed decision that the claimed subject-matter lacks inventive step, Article 56 EPC 1973. However, for reasons of procedural economy (by simplifying the argumentation), the board prefers not to use the closest prior art document of the decision, but the prior art acknowledged in the description (sections  and ).
2.2 In the following, only the auxiliary request is analysed for inventive step, since it is more concrete and narrower than the main request. Therefore, a lack of inventive step of the auxiliary request also applies to the main request.
3.1 The subject-matter of claim 1 of the auxiliary request can be summarised as follows:
a GEC computer automatically establishes a grid by
- selecting as a grid node each node interconnected to the GEC which provides the GEC with access rights to its (running) operating system to deploy programs on the node (see , third and fourth sentence);
- establishing (one or more) grid masters which manage access to the grid nodes (and its resources);
- deploying a GFA program on each grid node;
- starting the GFA program on each grid node;
- deploying a GPM program to the GFA program on each grid node and
- starting the GPM program by the GFA program on each grid node to let the grid node participate in the grid.
3.2 Except for two points, namely how to select the grid nodes and the dividing of the grid node software into two parts, these steps (i.e. establishing grid masters, deploying software to the grid nodes and starting it) are what a human system administrator usually does when establishing a well-known master-slave grid ( and ). He or she has to determine the masters and the slaves, and also has to make sure that the necessary software to participate in the grid is installed on the nodes, as acknowledged in the description, section  which reads:
"Currently, the process of implementing a resource grid is quite labor and time intensive from the standpoint of a system administrator. Specifically, the administrator has to perform a number of manual tasks on each node of a resource grid to enable that node to function as part of the resource grid. These manual tasks include, for example, manually accessing each node, loading grid participation software into each node, configuring and running the grid participation software, and setting a node to be a slave node, a master node, or both. These manual tasks can require a significant amount of time to perform, and since they have to be performed on every node, the amount of administrator time required to set up an entire resource grid can be substantial, especially if the resource grid comprises a large number of nodes." (emphasis added by the board)
3.3 However, performing these steps on a computer (i.e. the GEC) results in a mere automation of the usual behaviour of a human system administrator in establishing and configuring a grid, see T780/11 of the same board, section 3.9 (citing T634/01, section 6) and 3.10. Furthermore, no technical effect going beyond the usual effects of establishing and configuring a grid and its nodes can be recognised.
3.4 As to the way in which grid nodes are selected by the GEC (i.e. the first of the two points mentioned above), namely by selecting each node as a grid node which offers the GEC access to its OS to deploy programs on the node, it is first noted that such an access is indispensable for the GEC in order to install the grid node software on the node. Secondly, this selection method merely describes a convention amongst (human) system administrators of the (possibly world-wide dispersed) grid nodes which are interconnected to the GEC, namely to express the acceptance of a node's potential adherence to a grid by configuring the OS of the node such that it allows the GEC to deploy and start software on that node. Thus, to program the GEC such that it selects the grid nodes depending on the access rights to the nodes is again a mere automation of what the human administrator of the GEC does when establishing a grid according to this convention.
3.5 During oral proceedings, the appellant argued that the description contained three different embodiments with different ways of selecting the grid nodes. This showed that the selection was not straightforward and not performed in the same way by every human system administrator. Thus, the claim went beyond a mere automation.
3.6 However, the fact that there are several ways to do something does not mean that one (or all) of them are non-obvious. They could all be obvious. In the present case, only the way of the second embodiment claimed in the auxiliary request has to be analysed. This has been done above, and the board came to the conclusion that this specific way of selecting a grid node is obvious. Merely automating this obviously selected way cannot establish an inventive step.
3.7 The second point mentioned above is that the software to be deployed by the GEC to the grid nodes is divided into two parts (GFA and GPM). However, this partitioning does not produce a technical effect going beyond the effects that partitioning methods typically have, see T1541/16 from the same board, section 2.8 (and also 2.6).
3.8 In particular, the invention seems to suggest that deploying the GPM program to the already deployed and started GFA program, and starting it by the latter on the node would be different from simply deploying/starting the GPM program after having deployed/started the GFA program. The board cannot see a technical effect arising from such a methodology, since the GEC has sufficient access to install any program on the grid node. The GEC does not need the GFA program to deploy and start the GPM program via or by the GFA program.
3.9 During oral proceedings, the appellant argued that dividing the prior art grid participation software (, third sentence) into two parts makes it possible to concentrate the functionality common to both, master and slave nodes, into one part (GFA), and the functionalities specific to either a master or a slave into the other part (GPM). This reduced maintenance costs, since the common functionality would not have to be duplicated in both, the master grid participation software and the slave one.
3.10 However, the board considers this to be a typical example of applying the general principle of partitioning software. It belongs to the daily work of a programmer to identify common functionality in different programs and to isolate it in a separate part, in order to combine it later on with the remaining programs (i.e. where the common functionality has been deleted). This well-known methodology would have the same effects here as it usually has.
3.11 Moreover, the description is completely silent about these effects. There is only one passage in the relevant second embodiment (, last two sentences) about the possibility of having different programs for master and slave. It reads:
"In one embodiment, the GPM 312 is the same module for both slave and master operation, with the module being configured differently, depending upon the intended mode of operation. As an alternative, different GPMs 312 may be deployed for slave and master operation."
There is neither a mention of having a common functionality in the GFA program, nor of the reasons for doing it one way or the other.
3.12 The appellant further argued that creating two-part grid software allowed the existing grid participation software (, third sentence) to be reused in unchanged form.
3.13 However, also this statement and its possible effects are not mentioned in the description and seem to be speculative. Furthermore, the board cannot recognise any unexpected advantage in reusing software in unchanged form, instead of, for example, reusing the program text of the existing grid participation software in a one-pice program comprising the functionality of both, the GFA and the GPM. Both approaches have their known advantages and disadvantages.
3.14 Thus, there is no technical effect produced by partitioning the grid node software into two parts which would go beyond the effects that partitioning typically has. Nor is any such technical effect described in the description.
3.15 Therefore, the subject-matter of claim 1 of the auxiliary request is not inventive (Article 56 EPC 1973).
3.16 The same argumentation applies to claim 1 of the main request, since it is broader than that of the auxiliary request.
For these reasons it is decided that:
The appeal is dismissed.