T 1220/10 (Storage management applications/SYMANTEC) 11-09-2014

1. Overview of the invention

The application relates to plugin applications which are computer programs bridging the interface of a storage management application (SMA) to the interfaces of other SMAs (original description paragraphs [48]; [44]; [11]; last sentence of [34]; figure 4). An SMA in the sense of the application is an interposed software layer (e.g. a volume manager; [6], [22]) to virtualise the access from hosts (e.g. storage arrays like blade servers, storage appliances, client computers or server computers; [21]) to storage resources (e.g. storage disks, storage arrays, Logical Unit Numbers/LUNs, Access Control Lists/ACLs, Host Bus Adapters/HBAs; [20]) in a storage environment (e.g. a storage area network/SAN or a TCP/IP network with iSCSI; [4], [25]). Virtuali­sation means translating intercepted storage management operation requests of the host's resources from a higher level of abstraction to a lower level of abstraction, or vice-versa for the results ([6], [22]). A hetero­geneous storage environ­ment with disparate storage resources poses the problem of interfacing with a variety of vendor provided low-level interfaces for each type of storage resources ([8]). In order to solve this problem, a so-called "second storage management application" (SMA2) translates the operations from its front-end interface to one of its back-end interfaces which are disparate, native, proprietary low-level interfaces of the storage vendors ([29]; figure 1; this translation is not claimed). If there are several SMAs in a storage environment ([46], lines 2-3), the front-end interfaces of these SMAs can be different ([10]) which requires a further translation taking place before: A first SMA (SMA1) is added on top of the then second level SMAs (SMA2s). It receives the original request from the host and transmits it to a plugin application that translates the request to a format of the front-end interface of the concerned one of the SMA2s, called second storage management application (SMA2; [30]). The results of the storage operation are communicated back from SMA2 to SMA1 (250 in figure 2; [31]).

To summarise, the plugin application bridges (one) SMA1 with (several) SMA2s ([48]) in order to provide a single SMA (i.e. SMA1) which copes with all the interfaces of the SMA2s ([10], lines 6-11).

2. Overview of the decision

2.1 Claim 1 of the two requests satisfies the requirements of Article 123(2) EPC.

2.2 Claim 1 of the two requests lacks an inventive step (Article 56 EPC).

3. Original disclosure

3.1 According to the appealed decision (4.), the features of different front-end and back-end interfaces and of a plurality of SMAs are not originally disclosed. These features are no longer present in the two requests.

3.2 Claim 1 of the main request contains some amendments over the refused claim 1. Compared with original claim 1, present claim 1 contains the following features in addition which are all disclosed in [30] and [31]:

- SMA1 detecting a resource associated with the operation request ([30], lines 6-8);

- SMA1 detecting that the resource is controlled by SMA2 ([30], line 8 in combination with [28], lines 1-4);

- SMA2 includes a front-end interface for receiving requests ([30], lines 9-12)

- and a back-end interface to one ore more resources including the resource (lines 12-16);

- SMA1 accessing a plugin interface to acquire an appropriate plugin application

that is capable of translating the request into a format recognised by the front-end interface of SMA2 (lines 9-12),

- wherein the accessing causes the request to be translated by the plugin application (lines 9-12)

- and conveyed to the front-end interface of SMA2 (lines 9-12),

- which in turn performs the operation on the resource via the back-end interface (lines 12-16);

- SMA1 receiving results ([31], lines 1-3).

The board notes that claim 1 relates to the embodiment disclosed in particular in paragraphs [30] and [31] of the description, a point relevant to the appellant's argumentation - see below.

The feature of original claim 1 of passing the operation from SMA1 to SMA2 using an interface associated with SMA2 has been refined to the current feature of (implicitly) passing the request to the plugin application which translates it into a format recognised by the front-end interface of SMA2 and conveys it to the front-end interface of SMA2.

3.3 Claim 1 of the auxiliary request has two features in addition to the main request:

- a plurality of SMA2s: "[1. A method for communi­ca­ting within a storage environment from a first storage management application] to one of a plurality of storage management applications [SMA2s], the plurality of storage management applications including a second storage management application [SMA2]"; and

