T 0827/13 (Providing cloud storage/SAMSUNG ELECTRONICS) 26-11-2018

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

The invention

2. The application relates to the processing of a file access request from an application in a cloud computing system (originally filed description, page 1, lines 6 and 7, and page 2, lines 5 to 10).

According to the application, cloud computing is a computing paradigm in which IT-related functions are supported in the form of services that are transmitted over a network. Cloud computing allows users to easily access desired services such as file storage over the internet, even if they do not possess particular knowledge regarding the technical infrastructures that are supported by the cloud computing system (description, page 1, lines 10 to 21). However, in known systems, clients are only allowed access to particular remote storages which are statically mounted (description, page 1, line 22, to page 2, line 2).

3. The application proposes using a brokerage server between the client and the cloud storage (see Figure 1), to which the client sends file access requests which do not access the local storage, but the cloud storage (Figures 1 to 3).

The brokerage server provides metadata in the form of file lists describing the files stored in the cloud storages to the client. For this purpose, the metadata manager of the brokerage server may manage file lists for each client (description, page 12, lines 11 to 18).

If an application of the client issues a file read request, the client storage manager searches for the location of the corresponding file. The client storage manager may determine whether the file is located in the local storage or in cloud storage, according to a file list for cloud storages received from the brokerage server, which is stored in the client's cache (description, page 14, line 21, to page 15, line 5).

Sole request

4. Claim 1 relates to a brokerage server for supporting a client, which comprises the following features, as itemised by the Board:

(a) the brokerage server being configured to be connected through the internet to the client and through the internet to at least one cloud storage;

(b) a server storage manager adapted to receive a cloud file access request for accessing the cloud storage from the client;

(c) a metadata manager to manage metadata including information about files stored in the cloud storage, this information including information indicating which cloud storage the files are stored in, and a storage location of the file in that cloud storage, the metadata manager being configured to manage lists of files associated with each client and to provide these file lists to a client storage manager of the client via the server storage manager at regular time intervals or in response to a request from the client storage manager;

(d) a storage broker for supporting brokerage between at least one cloud storage and the client, the storage broker being adapted to select at least one cloud storage suitable for processing the cloud file access request from among a plurality of cloud storages in a cloud infrastructure connected through the internet using at least one of the data attributes included in the file access request and the metadata;

(e) an interface adaptor adapted to convert the file operation of the file access request received from the client into a file operation suitable for an interface of the selected cloud storage and to convert the result of processing the file access request received from the selected cloud storage into a data format interpretable by the client;

(f) wherein the server storage manager is adapted to transfer the result of processing the file access request to the client.

5. Added subject-matter - Article 123(2) EPC

5.1 The current request is an amended version of the then first auxiliary request decided upon by the Examining Division. Claim 1 of the latter request was essentially based on originally filed claims 7 and 8 and Figure 1. The present claim 1 differs from claim 1 of the first auxiliary request considered in the decision under appeal as follows: Feature (a) of claim 1 was added on the basis of the description as originally filed, page 6, line 22, to page 7, line 5. The metadata manager according to feature (c) was further specified on the basis of the description as originally filed, page 11, lines 4 to 9, page 12, lines 3 to 14, and page 15, lines 6 to 10. The storage broker feature (d) was amended on the basis of the description, page 3, line 22, to page 4, line 2, and page 7, lines 3 to 5.

5.2 The further independent claims 7 and 11 have been amended to correspond as far as possible to the subject-matter of claim 1. Claim 7 is based on original claims 1 to 5 and the description as originally filed, page 10, lines 11 to 14, page 14, line 21, to page 15, line 4, Figure 4. Method claim 11 is based on the description as originally filed, page 3, line 22, to page 4, line 2, and page 10, lines 11 to 14, and original claims 1 to 5, 8, 13 and 14.

Claim 10 is directed to a system (see Figure 1, for example) which includes a brokerage server according to claims 1 to 6 and a client according to claim 7.

5.3 In view of the above, the Board concludes that independent claims 1, 7, 10 and 11 meet the requirements of Article 123(2) EPC.

6. Novelty and inventive step - Articles 54 and 56 EPC

6.1 The Examining Division assessed novelty and inventive step over document D1, which discloses systems and methods for hierarchical storage management (D1, abstract). A hierarchical storage system typically administers the placement of data sets into a hierarchy of storage devices. The hierarchy of storage devices may include a wide range of devices such as high-end, high-throughput magnetic disks, collections of normal disks, jukeboxes of optical disks, tape silos, and collections of tapes that are stored off-line in either local or remote storage. When deciding where data sets should be stored, hierarchical storage systems typically balance various considerations, such as the cost of storing the data, the time of retrieval, the frequency of access, and so forth. Typically, the most important factors are the length of time since the data was last accessed and the size of the data (D1, column 1, lines 34 to 50).

