This application is related to file systems, and, in particular, to remotely located file systems which are accessible over a TCP/IP connection, and to the problems inherent in organizing and presenting coherent views of the files contained in multiple file systems when accessed by a single computer or mobile device.
The term “cloud computing” refers to the delivery of computing services via an internet connection. The term “cloud” in this context is a metaphor for the internet, and services, such as file storage or archiving, the running of applications, or the delivery of a service, such as email, is provided via an internet connection and accessed through a program such as a web browser or a customized application. This model allows the delivery of computing services using a utility model, akin to the delivery of electricity via the electrical grid or television programming via a cable or satellite infrastructure.
Several comprehensive cloud computing solutions are currently available, including, for example, Microsoft's WindowsLive service, Apple's MobileMe service and a suite of services offered by Google. One aspect of the cloud computing concept is the on-line storage of users' personal files, including, for example, data files, documents, spreadsheets, photographs, music files, video files, or any other type of file typically created or used by a user that would otherwise be stored in the personal file storage area on a personal computer.
As examples of the file storage aspect of the cloud computing model, WindowsLive includes a service called SkyDrive, MobileMe includes a service called iDisk and Google offers Google Docs. These services provide not only the ability to offload personal file storage needs to an internet-based solution, but the ability to access those files, not only from one's personal computer, but from any computer or mobile device having an internet connection, regardless of location. Indeed, once the user is remote from his home-based personal computer, that computer becomes part of the “cloud” to which the user has access, and any personal files stored there may become “cloud accessible”.
One difficulty inherent in the cloud computing model is the ability to locate and organize files which may be spread out over several actual locations and accessible using separate facilities or separate internet connections. For example, a person having files spread out over an internet accessible personal computer, a SkyDrive and an iDisk may have difficulty remembering which of those contains a particular file and how to access that file.
It would therefore be desirable to provide a unified presentation of files contained in multiple physical location in the cloud. Preferably, the unified presentation would give the illusion that all of the files are located in a single hierarchical file structure, instead of in multiple, diverse file structures. It would also be desirable, both for convenience and security reasons, that this unified file structure be created in a central location or single point of access, such as on a mobile device, but available in multiple locations, such as on a personal computing device, where the single point of access can act as a server of the unified file structure. As such, the single point of access becomes a part of the cloud itself, accessible by other clients.
The present invention addresses the problems outlined above by providing a unified interface to a virtual file structure through a protocol abstraction layer that aggregates disparate, fragmented data storage into the virtual, unified file structure, allowing a homogeneous file system for a user in a heterogeneous environment. Access to the virtual, unified file structure is provided through an internet service, preferably running on a mobile, web-connected device, a web-browser, a media player or other means, which may directly provide a user interface to the virtual, unified file structure, or which may serve the virtual file structure to another device. Preferably, to the user, the fact that the virtual file structure consists of an aggregation of several separate physical file structures in not apparent from interacting with the virtual file structure.
One difficulty encountered when unifying disparate sources of files is that different storage solutions will have different file sharing and access protocols. The solution provided by the present invention is to provide a unified interface to the virtual file structure through a protocol abstraction layer that aggregates the disparate, fragmented storage. Therefore, the preferred embodiment of the present invention provides a single common interface to several different file access protocols.
The following detailed description is of the best currently contemplated modes of carrying out exemplary embodiments of the invention. The invention is not meant to be limited to these exemplary embodiments and they are provided solely for the purpose of illustrating the general principles of the invention, as the scope of the invention is best defined by the appended claims.
Note that the invention is described in its preferred embodiment, that is, as running on a mobile device, such as an iPhone or a device running the Android operating system. However, in practice, the software comprising the invention could be running on any computing platform, including for example, a laptop computer, a desktop computer or a tablet computer.
In reference to
Data presentation module 110 provides a common set of services available for all of the files imported from the different protocols and aggregated by the lower layers of the software, which will be discussed later. Data presentation module 110 also presents special services for specific files based upon the type of file and may map user inputs to specific service calls to the underlying layers.
In the second aspect of the invention, the mobile device running the software shown in
One advantage of this aspect of the invention is that the security protocols necessary to access the multiple sources of files are aggregated in the mobile device and are not exposed to the eventual client to which the virtual unified file structure is being exported. As such, in this mode of operation the mobile device running the software in
The multi protocol data aggregator 200 does the work of unifying the diverse file structures into one unified virtual file structure. Multi-protocol data aggregator 200 is composed of two components, data aggregation layer 202 and protocol framework layer 204. Protocol framework layer 204 provides the framework for multiple protocol drivers 210 to plug into a unified file access model. It defines a set of core file access services that are implemented by all supported protocols while providing interfaces for special services exported by individual protocols. Protocol framework layer 204 will be accessing files that are coming from many different sources, for example, cloud services that are running SMB or HTTP protocols, local storage, or any one of a number of other file access protocols, labeled as 210 in
Data aggregation layer 202 provides multiplexing and de-multiplexing of services for the file access requests that it receives from the data presentation module and data export modules 110 and 120 respectfully. This layer may be required to do protocol emulation when the storage container containing the file for which the request is received is accessed through a different access protocol. Because the semantics between the different file access protocols are different, the data aggregation layer is required to resolve those differences in semantics.
Another function performed by data aggregation layer 202 is to hide the multiple sources of the files and aggregate all the files into a virtual unified file structure.
It often may be required that multi protocol data aggregator 200 emulate protocols when the file structure on an external file access server 420 may be accessed through a different access protocol. For example, if the user has requested to read part of a file residing in a server that may not support reading such a file, multi protocol data aggregator 200 may ask protocol framework layer 204 to download the entire file to the mobile device and provide the user the requested data by reading from the downloaded file.
More specifically, multi protocol data aggregator 200 may first attempt to establish a connection with the server. If the user had specified a protocol to use, multi protocol data aggregator 200 might use that protocol; otherwise multi protocol data aggregator 200 may attempt to detect the protocol that may be used to connect.
Multi protocol data aggregator 200 also tracks access information and priority for different sources of files. When accessing files which may be stored on multiple file servers, multi protocol data aggregator 200 may select a protocol that has the highest priority. The priorities may be static, defined by the user, or may be determined dynamically from a set of properties/metrics. For example, the user may assign a higher priority for a particular file server that does not charge to transfer files and a lower priority to one that does charge. Multi protocol data aggregator 200 may also assign priorities to file servers based on various metrics, such as the protocol the server is using (giving higher priority to protocols that allow reading of segments of a file, for example). Multi protocol data aggregator 200 also maintains a dynamic priority for file servers based on speed, availability and other properties. In addition, the protocol framework layer 204 may update multi protocol data aggregator 200 regarding quality of service issues with respect to various file servers. In general multi protocol data aggregator 200 may use one or a combination of these priorities to select the file server that a file is stored on or read from.
Additionally, multi protocol data aggregator 200 maintains a database of file checksums and the servers they are available from. If the multi protocol data aggregator 200 does not find a file locally, it checks other servers for which it has a checksum for the file and services the request from that server, based on priority.
The user may now access files on all the servers and perform normal file-related functions on any of the external file access servers 420. These functions include, but may not be limited to browsing a directory structure, viewing files that may be supported by a mobile platform, transferring files from one server to another, managing files and folders (creating, deleting, renaming, moving), playing and streaming media files (movies, music), downloading files from the server to a mobile device, e-mailing files as attachments using existing e-mail accounts, faxing files using fax over internet protocol (FoIP) service, printing files, downloading e-mail attachments to any of the servers and uploading photos to social networking sites.
Note that to set up the external file access servers 420 that may be access by the mobile device, users may be required to set up one or more servers by providing multi protocol data aggregator 200 some or all of the following information: a host name or an IP address of a remote server; a port and a protocol that the multi protocol data aggregator 200 may use to connect to the server; and information needed to authenticate with the server. Alternatively, multi protocol data aggregator 200 may try to discover the servers on the local wireless network, in which case. the users may not need to provide the host name or IP address of the server. Preferably, users will have to provide information for a particular server only once. Multi protocol data aggregator 200 may store the information it needs to connect to a remote server in a local database on the mobile device.
Regardless of the actual architecture of the multi-protocol data aggregator 200, this module is required to perform at least the following functions:
Referring back to
When a request is being made in accordance with the first aspect of the invention, that is, a file is being requested by a user on the mobile device, the request originates in data presentation layer 110 and migrates through the multi protocol data aggregator 200, which it is transformed into a request using a particular access protocol. This request flows down through the TCP/IP stack 300, where it is packaged into a TCP/IP packet and sent via the internet to an external file access server 420.
When a request is being made in accordance with the second aspect of the invention, that is, the mobile device is acting as a server of the virtual, unified file structure, the request originates at an external file access client 410 (for example, a web browser, a file browser, a media player, etc.) via a received TCP/IP packet. The request will migrate up the TCP/IP stack 300 to decision point D2 via path 30. At this point, the software is unaware if the data received at decision point D2 is a request for remote access to the virtual file structure, in which case it is routed, via path 20 to data export service layer 120, or if it is a response to a previous request which has migrated down via path 10 from multi protocol data aggregator 200, in which case the data will be sent via path 32, back to multi protocol data aggregator 200. Data export service layer 120 takes incoming request via path 20 and makes a request to multi protocol data aggregator 200. The request is fulfilled in a manner similar to a request from a local user through the data presentation module 110, as described above in accordance with the first aspect of the invention.
Regardless of where the request originates, a request entering the multi protocol data aggregator 200 is de-multiplexed into several requests for different file access services 210, based on which remote server need be accessed and will be sent to different external file access servers 420.
When an external file access client 410 makes a request to the data export service layer 120, the external file access client 410 will view the virtual unified file structures as though all the files were present on the mobile platform, even those files may have been collected from multiple external file access servers 420.
In an addition aspect of the invention, the secure information (i.e., passwords, encrypted keys, etc.) necessary to access the files on a multiple external file servers 420 are not required to be known to the external file access client 410. The external file access client 410 need only provide the security information necessary to send a request to the data export service 120. The knowledge of the security required for accessing multiple external file access file servers 420 is contained in the multi protocol data aggregator 200.
The novelty of the invention lies in the multi protocol data aggregator 200 which is able to both resolve the differences between various protocols 210 and present a unified file access protocol at the edge of the protocol framework layer 204 and to aggregate file structures received from multiple external file access servers 420 into a single virtual hierarchical file structure by data aggregation layer 202 for presentation to a local user via the data presentation module 110 or to be served to an external file access client 410 via the data export service layer 120. In addition the multi protocol data aggregator 200 is able to integrate the local storage 250 of the computing platform into the virtual unified file structure. The multi protocol data aggregator 200 provides all the normal operations for files stored remotely, such as reading, writing, modifying, moving, streaming, etc., that would normally be available for files stored locally. Multi protocol data aggregator 200 also solves the problem of security regarding requests coming in through the data export service layer 120 from external access clients 410. As previously stated, the external file access clients need not know the security access information for every external file access server 420 and, in fact, ideally may not even be aware that files presented in the virtual unified file structure come from multiple external file access servers 420. With respect to the external file access client 410, the file structure presented in response to requests looks as though it resides on the mobile device
As previously stated, the invention has been described in terms of a mobile computing platform such as a smart phone or other tablet device such as a iPad. However, there is no reason that the multi protocol data aggregator 200 could not be installed on a stationery platform and utilized in the same manner. In such case it is likely that the user interface 112 would be different than one would have on a mobile device.
It should also be obvious to one who is skilled in the art that the architectural organization of the multiprotocol data aggregator is only an exemplary embodiment and that many other different configurations could exist providing the functionality described above. The novelty of the invention lies in the functions performed by multi protocol data aggregator 200 and not in its architectural organization. As a result, some claims are provided in terms of functionality provided by the software and not in terms of actual discrete modules where the functions are provided, and the invention is not meant to be limited to the architecture shown in
This application claims the benefit of U.S. provisional patent application Ser. No. 61/287,930, filed Dec. 18, 2009.
Number | Date | Country | |
---|---|---|---|
61287930 | Dec 2009 | US |