Patent Grant
9461870
In general, this disclosure relates to cloud storage systems, in particular, to systems and methods for providing application specific file system directories for third-party applications.
Cloud storage systems provide users with the ability to store electronic documents and other files on a remote network rather than on the user's local computer or computing device. Such systems allow users to access the remotely stored files from any device that is capable of connecting with the remote network, for example using a web browser over an Internet connection. Cloud storage systems can also provide users with a large amount of memory to store files so that users are not limited by the memory capacity of a particular client or device. To access a cloud storage system, a user typically logs into an account on the cloud storage system using a username and password. The cloud storage system provides a user interface for users to view, edit, and manage files stored on the system.
Third-party applications may be used with cloud storage systems to provide applications and services for user's files on the cloud storage system. Third-party applications may include their own proprietary file formats that may limit access to the specific applications or interfaces by the cloud storage system and other third-party applications. In order for the third-party application to integrate with the cloud storage system, certain application information may be exchanged with the cloud storage system. Handling such application specific information in a streamlined fashion is desirable for efficient integration of third-party applications with cloud storage systems.
Thus a need exists in the art to provide a unified system for a third-party application to integrate with a cloud storage system. Systems and methods described herein provide dedicated data storage for a third-party application that is integrated in a cloud storage system to provide access to third-party application supported files.
In one aspect, systems and methods provide dedicated storage for a third-party application in a cloud storage system, by receiving, using a processor, a file for storage in a cloud storage system, wherein the file is associated with a third-party application and a user of the cloud storage system, identifying the third-party application, automatically allocating a directory for the identified third-party application and the user; and providing access to the directory for the identified third-party application to the third-party application. The directory is configured to store application data for the third-party application. The directory may be associated with a user and also hidden from the user. The directory may be assigned a reference link based on application data for the third-party application and a user identifier. Files for other users and other third-party applications may have respective directories allocated for use by the respective other third-party applications. Access to a file in the directory is authenticated for the requesting third-party application and respective user. In an aspect, if the third-party application is no longer available to the user, the user may be prompted to delete contents of the directory. In another aspect, the user may be presented with information for the directory and be provided an option to modify contents of the directory.
In another aspect, systems and methods provide support for a third-party application in a cloud storage system, by allocating a directory for a third-party application, associating the directory with a user of the cloud storage system, receiving configuration data for the third-party application, storing the configuration data in the directory; and hiding the directory from view by the user.
The methods and systems may be better understood from the following illustrative description with reference to the following drawings in which:
To provide an overall understanding of the systems and methods described herein, certain illustrative embodiments will now be described, including systems and methods for a cloud storage system capable of allocating an application specific directory for a third-party application. However, it will be understood by one of ordinary skill in the art that the systems and methods described herein may be adapted and modified as is appropriate for the application being addressed and that the systems and methods described herein may be employed in other suitable applications, and that such other additions and modifications will not depart from the scope thereof. In particular, a server, processor, or system as used herein may be a single computing device or multiple computing devices working collectively and in which the storage of data and the execution of functions are spread out amongst the various computing devices.
Aspects of the systems and methods described herein provide an application manager, for example, in a cloud storage system, that is capable of providing and allocating an application specific file system directory for a third-party application. Cloud storage systems may be used to store electronic document or files. Those cloud stored files are accessible from the cloud storage via a network from any client or computing device. As such, a user of a cloud storage system is not limited by storage capacity of a local device, or the availability of the local device. Different kinds of third-party applications may be used for the files that the user wishes to store on the cloud storage system. Since most applications have their own proprietary formats, integration of the third-party applications in another environment can require different application-specific solutions.
One way to improve efficient handling of third-party application files on a cloud storage system is to provide a third-party application file system directory on the cloud storage system that is accessible and used only by the third-party application. The third-party application directory may be allocated for each user of a third-party application on the cloud storage system. The third-party application directory may be used to store data relevant to the third-party application or originated by the third-party application, for example, application configuration data, default file types, user preferences, file state information, temporary files, file logs, or other data for the third-party application. In some implementations, such data is preferably protected from access by other applications, and also from the user. For example, if the user sees a data directory for the third-party application and modifies it, the contents of the directory may be unusable by the third-party application. Accordingly, the third-party application directory may be made hidden or un-modifiable to the user.
The third-party application directory may be provided on a cloud storage system that is accessible by any number of client computers and other electronic devices that are capable of connecting with remote networks, for example the Internet. In some implementations, the third-party application may be locally installed on a client computer or other device. In other implementations, the cloud storage system may be connected to the third-party application server or otherwise make the third-party application available to a cloud storage system user. Some examples of third-party applications or services include word processing applications, photo and video storing and sharing services, spreadsheet applications, graphic design services, presentation applications, database applications, gaming and entertainment services, music services, e-mail services, cloud storage services, and a variety of other categories.
The third-party application manager system 101 allows for third-party application developers to associate third-party application data directories 118 with a user. In particular, the third-party application developer may have certain default data to store in a third-party application data directory that may be used to integrate use of a third-party application file in another environment, for example, a cloud storage environment.
In one implementation, the third-party application manager system 101 is a part of a cloud storage system, which is a file hosting system that allows users to store, retrieve, and modify data via one or more user devices such as the user device 114. This data may be referred to as a user's web data. As an example, the cloud storage system 101 may be stored on a single server system or in a distributed system. In particular, the cloud storage system 101 may use cloud storage to store user data.
The database 106 stores several types of data. In particular, the database 106 stores data associated with user applications 116 and application directories 118. The user applications 116 may be stored as a list of applications associated with a user. For example, the set of user applications 116 may correspond to a list of all applications that the user has ever used to interact with a file, or with which the user has selected to be associated. As an example, when the third-party application manager system 101 is a part of a cloud storage system, the user's web data includes a set of files with various application formats. In this case, the list of user applications 116 may correspond to a set of applications that the user has used to access any file in the user's web data, or a set of applications that are configured to support any file within the user's web data. In general, the list of user applications 116 may be associated with the user, or a set of files associated with the user.
In addition, the database 106 also stores an application directory 118 that is associated with a particular user as well as the user application 116. The application directory 118 may be part of a data object family associated with the respective user application 116 and/or user. In some implementations, any user files related to the third-party application may also be included in the data object family. An alias associated with the third-party application may be assigned to the data object family and used for identification and authentication purposes as well as in a reference link for mapping the file system directory.
The third-party application developer system 103 communicates with the third-party application manager system 101 over the network 102 to initiate use of the third-party application. As depicted in
The third-party application directory may be allocated per-user and per-application. In some implementations the third-party application directory 118 may not be visible in a user interface for accessing user files, for example, in the cloud storage system. In other implementations, the third-party application directory 118 may be visible to the user, but the contents of the directory may not be modifiable. To the third-party application developer system 103, however, the application directory 118 is visible and available as any other directory. The application directory 118 may be made available using existing API methods using, for example, a standard identifier. The third-party application manager system 101 may receive the identifier from the developer system 103 to encode respective user and application identifiers. The third-party application directory 118 is generally created during the first use of the third-party application by the user. The third-party application directory 118 and its contents may be assigned certain authorization fields that are used to ensure that any requesting or accessing application is authorized to access the directory. Typically, only one third-party application is able to access its own application specific directory. The authorization fields may also be copied from a parent directory for the application to every directory and file that is created using the third-party application.
One example of a file manager interface is shown in
An example of a user's view of their files is shown in
Turning to
Method 400 may begin at step 402, when a file is received on a cloud storage system. In some implementations, the file may be received when a user seeks to store the file on a cloud storage system, or otherwise interact with the file using the cloud storage system. A processor for the cloud storage system, or a third-party application manager system may identify a third-party application associated with the file at step 404. The identification process may include consulting a list of third-party applications known to the cloud storage system, determining application information that is associated with the file, or may require communication with a third-party application developer. An allocation of a third-party application directory may be made by the processor for the identified third-party application at step 406. The third-party application directory may be a data directory that is used to store particular data for the third-party application, for example, configuration data, and which is stored in association with the respective user in the cloud storage system. At step 408 the processor authorizes the third-party application to access the third-party application directory. The authorization process may include communicating authenticating information between the processor and the third-party application. Authentication information may be included in the third-party application directory. The third-party application directory as well as its contents may be assigned an authorization field so that only the specific third-party application may access the directory. The authorization fields are copied from a parent file to each file when they are added.
Authentication of a third-party application, in particular, a requesting third-party application may be performed using a processor in the cloud storage system or the third-party application manager system. A third-party application may request access to its third-party application directory on the cloud storage system by communicating such request to the cloud storage system, generally in connection with a user accessing a file. At step 502, a request is received to access a third-party directory. The processor may obtain certain information from the third-party application as well as the third-party directory to determine application data, at step 504. Typically, the third-party directory will have an authorization field that is associated with the application data. That authorization field is also included in all of the respective application files so that the application is explicitly authorized to access its files on the cloud storage system. The application data of the application may be matched to the third-party application directory at step 506 to determine whether the requestor application is authorized to access the directory. Application data, alias information, application identifiers and other authentication information may be stored in a database accessible to the processor, for example, database 106. If the application data and identifiers match, the processor will provide access to the third-party application specific directory at step 508.
A user is generally freely available to manage his or her files stored on the cloud storage system. However, as mentioned herein, application-specific data directories should not be modified by the user. Although application-specific directories can contain any kind of data relevant to an application, such data is typically not useful on a standalone basis. As such, user modifications may be made out of context, or without knowledge of the data in the directory. A user may find it useful to know that some data directory exists that has a storage volume that goes towards the user's storage quota, and so an indication of the size of a data file may be made known to the user. In some implementations, the contents of the data directory are not modifiable by the user. A method for limiting access to an application specific directory is shown in
The steps of method 600 may be performed by a processor in the cloud storage system. At step 602, a requestor may select to view the requestor's files by making a selection in a user device, a developer device, or other device to view an interface for a file manager or an application manager. The processor may receive the request to view the user's files and search its database for any available files associated with the requestor. The files may be identified at step 604 by the processor using known techniques for identifying files associated with a particular user. The processor will also obtain information about the user type, for example, whether the user is an individual, or an application developer. Based on the user type, the processor will limit the interaction of the files and the application directories at step 606. For example, an individual user may be limited from viewing the contents of a third-party application directory, or seeing such directory at all. In some implementations, the individual user may see that there is a directory that has a certain stored amount. In such implementation, the user may clear the contents of the directory, or make limited modifications to the directory contents. For an application developer user, however, such limitations would not be applied to its respective third-party application specific directory. Other third-party application directories would not be available for view or interaction by a different third-party application user. At step 608, the processor will present a list of the requestor's file and directories, including the limitations based on the requestor type, to the requestor using for example, a file manager user interface display.
The components of the system 100 of
The computing device 700 comprises at least one communications interface unit, an input/output controller 710, system memory, and one or more data storage devices. The system memory includes at least one random access memory (RAM 702) and at least one read-only memory (ROM 704). All of these elements are in communication with a central processing unit (CPU 706) to facilitate the operation of the computing device 700. The computing device 700 may be configured in many different ways. For example, the computing device 700 may be a conventional standalone computer or alternatively, the functions of computing device 700 may be distributed across multiple computer systems and architectures. In
The computing device 700 may be configured in a distributed architecture, wherein databases and processors are housed in separate units or locations. Some units perform primary processing functions and contain at a minimum a general controller or a processor and a system memory. In distributed architecture implementations, each of these units may be attached via the communications interface unit 708 to a communications hub or port (not shown) that serves as a primary communication link with other servers, client or user computers and other related devices. The communications hub or port may have minimal processing capability itself, serving primarily as a communications router. A variety of communications protocols may be part of the system, including, but not limited to: Ethernet, SAP, SAS™, ATP, BLUETOOTH™, GSM and TCP/IP.
The CPU 706 comprises a processor, such as one or more conventional microprocessors and one or more supplementary co-processors such as math co-processors for offloading workload from the CPU 706. The CPU 706 is in communication with the communications interface unit 708 and the input/output controller 710, through which the CPU 706 communicates with other devices such as other servers, user terminals, or devices. The communications interface unit 708 and the input/output controller 710 may include multiple communication channels for simultaneous communication with, for example, other processors, servers or client terminals in the network 718.
The CPU 706 is also in communication with the data storage device. The data storage device may comprise an appropriate combination of magnetic, optical or semiconductor memory, and may include, for example, RAM 702, ROM 704, flash drive, an optical disc such as a compact disc or a hard disk or drive. The CPU 706 and the data storage device each may be, for example, located entirely within a single computer or other computing device; or connected to each other by a communication medium, such as a USB port, serial port cable, a coaxial cable, an Ethernet cable, a telephone line, a radio frequency transceiver or other similar wireless or wired medium or combination of the foregoing. For example, the CPU 706 may be connected to the data storage device via the communications interface unit 708. The CPU 706 may be configured to perform one or more particular processing functions.
The data storage device may store, for example, (i) an operating system 712 for the computing device 700; (ii) one or more applications 714 (e.g., computer program code or a computer program product) adapted to direct the CPU 706 in accordance with the systems and methods described here, and particularly in accordance with the processes described in detail with regard to the CPU 706; or (iii) database(s) 716 adapted to store information that may be utilized to store information required by the program.
The operating system 712 and applications 714 may be stored, for example, in a compressed, an uncompiled and an encrypted format, and may include computer program code. The instructions of the program may be read into a main memory of the processor from a computer-readable medium other than the data storage device, such as from the ROM 704 or from the RAM 702. While execution of sequences of instructions in the program causes the CPU 706 to perform the process steps described herein, hard-wired circuitry may be used in place of, or in combination with, software instructions for implementation of the processes of the present disclosure. Thus, the systems and methods described are not limited to any specific combination of hardware and software.
Suitable computer program code may be provided for performing one or more functions in relation to associating an application with one or more file formats using a third-party application manager system as described herein. The program also may include program elements such as an operating system 712, a database management system and “device drivers” that allow the processor to interface with computer peripheral devices (e.g., a video display, a keyboard, a computer mouse, etc.) via the input/output controller 710.
The term “computer-readable medium” as used herein refers to any non-transitory medium that provides or participates in providing instructions to the processor of the computing device 700 (or any other processor of a device described herein) for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media include, for example, optical, magnetic, or opto-magnetic disks, or integrated circuit memory, such as flash memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes the main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM or EEPROM (electronically erasable programmable read-only memory), a FLASH-EEPROM, any other memory chip or cartridge, or any other non-transitory medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to the CPU 706 (or any other processor of a device described herein) for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer (not shown). The remote computer can load the instructions into its dynamic memory and send the instructions over an Ethernet connection, cable line, or even telephone line using a modem. A communications device local to a computing device 700 (e.g., a server) can receive the data on the respective communications line and place the data on a system bus for the processor. The system bus carries the data to main memory, from which the processor retrieves and executes the instructions. The instructions received by main memory may optionally be stored in memory either before or after execution by the processor. In addition, instructions may be received via a communication port as electrical, electromagnetic or optical signals, which are exemplary forms of wireless communications or data streams that carry various types of information.
It will be apparent to one of ordinary skill in the art that aspects of the systems and methods described herein may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects consistent with the principles of the systems and method described herein is not limiting. Thus, the operation and behavior of the aspects of the systems and methods were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein.
Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7069502 | Numata et al. | Jun 2006 | B2 |
| 7197510 | Abe et al. | Mar 2007 | B2 |
| 7680932 | Defaix et al. | Mar 2010 | B2 |
| 7707413 | Lunt et al. | Apr 2010 | B2 |
| 7711835 | Braddy et al. | May 2010 | B2 |
| 7734914 | Malasky | Jun 2010 | B1 |
| 7761796 | Faraday et al. | Jul 2010 | B2 |
| 7779113 | Samar | Aug 2010 | B1 |
| 7818678 | Massand | Oct 2010 | B2 |
| 7818679 | Clarke | Oct 2010 | B2 |
| 7941419 | Bhatkar et al. | May 2011 | B2 |
| 7962853 | Bedi et al. | Jun 2011 | B2 |
| 7983416 | Takashima et al. | Jul 2011 | B2 |
| 7996380 | Arrouye et al. | Aug 2011 | B2 |
| 8015496 | Rogers | Sep 2011 | B1 |
| 8108427 | Prahlad et al. | Jan 2012 | B2 |
| 8131723 | Sim-Tang | Mar 2012 | B2 |
| 8151204 | Lusen et al. | Apr 2012 | B2 |
| 8190987 | Campbell et al. | May 2012 | B2 |
| 8250455 | Kadowaki et al. | Aug 2012 | B2 |
| 8341708 | Eatough et al. | Dec 2012 | B1 |
| 8386478 | Wang | Feb 2013 | B2 |
| 8555160 | Hattori | Oct 2013 | B2 |
| 20020105545 | Carter et al. | Aug 2002 | A1 |
| 20030126592 | Mishra et al. | Jul 2003 | A1 |
| 20040205358 | Erickson | Oct 2004 | A1 |
| 20050243760 | Yoshioka | Nov 2005 | A1 |
| 20050273695 | Schnurr | Dec 2005 | A1 |
| 20050289538 | Black-Ziegelbein et al. | Dec 2005 | A1 |
| 20060005168 | Singh | Jan 2006 | A1 |
| 20060070029 | Laborczfalvi et al. | Mar 2006 | A1 |
| 20070226535 | Gokhale | Sep 2007 | A1 |
| 20070254631 | Spooner | Nov 2007 | A1 |
| 20080172720 | Botz et al. | Jul 2008 | A1 |
| 20080189361 | Greschler et al. | Aug 2008 | A1 |
| 20090083707 | Fujita et al. | Mar 2009 | A1 |
| 20090210721 | Phillips | Aug 2009 | A1 |
| 20090254580 | Laurion | Oct 2009 | A1 |
| 20090288135 | Chang et al. | Nov 2009 | A1 |
| 20100005529 | Hemade | Jan 2010 | A1 |
| 20100063930 | Kenedy et al. | Mar 2010 | A1 |
| 20100095082 | Hull et al. | Apr 2010 | A1 |
| 20100161762 | Saxena | Jun 2010 | A1 |
| 20100257578 | Shukla et al. | Oct 2010 | A1 |
| 20100274910 | Ghanaie-Sichanie et al. | Oct 2010 | A1 |
| 20100281528 | Hayton et al. | Nov 2010 | A1 |
| 20110066668 | Guarraci | Mar 2011 | A1 |
| 20110137979 | Seo et al. | Jun 2011 | A1 |
| 20110179176 | Ravichandran et al. | Jul 2011 | A1 |
| 20110202672 | Narayanaswamy et al. | Aug 2011 | A1 |
| 20110231912 | Lee et al. | Sep 2011 | A1 |
| 20110252038 | Schmidt et al. | Oct 2011 | A1 |
| 20120005159 | Wang et al. | Jan 2012 | A1 |
| 20120095878 | Feldman et al. | Apr 2012 | A1 |
| 20120099135 | Ono | Apr 2012 | A1 |
| 20120110646 | Ajitomi et al. | May 2012 | A1 |
| 20120144202 | Counterman | Jun 2012 | A1 |
| 20120144454 | Lee | Jun 2012 | A1 |
| 20120254042 | Ludemann | Oct 2012 | A1 |
| 20120259964 | Lin et al. | Oct 2012 | A1 |
| 20120266229 | Simone et al. | Oct 2012 | A1 |
| 20130036455 | Bodi et al. | Feb 2013 | A1 |
| 20130080268 | Gordon et al. | Mar 2013 | A1 |
| 20130086585 | Huang et al. | Apr 2013 | A1 |
| 20130086670 | Vangpat et al. | Apr 2013 | A1 |
| 20130111336 | Dorman et al. | May 2013 | A1 |
| 20130124606 | Carpenter et al. | May 2013 | A1 |
| 20130144978 | Jain et al. | Jun 2013 | A1 |
| 20130174237 | Zises | Jul 2013 | A1 |
| 20130204849 | Chacko | Aug 2013 | A1 |
| 20130254343 | Stevens et al. | Sep 2013 | A1 |
| 20130318125 | Smith et al. | Nov 2013 | A1 |
| 20140082071 | Rexer | Mar 2014 | A1 |
| 20140108474 | David et al. | Apr 2014 | A1 |
| 20140114672 | Wright et al. | Apr 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 10-2010-0137323 | Dec 2010 | KR |
| 10-2012-0010397 | Feb 2012 | KR |
| WO 2010054374 | May 2010 | WO |
| Entry |
|---|
| International Search Report for Application No. PCT/US2014/037791, dated Oct. 8, 2014. |
| Symantec Corporation: E-Security Begins With Sound Security Policies, Announcement Symantec, XX, XX, XP002265695, p. 10-11, Section “Who Writes the Policy?”, Jun. 14, 2001, 23 pages. |
| Laferriere C. et al., “Authentication and Authorization Techniques in Distributed Systems,” Security Technology, 1993 Security Technology, Proceedings, Institute of Electrical and Electronics Engineers 1993 International Carnahan Conference on Ottawa, Ont., Canada Oct. 13-15, 1993, New York, NY USA IEEE, Oct. 13, 1993, pp. 1647170, XP010124730. |
| Lampson B. et al., “Authentication in Distributed Systems: Theory and Practice,” ACM Transactions on Computer Systems, Association for Computing Machinery, Inc. US, vol. 10, No. 4, pp. 265-310, Nov. 1992. |
| Beresford et al., “MockDroid: Trading Privacy for Application Functionality on Smartphones,” HotMobile '11 Mar. 1-3, 2011, Phoenix, AZ, USA. |
| Bibi et al., “A Platform for Delivering Multimedia Presentations on Cultural Heritage,” 2010 14th Panhellenic Conference on Informatics, pp. 175-179. |
| Ellis et al., “Concurrency Control in Groupware Systems,” ACM 1989, pp. 399-407. |
| Nauman et al., “Apex: Extending Android Permission Model and Enforcement with User-Defined Runtime Constraints,” ASIACCS '10 Apr. 13-16, 2010 Beijing, China. |
| Nichols et al., “High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System,” UIST '95. 8th Annual Symposium on User Interface Software and Technology. Proceedings of the ACM Symposium on User Interface SoftwareandTedmology, Nov. 14-17, 1995, pp. 111-120. |
| Peels et al., “Document Architecture and Text Formatting, ACM Transactions on Office Information Systems,” 3 (4):347-369 (1985). |
| The OAuth 2.0 Authorization Protocol; draft leff-oauth-v2-24; Mar. 8, 2012. |
| Zhou et al., “Taming Information-Stealing Smartphone Applications (on Android),” LNCS 6740:93-107 (2011). |
| Number | Date | Country | |
|---|---|---|---|
| 20140344456 A1 | Nov 2014 | US |