D1 explains that in prior-art systems, hierarchical storage systems sometimes remove files from primary local storage and migrate them to remote storage and leave a "stub file" in their place at the local storage. Stub files typically contain information that allows the hierarchical storage system to determine where and at what time the data in the file was migrated. In general, the process of migrating data from local storage to remote storage involves identifying files that have met particular migration criteria, migrating the data from local to remote storage, deleting the data from local storage, and replacing the deleted data in the local storage with an appropriate stub file (D1, column 1, lines 55 to 66).

In the system proposed in D1, data migration begins with the hierarchical storage system identifying candidates that will meet a designated migration policy at an identified time in the future. The migration policy may be any traditional migration policy and may utilise any number of factors to determine when data should be migrated from local storage to remote storage. For example, files may be migrated from local storage to remote storage after the files have not been accessed for a designated period of time (D1, column 4, lines 39 to 50).

After the hierarchical storage manager, which is implemented on the client (D1, Figure 9), has determined which attributes are to be stored remotely, the attributes may be safely removed from the file if migration occurs. In addition, the hierarchical storage manager adds a remote storage attribute to the system attributes of the file. The system attributes are those attributes used primarily or exclusively by the operating system and the input/output (I/O) system to store information necessary or useful to allow the operating system and I/O system to perform their various tasks. The remote storage attribute is generally used to store whatever information is needed by the hierarchical storage manager to identify where remotely stored attributes are located (D1, column 16, lines 14 to 30; column 14, lines 25 to 31).

6.2 Even though the system in D1 deals with the migration of files in a hierarchical storage system and not with a cloud file storage service, at least some of the functionality implemented by the brokerage server of claim 1 can be mapped to the functionality of the hierarchical storage manager of D1 (see D1, column 9, lines 38 to 43; column 13, lines 14 to 27 and 41 to 49; Figures 4 to 6 and 9) as explained in detail below.

6.2.1 D1 already discloses the use of internet connections (D1, column 9, lines 33 to 43) and remote, networked communication with the remote storage (D1, column 13, lines 36 to 49). It also discloses that the hierarchical storage manager accesses remote storage (D1, Figure 9). While D1 may suggest connecting to the remote storage via the internet, it does not disclose feature (a).

6.2.2 The functionality of the server storage manager according to feature (b) can be mapped to corresponding functionality of the hierarchical storage manager, with the difference that in D1 a file access request is received, but not a "cloud file access request" (D1, column 13, lines 14 to 16; column 30, lines 58 to 61; column 31, lines 9 to 23; column 32, lines 2 to 16).

6.2.3 The hierarchical storage manager manages metadata about files stored remotely in a "remote data table" (D1, column 13, lines 52 to 61; Figure 4). Hence it can be partially mapped to the metadata manager according to feature (c) of claim 1. However, document D1 fails to disclose that the metadata manager manages file lists associated with different clients and provides these file lists to a client's storage manager via the server storage manager at regular time intervals or in response to a request from the client storage manager.

6.2.4 The hierarchical storage manager of D1 is responsible for determining which attributes of a file should be stored remotely. It decides on which remote storage devices (such as disks, tapes etc.) the remotely stored attributes should be stored (D1, column 14, lines 36 to 40; column 15, lines 4 to 20 and 46 to 55). According to D1, column 15, lines 46 to 55, the remotely stored attributes from a particular file need not be stored in the same location or even on the same type of remote storage device. Consequently, when the hierarchical storage manager, in response to a file access request, accesses a file with attributes stored on one or more remote storage devices, the hierarchical storage manager needs to select and access one or more of these remote storage devices, depending on which attributes of the file are to be accessed (D1, Figure 6; column 19, lines 1 to 13; column 30, lines 51 to 54; column 32, lines 4 to 16). In D1, it is not the hierarchical storage manager which identifies file requests involving a file with migrated data. This is done by a file system driver by examining the remote storage attribute which is found in the local file system. The remote storage attribute may then be passed to the hierarchical storage manager (D1, column 31, lines 9 to 23; column 18, lines 16 to 36).

Consequently, document D1 discloses a storage broker according to feature (d) of claim 1, with the exception that in D1 the file access request is not for a cloud infrastructure connected through the internet.