- the SMA2s having different front-end interfaces: "the first front-end interface of the second storage management application being different than the front-end interface of another of the second storage management applications;" (at the end of the step of performing).

3.4 As to the first feature ("plurality of SMA2s"), the board disagrees with the appealed decision (4.) and is of the opinion that it is originally disclosed in [48], first sentence which states that the "invention provides plugin applications that bridge one storage management application with other storage management applications." SMA1 is referred to in the singular, while both the plugins and the SMA2s are referred to in the plural..

3.5 The second feature ("the SMA2s having different front-end interfaces") also follows from that passage ([48]): If the SMA2s did not have different front-end interfaces, there would be no need for more than one plugin application translating to them.

3.6 Thus, claim 1 of the two requests satisfies the require­ments of Article 123(2) EPC.

4. Inventiveness of claim 1 of the main request

4.1 The board considers D1 to be the closest available prior art for the purpose of examining the question of inventiveness, as it was in the appealed decision.

4.2 As a preliminary, the board considers that the volume providers and volume manager of D1 qualify as SMAs in the sense of the present application - see paragraphs [4], [6], [20]-[22] and [25]. Thus the board does not accept the appellant's arguments on this point, the reasons being given in more detail below.

4.3 D1 discloses a method of managing a plurality of volume providers (203 in figure 3; page 11, paragraph 3), consisting of software and hardware volume providers (204 and 206 in figure 3), in a storage management system (200 in figure 3) through a common volume manager (202 in figure 3). The common volume manager provides a unified view (page 11, line 16 - page 12, line 1) to applications (210 in figure 3) for accessing and configuring storage devices (106 in figure 3) in the storage network. It presents an interface (209 in figure 3) to applications through which it receives requests for accessing the storage devices (page 12, lines 1-2; page 12, line 28 - page 13, line 12; 404 in figure 4; page 15, lines 19-21). Having received such a request, the common volume manager generates one or more commands necessary to execute said request and issues these commands to appropriate volume managers (405 and 406 in figure 4; page 15, lines 22-27) via an interface (208 in figure 3) to which each volume provider is required to conform to (page 13, lines 13-16). Volume providers convert these commands to standard or vendor-specific protocol requests (page 13, lines 16-18; page 14, lines 2-7) and communicate them to storage devices for processing (406 in figure 4; page 15, lines 27-28). After processing the commands, the volume providers communicate response information to common volume manager (408 in figure 4; page 16, lines 3-4) which aggregates the information and communicates to the requesting application (410 and 412 in figure 4; page 16, lines 10-12).

4.4 The grounds (page 4, 7., second sentence) state that "the applicant does not believe that D1 is relevant when applying the Problem-Solution approach to the present invention". Further (page 4, paragraph 2; page 3, last paragraph), that D1 teaches away from the invention, since the front-end interfaces of the volume providers (i.e. of the SMA2s) are required to be compliant with a single interface (208) so that there is no need for plugin applications translating the requests from the common volume manager (202; i.e. SMA1) to the SMA2s. On the other hand, the invention allows to keep the interfaces of the SMA2s as they are. Thus D1 fails to provide any motivation to arrive at the invention (page 4, paragraph 2).

4.5 However, the board is of the opinion that a document serving as an appropriate starting point for the problem-solution approach ("closest prior art") does not have to provide the (technical) moti­vation to arrive at the invention starting from that document. The motivation may arise from any source, as long as it would in fact arise.

4.6 In this case however, the motivation to modify D1 in order to cope with different front-end interfaces of the SMA2s is not even a technical, but instead an administrative or commercial one: it is the aim of reusing existing SMA2 programs as they are, i.e. with their vendor-specific front-end interfaces (see grounds, page 3, middle of last paragraph: "the vendors may not be willing to change the front-end interface of their SMA"). Technically, there is no need to reuse existing programs. There is no (technical) problem in using newly programmed SMA2 programs with a common interface. It is simply more expensive and causes more work.

4.7 Furthermore, the board does not consider it necessary for a document to qualify as closest prior art that it explicitly discloses the disadvantages associated with the system or method it discloses, especially where those disadvantages arise from an administrative or commercial aim different from that which it contemplates.

