Patent Publication Number: US-10785305-B2

Title: Automatic file storage and sharing

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     This application is a continuation of U.S. application Ser. No. 16/434,658, filed Jun. 7, 2019, now U.S. Pat. No. 10,506,046, which application is a continuation of U.S. application Ser. No. 14/755,402, filed Jun. 30, 2015, now U.S. Pat. No. 10,356,172, which is incorporated by reference in its entirety. 
     This application is related to U.S. patent application Ser. No. 13/217,944, filed Aug. 25, 2011, now U.S. Pat. No. 9,049,176, and titled “FILE SHARING VIA LINK GENERATION”, the contents of which are hereby incorporated by reference. 
    
    
     BACKGROUND 
     The described embodiments generally relate to sharing information among devices, and particularly to automatically storing and synchronizing files on a content management system and sharing a link to the synchronized files. 
     Some content management systems permit devices to synchronize files with the content management system and other devices. A device stores a local copy of files. When files are added, deleted, and edited on the device, these modifications are sent to the content management system for storage and synchronization with the other devices. Users of content management systems may share files stored on a content management system, but sharing files via a content management system can be complicated and time consuming. For example, a user may have to download a local copy of the file from the content management system and then provide the file to others, for example as an e-mail attachment. 
     SUMMARY 
     Described embodiments enable the automatic uploading and sharing of files via a content management system. An object (e.g., a file, a folder and its included files, etc.) is stored on a client device. A user of the client device may initiate a request to share the object via client software of the content management system executing on the client device. In various embodiments, a request is initiated via a user interface element generated by the client software. For example, client software may detect a “click-and-drag” operation of an object and provide a sharing element on a display of the client device. If the user “drops” the object over the sharing element, the client software automatically sends a sharing request to the content management system. In one embodiment, the client software prompts the user of the client device for one or more recipients for the sharing request. Sharing requests may be initiated in different manners in different embodiments, including choosing sharing options from context-sensitive menus or other user interface constructs within applications executing on the client device. 
     An automatic link engine (ALE) of the content management system receives the sharing request and automatically initiates a sharing process. In one embodiment, the sharing process comprises receiving the object from the client device, storing the object in the content management system, generating a link to the object, and sending the link to the recipient(s). 
     In various embodiments, objects are synchronized with the content management system such that a user may access objects via other computing devices. Shared objects may be stored together in a directory on content management system that allows a user to view and/or access the shared objects. The shared objects may be organized according to various parameters (e.g., object type, share date, etc.). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1A  illustrates an example computing environment for a content management system in accordance with one embodiment. 
         FIG. 1B  is a block diagram illustrating the components of an example client for automatically uploading and sharing a file, according to one embodiment. 
         FIGS. 2A-E  show instances of an example user interface for automatically uploading and sharing a file, according to one embodiment. 
         FIG. 3  is a block diagram illustrating the components of an automatic link engine, according to one embodiment. 
         FIG. 4  is a flowchart of an example process for the automatic upload, link generation and link sharing for a file. 
         FIGS. 5A-B  show example user interfaces for automatically uploading and sharing a file. 
     
    
    
     The figures depict various embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein. 
     DETAILED DESCRIPTION 
       FIG. 1A  illustrates an example computing environment for a content management system  100  in accordance with one embodiment. Content management system  100  includes automatic link engine  105  and file database  103 . Automatic link engine  105  provides functionality for automatic file upload and sharing as described below. File database  103  provides network file storage for clients  110 A and  110 B of a file access service that includes content management system  100 . For example, a first client  110 A may store one or more objects (e.g., files, folders, etc.) in file database  103 ; a second client  110 B may store one or more objects in file database  103 . In some embodiments, software executing on the client  110  integrates the network-stored objects with the client&#39;s local file system to enable a user to manipulate the network-stored objects through the same user interface (UI) as is used to manipulate objects on the local file system, e.g., via a file explorer. In some embodiments, clients  110  may additionally maintain a cache of the objects stored in storage  103 , to improve speed and reliability. Those of skill in the art will recognize that various methods exist to maintain synchronization between local and network based files. In other embodiments, clients  110  access objects via a web interface, or through a custom-designed client installed on a client device. Devices might include, for example, a desktop or laptop computer, a tablet computing device, or a handheld computing device such as a personal digital assistant or a smart phone (e.g., an IPHONE or BLACKBERRY, or an ANDROID-based smart phone). One provider of a suitable file access service is Dropbox Inc., of San Francisco, Calif. 
       FIG. 1A  illustrates only two clients,  110 A and  110 B, for purposes of clarity. When implemented, content management system  100  may be in communication with thousands or millions of clients, and each client may store one or multiple files on content management system  100 . When represented to the user, the files may be arranged in folders; and folders themselves may be arranged in other folders, as determined by the user; however the underlying storage architecture may be considerably different, and implemented to maximize storage efficiency, and without necessarily mirroring each user&#39;s file hierarchy. Content management system  100  and its components may be implemented using any appropriate hardware for performing file serving and storage—solely for clarity of illustration and description,  FIG. 1A  illustrates only a single content management system, and one instance of relevant file stores and modules. Additionally, many components required for operation of a content management system and service, known to those of skill in the art but not germane to this description—for example, network cards, CPUs, memory, and the like—are omitted for clarity. 
       FIG. 1A  also illustrates a visitor device  120 , to which a sharable link can be provided. As described further below, a visitor  120  need not have client software installed, and need not be associated with a user of file access server  100 , in order to access files via a shared link. 
     Network  140  represents the communication pathways between the client devices  110  and the content management system  100 . In one embodiment, the network  140  uses standard Internet communications technologies and/or protocols. Thus, the network  140  can include links using technologies such as Ethernet, IEEE 802.11, IEEE 806.16, WiMAX, 3GPP LTE, integrated services digital network (ISDN), asynchronous transfer mode (ATM), etc. Similarly, the networking protocols used on the network  140  can include the transmission control protocol/Internet protocol (TCP/IP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data exchanged over the network  140  can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc. In addition, all or some links can be encrypted using conventional encryption technologies such as the secure sockets layer (SSL), Secure HTTP (HTTPS) and/or virtual private networks (VPNs). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above. 
     Content management system  100  comprises an automatic link engine  105  that automatically uploads a file, generates a link, and shares the link responsive to a sharing request. In one embodiment, automatic link engine  105  further enables file access by users other than those who initially provided the files. The automatic link engine  105  is described further below with respect to  FIG. 3 . 
       FIG. 1B  is a block diagram illustrating components of an example client  110 , according to one embodiment. In this embodiment, client  110  includes client software  150 , display  160 , one or more native applications  170 , operating system  180 , and client storage  190 . 
     Native applications  170  vary based on the client device, and may include various applications for creating, viewing, consuming, and modifying content stored on content management system  100 , such as word processors, spreadsheets, database management systems, code editors, image and video editors, e-book readers, audio and video players, and the like. Operating system  180  on each device provides a local file management system and executes the various software modules such as client software  150  and native applications  170 . 
     Client software  150  can be a dedicated application or module that provides access to the services of content management system  100 , providing both user access to shared files through a user interface, as well as programmatic access for other applications. Client  110  may also access content management system  100  through a web browser of client  110 . As an alternative, client software  150  may integrate access to content management system  100  with the local file management system provided by operating system  180 . When access to content management system  100  is integrated in the local file management system, a file organization scheme maintained at content management system  100  is represented as a local file structure by operating system  180  in conjunction with client software  150 . Client software  150  may take various forms, such as a stand-alone application, an application plug-in, or a browser extension. Client storage  190  may include one or more types of non-transitory computer-readable persistent storage media. For example, the client storage  190  may include a hard drive, solid-state memory device, and/or other form of persistent memory. Client software  150  includes request module  155  for creating and sending sharing requests, and user interface module  157 , which are discussed in more detail below. 
       FIGS. 2A-E  show instances of an example user interface for automatically uploading and sharing objects (e.g. files, folders, etc.), according to one embodiment. The example user interface may be generated by user interface module  157  and shown on display  160  of client  110 . The example user interface of  FIG. 2A  includes desktop  210  and file system window  215 . File system window  215  includes a list of files  220  stored in client storage  190 . In various embodiments, one or more files  220  are displayed on desktop  210  or in a window of a native application  170 . In one embodiment, files  220  are not yet stored on content management system  100 . The example user interface may receive user input from a cursor that is controlled by a user input device (e.g., mouse, trackpad, keyboard, etc.). In another embodiment, client  110  is executed by a device having a touchscreen, which allows interaction with user interface elements by performing various gestures on the touchscreen. 
       FIG. 2B  shows a sharing element  225  that in one embodiment appears on the display when a user performs a specific action on an object such as file  220 A (e.g., a click-and-drag action). The sharing element  225  may be generated by user interface module  157 . User interface module  157  may communicate with operating system  180  to detect click-and-drag actions and other actions. For example, user interface module  157  may request to be notified when a click-and-drag action occurs on an object within operating system  180 . The client software may further request attributes of the object (e.g., where the object is stored, whether the object is a file, the type of file, etc.). In one embodiment, if an object is the subject of a click-and-drag action, user interface module  157  generates and displays sharing element  225  on display  160 . In one embodiment, user interface elements on display  160  are displayed in layers, and the sharing element  225  is displayed on top of other user interface elements on the display such that it is visible even if other user interface elements (e.g., windows) are present on the display. 
     As shown in  FIG. 2C , if a file  220 A is dragged over sharing element  225  and “dropped” (released), request module  155  creates a request to automatically upload and share the file and sends the request to automatic link engine  105 . In one embodiment, as shown in  FIG. 2D , user interface module  157  displays a recipient element  230  that allows a user to input a recipient (e.g. by selecting from a list of possible recipients, or by entering a user name, e-mail address or other identifier via a keyboard or other input device, etc.). A recipient need not be a user of the content management system. 
     In another embodiment, the sharing element  225  corresponds to a pre-determined recipient or group of receipients. In this embodiment, the file is automatically uploaded to the content management system  100  and automatic link engine  105  generates and sends a share link to the recipient(s), as discussed below with respect to  FIGS. 3 and 4 . In various embodiments, there may be multiple sharing elements  225  corresponding to different recipients or groups of recipients. For example, in addition to the generic sharing element  225  discussed above, there may be three additional sharing elements  225 A-C as shown in  FIG. 2E . Each of the three sharing elements may correspond to a different recipient or group of recipients. In the example of  FIG. 2E , sharing element  225 A may correspond to recipient A, sharing element  225 B may correspond to recipient B, and sharing element  225 C may correspond to recipients C, D, and E. In one embodiment, the recipients that correspond to the sharing elements are determined by request module  157  based on file attributes. For example, a file  220 A may be in a ‘Work’ folder. The sharing elements may correspond to recipients with whom the sharing user has previously shared files from the ‘Work’ folder. Similarly, the recipients may be determined based on other file attributes (e.g., file type, etc.). In other embodiments, recipients displayed in sharing elements may be determined based on other criteria (e.g., based on recently shared files, based on a choice of the sharing user, etc.). 
       FIG. 3  is a block diagram illustrating the components of the automatic link engine  105  of  FIG. 1A , according to one embodiment. Automatic link engine  105  enables automatic upload, link generation, and link sharing for a file designated by a user of content management system  100 . 
     Automatic link engine  105  comprises a file handling module  310  for handling sharing requests from clients  110 , a link generation module  330  for generating links and specifying corresponding files to be shared, a link distribution module  340  for facilitating distribution of the links to other users, a link management module  350  for viewing and removing previously generated links, and a file access module  360  for accessing the files via the generated links. Automatic link engine  105  comprises a sharing database  320 , which specifies sets of files to be shared and a mapping between the shared files and the links used to reference them. For example, the sharing database might comprise a set of pairs, each pair mapping a particular object to a unique link (e.g., a URL) by which the object can be accessed. Files uploaded to content management system  100  are stored in file database  103 . 
       FIG. 4  is a flowchart of an example process for the automatic upload, link generation and link sharing for an object. Request management module  310  receives  410  a sharing request from a client  110 . A sharing request may be sent by client software of a client  110  responsive to a user interface input. An example user interface is discussed above with respect to  FIGS. 2A-E . Additional example embodiments of request initiation and the user interface are discussed below with respect to  FIGS. 5A-B . In one embodiment, a sharing request includes a reference to an object and one or more recipients. In another embodiment, a sharing request may include a message from the sharer to the recipient(s). Request management module  310  may store the contents of a sharing request in sharing database  320  so that the modules of automatic link engine  105  may retrieve the requisite information for completing the sharing process at a later time. 
     Request management module  310  receives  420  the object from the client  110 . In one embodiment, the object to which the sharing request corresponds is stored in client storage  190  and may include a single file or a set of files, or a container of files such as one or more folders, or even particular logical content such as a particular time sequence of a video file, particular slides of a presentation file, or particular records from a database constructed from multiple files. Request management module  310  stores the object in file database  103 . 
     Link generation module  330  generates  430  a link corresponding to the object specified by the sharing request. The link unambiguously identifies within automatic link engine  105  the object to which it corresponds. In one embodiment, upon receiving a request to share a particular object, the link generation module  330  generates an objectidentifier (ID) unambiguously describing the object to be shared and a unique character string that identifies a name of the object (e.g., a uniform resource indicator (URI)) that serves as the link, and then saves an association of the object descriptor and the URI in the sharing database  320 . In one embodiment, the URI is a uniform resource locator (URL). 
     Link distribution module  240  sends  440  the generated link to the recipient(s) specified in the sharing request. Link distribution module  240  may send the link to the recipient(s) by email or similar messaging service, and/or by a message service of content management system  100 . In one embodiment, link distribution module  240  sends the generated link to the client  110  that originated the sharing request. 
     In one embodiment, steps  430  and  440  may occur before or at the same time as step  420 , which means that the link is generated and/or sent at the same time or before an object is stored in file database  103 . This allows the link to be provided without having to wait for the object to be stored in file database  103 . In this embodiment, the link may refer to a storage location where the file will be stored once the storage operation is complete, and the file may not be accessible until that time. In another embodiment, step  420  occurs before steps  430  and  440 , such that the object is stored in file database  103  before a link is generated and sent to the recipient(s). 
     In one embodiment, link management module  350  permits a user to manage previously-generated links. For example, a user may cause the link management module  350  to query the sharing database  320  for all the links that have been sent for that sharer and to display a list of the links. Each link has associated “Get link” and “Remove” actions. The “Get link” action displays the text of the link (e.g., URL) for dissemination by the sharer. The “Remove” action revokes access to recipients via that link, such as by deleting the entry for that link from the sharing database  320 . Thus, no matter how large the set of recipients—and thus access to the corresponding object—the sender can quickly and easily revoke the access simply by removing the link. 
     The file access module  360  provides the shared object and/or representations thereof to clients  110  in response to requests made via the generated link. For example, assume that responsive to a sharing request of the client  110 A of  FIG. 1A , link generation module  230  generated a shortened link http://db.tt/xOFounw to a folder named “JuneDocs” with an object ID of 3D8B99 and link distribution module  340  shared the link with a user of the client  110 B. When the user clicks on or otherwise selects the link via the email or social networking service, a browser application on the client  110 B sends a corresponding request to the automatic link engine  105 . For the example in which the link is the URL http://db.tt/xOFounw, the browser sends an HTTP request to the host db.tt, which is a domain name of the content management system  100 , including the parameter xOFounw. The request is handled by the file access module  360 , which locates the entry in the sharing database  320  corresponding to the parameter and extracts the associated object ID (namely, 3D8B99). Alternatively, if the folder is associated with a longer link https://www.service.com/s/28rtiz608u2mnco/newdoc.pdf, and this longer link is in turn associated with a shorter link http://db.tt/xOFounw, then the file access module first obtains the longer link from the shortened link using the link shortening service used to create the shortened link, and then determines the object from the longer link and the sharing database  320 . (If the link has been removed, e.g. via the “Remove” action, the sharing database  320  will not contain an entry for that link. Thus, the file access module  360  will accordingly prevent access to the object by informing the user requesting the access to the object that the object is not available.) In one embodiment, the entity that receives and accesses the shared link may be a visitor  120 , i.e., not a registered user of content management system  100 . 
     In one embodiment, the file access module  360  displays a representation of the object using a native application or plug-in corresponding to the object. In one embodiment, if the entity accessing the shared resources by shared link is a registered user of content management system  100 , the user has an option of copying the shared files to his or her own file space on file server  103 . In one embodiment, the copy is a static copy, such that if the original sharing user makes subsequent changes to the shared file, the changes are not reflected in the version of the file copied by the user with whom the link was shared. 
     Additional Example User Interfaces 
     The sharing request can be initiated by users of clients  110  in different manners in different embodiments. For example, the request can be made using the user interface provided by the client software running on the clients  110 , such as the example user interface of  FIGS. 2A-E . Further examples include designating a file within a file browser application and choosing a “Share file” option  505  from a resulting context-sensitive menu, as depicted in  FIG. 5A . In one embodiment, choosing the “Share file” option  505  results in the display of a user interface element similar to recipient element  230  of  FIG. 2D . In the example user interface of  FIG. 5A , a user may also initiate a sharing request by choosing the “Share with” option  510  from the file explorer application or context-sensitive menu and choosing one or more recipients of the file. 
     In another embodiment, the request can be initiated by clicking a link icon  515  within a file viewing application on a client  110 , as depicted in  FIG. 5B . As another example, the request can be made from a web-based interface provided by the file access server  100 , in which the user interface for initiating a sharing request is similar to the user interface of  FIG. 2A-E , but the sharing element(s) are displayed in a browser window. 
     File Organization and Synchronization 
     In one embodiment, when a file is shared according to the process of automatically uploading the file, generating a link to the file, and sending the specified recipients, the file is stored locally on client  110 . In another embodiment, the file is synchronized with content management system  100 . Thus, if the file is updated on a client  110  after being stored in file storage  103 , the changes may be synchronized to the copy of the file stored in file storage  103 , as well as with any other clients  110  synchronizing the file. 
     In one embodiment, shared files stored locally on client  110  are automatically organized together, for example in a “Shared Items” folder. Files may be organized by various parameters, including sharing date, recipient(s), folder from which file was shared, type of file, whether the file has been accessed by recipient(s), etc. 
     In the embodiment using synchronization, each client  110  executes a synchronization client application through which files of that client are specified for synchronization. The synchronization client application then provides the specified files to the content management system  100 . The specified files are then provided to other ones of the clients  110 , either by “push” in which the content management system  100  provides the files to the clients associated with a user who provided the files, or by “pull” in which the clients request the files from the file access server. The synchronization client applications and the content management system  100  also ensure that changes to the synchronized files are likewise reflected across all associated clients  110 . 
     In one embodiment, the synchronization client applications use local peer-to-peer synchronization for greater efficiency and do not require use of the content management system  100 . For example, devices associated with the same user or having access to the same shared folder can determine whether they are on the same local area network, and if so establish a secure connection (e.g., via SSL) and effect synchronization through peer-to-peer transfer of files. 
     The synchronized files are typically provided only to clients  110  associated with a user who provided the files. For example, if a particular user registers his desktop, laptop, and handheld device with the content management system  100  as his or her client devices  110 , then the file access server and the synchronization applications on those three devices will synchronize the files with those devices and otherwise make the file available to the user via the user&#39;s login (e.g., via a web-based interface). However, the content management system  100  will not by default make the files available to devices of other users or via logins other than that of the user who provided the files. 
     The foregoing description of the embodiments of the invention has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure. 
     Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combinations thereof. 
     Any of the steps, operations, or processes described herein may be performed or implemented with one or more hardware or software modules, alone or in combination with other devices. In one embodiment, a software module is implemented with a computer program product comprising a computer-readable medium containing computer program code, which can be executed by a computer processor for performing any or all of the steps, operations, or processes described. 
     Embodiments of the invention may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, and/or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory, tangible computer readable storage medium, or any type of media suitable for storing electronic instructions, which may be coupled to a computer system bus. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability. 
     Embodiments of the invention may also relate to a product that is produced by a computing process described herein. Such a product may comprise information resulting from a computing process, where the information is stored on a non-transitory, tangible computer readable storage medium and may include any embodiment of a computer program product or other data combination described herein. 
     Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.