6.2.5 The hierarchical storage manager intervenes for an I/O request to access a file with migrated data, and generates a new I/O request package that is passed to a remote storage driver which retrieves the requested information from remote storage (D1, column 31, lines 9 to 23; column 32, lines 4 to 16; Figure 9). As the hierarchical storage manager needs to access different remote storage devices such as tapes or disks, it is implicit that the I/O request, and thus the file operation, needs to be converted into a format suitable to access the relevant remote device.

In the statement of grounds of appeal (page 5, second paragraph), the appellant argued that in D1 there was no conversion of a file operation of the file access request into a file operation that was appropriate for the specific interface of the selected cloud storage, as the remote storage devices of D1 would have the same interface. However, this argument is not convincing as D1 explicitly discloses access to different kinds of remote storage devices.

D1 also discloses that the result of an I/O request to access a file is transferred back to the client (D1, column 32, lines 21 to 26). Hence, D1 discloses features (e) and (f) of claim 1.

6.3 Consequently, the subject-matter of claim 1 differs from the system disclosed in document D1 as follows:

(i) the file access request is a cloud file access request;

(ii) the brokerage server is configured to be connected through the internet to the client and through the internet to at least one cloud storage;

(iii) the metadata manager is configured to manage lists of files associated with each client and to provide these file lists to a client storage manager of the client via the server storage manager at regular time intervals or in response to a request from the client storage manager.

6.4 These differences contribute to creating a cloud storage service which allows clients to remotely access storage capability on the internet. Hence, the problem can be formulated as how to provide remote file storage services in the hierarchical storage management system of D1.

6.5 The skilled person faced with this problem would certainly consider using the internet as a wide area network to connect to remote storage systems. In view of the fact that D1 already explicitly suggests executing program modules remotely (D1, column 8, lines 25 to 37) and since the offloading of functionality from a client computer to a separate server computer is well-known, the Board considers that it was also obvious to separate the hierarchical storage manager functionality, at least in part, from the client to a separate server. Hence, the skilled person would arrive at the features according to differences (i) and (ii) without the exercise of inventive skill.

However, when the skilled person implements a part of the functionality of the hierarchical storage manager of D1 on a separate server, the skilled person would continue to store the file metadata, in particular the remote storage attribute, in the local file system. There is no evident motivation for the skilled person to change the approach of storing the file metadata in the local file system to a completely different approach such as storing all the metadata concerning files stored in the cloud infrastructure on a remote server, as the system of D1 is optimised to access files stored locally and as it supports the local and/or remote storage of different parts of a single file. As the system of D1 already stores the metadata needed by the client locally on the client in the stub files, there is no reason why the skilled person, when starting from document D1, would consider implementing difference (iii), i.e. managing client-specific file lists at the brokerage server and providing these file lists to the client.

6.6 In its decision, the Examining Division also cited document D2, which discloses a system that allows a practically infinite number of physically separate storage devices to be used as archival storage means by one or more application programs. Application data is organised among the devices such that files with a similar expiry date (the date beyond which the files are no longer required to be archived) are grouped together on the same physical device, such that after the expiry date, the device used for such files may be erased and re-used (D2, paragraph [0019]). A broker application maintains a device table with each row of the table corresponding to a single storage device, and each column corresponding to various configuration and status conditions of the storage devices (D2, paragraph [0036], Figure 3). The broker uses this device table to determine which device a given file should be written to (D2, paragraph [0049]).

The skilled person does not obtain any hint from D2 which would point him to the solution now claimed, in particular to the features according to difference (iii).

6.7 In view of the above, the Board considers that the subject-matter of claim 1 involves an inventive step according to Article 56 EPC over document D1 even when it is combined with document D2.

7. With respect to the client of independent claim 7, the system of independent claim 10 and the method of independent claim 11, the Board observes that the above arguments in favour of an inventive step over D1 also apply, mutatis mutandis, to these claims. Claims 7 and 11 comprise features corresponding to difference (iii) that define how the client uses the metadata obtained from the brokerage server. System claim 10 includes the features of claims 1 and 7.

8. Remittal

In summary, the Board considers that the subject-matter of independent claims 1, 7, 10 and 11 involves an inventive step with respect to document D1 and that, for this reason, the decision of the Examining Division cannot be upheld.

However, before a patent can be granted, the claimed subject-matter may have to be examined in the light of the further documents on file mentioned in the search report. Hence, the Board finds it appropriate to exercise its powers under Article 111(1) EPC and remit the case to the department of first instance for further prosecution.

Moreover, further issues may need to be resolved, e.g. with regard to the dependent claims (for example, claims 8 and 9 refer to a client comprising or including a brokerage server) and the adaptation of the description.