4.8 Be that as it may, the board agrees with the appellant that it is very likely that the skilled person would encounter the problem that the vendors were not willing to change the front-end interface of their SMA. But this is a problem that the skilled person starting from D1 and wishing to increase the flexibility of the system by connecting storage systems from different vendors would encounter just as much as in "the environment of the present invention", as it is put in the grounds. The desire to connect storage systems from different vendors is both a commercial aim (which according to the established case law, e.g. T 641/00, Comvik, may be used in the formulation of the technical problem) and in the view of the board an everyday requirement arising naturally.

4.9 In its letter dated 6 August 2014, filed after the summons to oral proceedings, the appellant gave further arguments as to why D1 does not qualify as closest prior art. It points to case law of te Boards of Appeal requiring that e.g. "the most suitable starting point to be selected ... is ... a document dealing with the same technical problem as the claimed invention," (T 0859/03). It then argues that D1 is not concerned with the same problem as the claimed invention, "which as proposed by the Board is: how to enable the common volume manager (203; SMA1) of D1 to communicate with volume providers (203; SMA2s) which do not conform to its its interface (annex at 5.14)."

4.10 However, the board is not convinced by these arguments. Firstly, in common with much other case law, the board takes the view that it is not critical whether or not a given document is the absolute and only closest prior art. There may indeed be more than one available document which could be selected as the closest prior art in the sense of a starting point for the problem-and-solution approach to be applied. In this case the board has been presented with D1 as the closest prior art in that the examining division chose to base its decision on this document. It is incumbent on the board to investigate whether the invention is indeed lacking an inventive step with respect to this document. While that investigation may require the board to consider whether the document is at all a suitable starting point for the approach, it does not require an assessment of whether there might not be an even better one. If D1 is a suitable starting point and the claimed invention lacks an inventive step with respect to D1, that is sufficient; the board needs to go no further to decide the question. Secondly, the board considers that the appellant has misinterpreted the "problem" being referred to in the case law. The appellant has specified this problem as what the board identified as the objective technical problem solved by the claimed invention, i.e. precisely the problem inferred from the difference between D1 and the claimed invention. Requiring that the closest prior art document be concerned with, i.e. solve or at least try to solve, the same problem as that identified by the problem-solution approach applied to that document, would lead to the absurdity that the only documents which could be considered for inventiveness were such as had tried to solve exactly that problem and had either failed or, possibly, provided an alternative solution. The board takes the view rather that the common "problem" which is referred to in this context in the case law is the general aim of the invention as disclosed in the application, which is often referred to in decisions as the problem "underlying" the application. In this sense the problem underlying the present application is given in paragraph [3], "The present invention is related to software bridges ... that bridge storage management services in a shared storage environment." More specifically, using the terminology of the application, the problem might be formulated as, "how to enable an SMA1 to communicate with several SMA2s", which is the same problem as is dealt with in D1. Thus, the subject-matter of D1 is conceived for the same purpose of connecting SMA1 with different SMA2s as the application.

4.11 Therefore, the board cannot see any convincing reason why it should not take D1 as closest prior art, and moreover considers it a naturally arising problem that the skilled person would want to be able to access different storage systems which present different interfaces.

4.12 The board agrees with the appealed decision (page 4, paragraph 2) that claim 1 differs from D1 in that SMA1 accesses a plugin interface to acquire a plugin application which translates the requests for the concerned SMA2.

4.13 The grounds of appeal state further differences under section 8. However, the board finds the statements in this section contradictory and cannot identify any further feature of claim 1 in this passage which is not disclosed in D1. It is argued for example (8., para­graph 2) that "it is not appropriate to consider both the common volume manager (202) and the volume pro­viders (203) of D1 as storage management appli­ca­tions of the present invention." However, the description ([22], lines 5-6) discloses volume managers as one type of SMAs.

Thus, the common volume manager qualifies as an SMA.

4.14 Furthermore, the volume providers together with the software drivers and the hardware drivers (D1, figure 3; page 2, paragraph 2) operate directly on the storage devices in the same way as the SMA2s do (application, figure 1). For example, volume providers convert operations from their input interface (208) to industry standard or vendor-specific requests (D1, page 13, paragraph 2, third sentence) in the same way as the application ([29]).

Therefore, the volume providers (if need be: in combination with the drivers) qualify as SMA2s.

4.15 The grounds (8., paragraph 3) further argue:

"This common volume manager does not have any back-end interface to storage resources. In other words, the common volume manager is a volume providers (203) manager, not a storage resources (106) manager. Consequently, the common volume manager of D1 cannot be reasonably considered as a storage management application of the present invention ..."

4.16 However, using the same line of argumentation, since SMA1 of the claim also does not have any back-end interface to storage resources, it would be a SMA2s' manager and not be itself an SMA. Thus, this is contradictory.

4.17 The board considers the objective technical problem of the decision (page 4, last but one paragraph), namely "how to increase flexibility in storage interface modification", to be too general. It would rather formulate the problem as "how to enable the common volume manager (202; SMA1) of D1 to communicate with volume providers (203; SMA2s) which do not conform to its interface (208)".

4.18 The board agrees with the decision that the claimed solution (i.e. SMA1 accessing a plugin interface to acquire a plugin application for the translation step) does not involve an inventive step: Assume that person A wants to communicate with person B. But B refuses to communicate in A's language. Then A either has to communicate in B's language or use the services of a translator. Faced with the objective technical problem formulated above, the skilled person would have to extend the functio­nality of the volume manager (SMA1) accordingly.

4.19 The board further agrees with the decision (paragraph bridging pages 5 and 6) that plugins are known in the art to "introduce flexibility", i.e. to extend the functionality of a software. An example of using plugins can be found in D2 (decision page 5, line 2: "as shown for instance [in] document D2, ..."), but the board does not even consider it necessary to combine D1 with D2, since plugins belonged to the general knowledge of the skilled person at the current priority date. The appellant has indeed accepted, in its response to the summons to oral proceedings, that plugins were known generally in the state of the art (page 3, paragraph 7).

4.20 That this is so is clear from the application itself which tells the addressee to use a plugin interface without any further explanation of what a plugin, or plugin interface, is. If hypothetically the board were to assume that plugins were not part of the common general knowledge in the art, the application would clearly violate Article 83 EPC, i.e. it would not disclose the invention in a manner sufficiently clear and complete for it to be carried out by a person skilled in the art. Thus, the skilled person would find it obvious to add the necessary translating functionality as a plugin application to SMA1.

4.21 Therefore, claim 1 of the main request is not inventive in the sense of Article 56 EPC.

5. Inventiveness of claim 1 of the auxiliary request

5.1 As stated above in the section about original disclosure, claim 1 of the auxiliary requests contains the following features in addition to claim 1 of the main request:

- a plurality of SMA2s, and

- the SMA2s having different front-end interfaces.

5.2 The first feature however is disclosed in D1 where SMA2 is likewise one of a plurality of SMAs (203, 204 and 206 in figure 3; page 11, lines 16-18, lines 22-24).

5.3 As to the second feature ("different front-end interfaces"), it is clear from the reasoning of the board concerning inventive step of the main request (see for example the objective technical problem: "how to enable the common volume manager (202; SMA1) of D1 to communicate with volume providers (203; SMA2s) which do not conform to its interface (208)") that the method of the main request also works for different front-end interfaces of the SMA2s. In analogy to the above stated "A wants to communicate with B, but B refuses to communicate in A's language, then A either has to communicate in B's language or use the services of a translator", the auxiliary request merely describes the situation where you need several translators.

5.4 The grounds (30., 38. and 46.) do not give any specific arguments why claim 1 of the then fourth auxiliary request (which is similar to claim 1 of the auxiliary request) should be inventive.

5.5 The appellant argues in his letter dated 6 August 2014 (page 5, paragraph starting with "Accordingly") that "it is clear that D1 provides no suggestion of allowing the use of two second storage management applications that have differing front-end interfaces, as claimed".

5.6 As argued above for the main request, the board does not even consider it necessary that D1 mentions the non-technical aim (i.e. the reuse of existing SMA2 programs) which will be the motivation to modify it.

5.7 Therefore, claim 1 of the auxiliary request is not inventive in the sense of Article 56 EPC for essentially the same reasons as the main request.