Patent Publication Number: US-2019180044-A1

Title: Internal folder sharing

Description:
CROSS-RELATION TO RELATED APPLICATIONS 
     This application is a continuation application of and claims the benefit of priority to U.S. patent application Ser. No. 14/271,846, filed May 7, 2014, which application claims the benefit of priority to U.S. Provisional Application No. 61/820,793 filed May 8, 2013, the contents of both which are incorporated herein by reference in their entireties. 
    
    
     TECHNICAL FIELD 
     This application relates generally to cloud-based file storage. More particularly, this application relates to the internal file sharing in a cloud-based file storage. 
     BACKGROUND 
     With the dramatic increase in use of mobile devices in recent years, it has become more important now than ever before that a user&#39;s files be synchronized between multiple devices. A single user may operate on a desktop computer, laptop computer, tablet computer, and mobile phone, editing the same document at different times on different devices. This issue is only going to become even more important as additional mobile devices, such as wearable computers and vehicle-based computers become popular mechanisms for editing files. 
     Problems, however, may be encountered as the synchronization of files across devices become more complex. Specifically, users may wish to share folders containing files with other users, which adds significant complexity to the management of files across multiple devices. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
         FIG. 1  is a block diagram illustrating a system, in accordance with an example embodiment, of securely synchronizing files. 
         FIG. 2  is a block diagram illustrating a client device, in accordance with an example embodiment, that may form part of the system of  FIG. 1 . 
         FIG. 3  is a block diagram illustrating another client device, in accordance with an example embodiment, that may form part of the system of  FIG. 1 . 
         FIG. 4  is a block diagram illustrating a backend, in accordance with an example embodiment, that may form part of the system of  FIG. 1 . 
         FIG. 5  is a diagram illustrating sub-folder sharing in accordance with an example embodiment. 
         FIG. 6  is a flow diagram illustrating a method, in accordance with an example embodiment, for sharing a folder in a tile system between an owner and a grantee. 
         FIG. 7  is a block diagram illustrating a mobile device, in accordance with an example embodiment. 
         FIG. 8  is a block diagram of machine in the example form of a computer system within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed. 
     
    
    
     DETAILED DESCRIPTION 
     Overview 
     The description that follows includes illustrative systems, methods, techniques, instruction sequences, and machine-readable media (e.g., computing machine program products) that embody illustrative embodiments. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures, and techniques have not been shown in detail. 
     In an example embodiment, various techniques are utilized in order to allow for efficient, accurate, and secure synchronization of files across multiple devices even in cases where a large number of events are occurring concurrently. This may include using an events-based technique to improve reliability during periods of file modifications being performed concurrently. In another example embodiment, name conflicts between different files may be resolved automatically. 
       FIG. 1  is a block diagram illustrating a system  100 , in accordance with an example embodiment, of securely synchronizing files. In the system  100 , files may be synchronized between one or more servers  102  and one or more client devices  104 A- 104 D. The client devices  104 A- 104 D may include various types of devices running various types of platforms with various types of operating systems and applications. For example, client device  104 A may be a mobile device running proprietary mobile applications  106 . Client device  104 B may be a personal computer running a Macintosh™ operating system from Apple Inc. of Cupertino, Calif. This may include a file system known as Finder  108 , which may include a specialized plug-in  110  to allow Finder  108  to be altered in order to better operate with a proprietary application  112 . 
     Client device  104 C may be a personal computer running a Windows™ operating system from Microsoft Corp. of Redmond, Wash. This may include a file system known as Windows Explorer  114 , which may include a specialized plug-in  116  to allow Windows Explorer  114  to be altered in order to better operate with a proprietary application  118 . Additionally, applications such as Microsoft Office™  120  and Microsoft Outlook™  122  may also include their own specialized plug-ins  124 ,  126 , respectively, which allow them to better operate with the proprietary application  118 . Client device  104 D may be a web-based device that may operate a web browser  128  instead of a traditional operating system. 
     Each of the client devices  104 A- 104 D may communicate with a back-end  130  hosted by the one or more servers  102 . This communication may either take place directly between the back-end  130  and the proprietary applications  106 ,  112 ,  118 , or indirectly through a web application  132 . A provisioning service, such as HostPilot™  134  may also be present, and may coordinate with a directory service such as Active Directories  136 . 
       FIG. 2  is a block diagram illustrating a client device, in accordance with an example embodiment, in more detail. In an example embodiment, the client device in this figure corresponds to client device  104 C of  FIG. 1 , although in some example embodiments this diagram corresponds to a different client device. Additionally, the various components in  FIG. 2  are labeled as those components are labeled in  FIG. 1 . In some embodiments, however, the components may not be identical. Proprietary application  116  may be a desktop application, and may store files in a local database  200 . The proprietary application  118  may also communicate with specialized plug-ins  116 ,  124 ,  126  in Windows Explorer  114 , Microsoft Office  120  and Microsoft Outlook™  122 , respectively. This communication may take place, for example, using Thrift over TCP. The proprietary application  118  may communicate with a storage service  202  on the server  102 . 
       FIG. 3  is a block diagram illustrating another client device, in accordance with an example embodiment, in more detail. In an example embodiment, the client device in this figure corresponds to client device  104 B of  FIG. 1 , although in some example embodiments this diagram corresponds to a different client device. Additionally, the various components in  FIG. 3  are labeled as those components are labeled in  FIG. 1 . In some embodiments, however, the components may not be identical. Proprietary application  112  may be a desktop application, and may store files in a local database  300 . The proprietary application  112  may also communicate with a specialized plugin  108  in Finder  110 . This communication may take place, for example, using Thrift over TCP. The proprietary application  118  may communicate with a storage device  302  on the server  102 . 
       FIG. 4  is a block diagram illustrating a backend, in accordance with an example embodiment, in more detail. In an example embodiment, the backend in this figure corresponds to backend  130  of  FIG. 1 , although in some example embodiments this diagram corresponds to a different backend. Additionally, the various components in  FIG. 4  are labeled as those components are labeled in  FIG. 1 . In some embodiments, however, the components may not be identical. The backend  130  may include a front-end server  400 , which acts to perform much of the server-side storage functions described in this disclosure, as well as interfacing with the various devices. These functions will be discussed in more detail later in this document. The front-end server  400  may interface with client devices  104 A- 104 D through a firewall  402 . The front-end server  400  may also interface with a database server  404 , which may control access to a database  406 . The database  406  may be of many different types of formats. In one example embodiment, the database  406  is a relational database, such as one operated using Structured Query Language (SQL). Other formats of database are envisioned, however, as well, including flat-file and multidimensional databases. The database may store not just files and folders, but also metadata about the files and folders, including, but not limited to, information about which files and folders are shared, and with whom. 
     A central server  408  performs internal tasks such as cleanup, provisioning, and other backend services. A key management server  410  provides access for keys created for each user. When a user is created on the central server  408 , a key may be issued by the key server  410 . These keys are also used by an encryption server  412  to encrypt and decrypt files and folders. This is accomplished through the use of the front end server  400 , which understands which organization the keys belong and submits file or folder content to the encryption server  412  for encryption. Active Directories  414  is used for integration with Exchange™. 
     Internal Sharing 
     In an example embodiment, files to be synchronized between devices may be organized into folders. This allows a user to share an entire grouping of files with other users in an organization. The user initially sharing the folder can be referred to as the owner of the folder. The users with which the owner shares the folder can be referred to as grantees. In an example embodiment, the owner of a folder can share that folder with another user (grantee) from his/her organization using, for example, a web application. When a folder is shared, the grantee can receive a sharing invitation that can be either accepted or rejected using the web application. When the grantee accepts the sharing invitation, the desktop application can create the shared folder locally (on the device of the grantee) in specific folder (e.g. My SecuriSync\Shared Folder) and then synchronize this new local folder with the server folder. 
     Notably, the owner and all the grantees could conceivably have multiple instances of the folder stored on a variety of different devices. For example, an owner may have an instance of the folder on a desktop computer and a mobile phone, while one of the grantees may have an instance of the folder on a laptop computer and a tablet computer. All of these instances may be synchronized, not just for each user but among all the users having access to the folder. 
     A folder can be shared by the owner at a number of different permission levels. In an example embodiment, the permission levels include View, Modify or Co-owner permission. The View permission allows viewing but not modification of the files in the folder. Thus, if a folder is shared with View permission, then if the grantee locally modifies one of the files in the folder, the local file will be overwritten with the server version. The modified version can be saved to a conflict file. Also, if the grantee locally deletes a file/folder that exists on the server, the file/folder will be restored locally. If the grantee having View permission locally creates a new file/folder, it will not be synchronized by the desktop application. 
     It should be noted that in some example embodiments the view permission only applies to the version of the files potentially shared with other users. In some example embodiments, if a user having view permission makes a modification to a file and saves that modification locally, the modified version can be shared with the user&#39;s other devices. In one example embodiment, this may be accomplished by synchronizing the conflict folder among the user&#39;s devices. 
     In an example embodiment, if a folder is shared with Modify or Co-owner permission, then if the grantee locally modifies a file that exists on the server or creates a new file, the local file version will be synchronized to the server (if there is no version conflict, which will be described in more detail below). Also, if the grantee locally creates a new folder, it will be created on the server by the desktop app. If the grantee locally deletes a file/folder that exists on the server, the file/folder will be deleted on server. 
     Sub Folder Sharing 
     In an example embodiment, a folder may be shared with a different user (grantee) regardless of its level in a folder hierarchy. The grantee may have one of a number of different permission levels (e.g., view, modify, co-owner). In the prior art, if a subfolder of a folder was to be shared, the entire folder (including other subfolders) would also have to be shared. In an example embodiment the subfolder can be shared regardless of whether or not the parent folder is shared. Permissions for folders and subfolders are each stored independently, allowing each folder or subfolder to be shared or not shared independently. If a subfolder is shared it may appear on grantee&#39;s devices as top-level folder while simultaneously appearing as a mid-level folder (subfolder) on the owner&#39;s devices. 
     In an example embodiment, if a parent folder is later shared with a grantee that already has permissions for a sub-folder of that parent folder, an issue may arise in that the grantee may get confused if suddenly the sub-folder disappears from a main directory and is placed in a new folder unbeknownst to the grantee. As such, in an example embodiment, if a parent folder is shared with a grantee that already has permissions for a sub-folder of that parent folder, the new shared parent folder may appear on the user&#39;s device as a top-level folder, while the sub-folder also remains as a top-level folder, with the same permissions as it had before. Both the top-level folder and the subfolder may be synchronized with each other, despite both being stored in the same instance of the file system (e.g., on the same device). 
     It should be noted that in an example embodiment if a parent folder is shared, then the sub-folders within that folder inherit the permission level of the parent. 
       FIG. 5  is a diagram illustrating sub-folder sharing in accordance with an example embodiment. An owner  500  may wish to share various folders and subfolders  502 - 508  with a grantee  510 . This sharing may occur at various permission levels. The user may wish to grant viewing permission to Folder A  502 , which then means that all subfolders  504 ,  506 ,  508  are also shared with the grantee  510  at the view permission level. This results in the grantee  510  seeing all of the folders  502 - 508  when viewing folders in the view permission level. If the grantee  510  wishes to see only those folders that he has co-owner permissions to, however, he will only see Folder C  506  and Folder D  508 . Likewise, if the grantee  510  wishes to see only those folders that he has modify permissions to, then he will only see Folder D  508 . 
     The various sharing permissions may be stored with the files/folders. When a folder is shared with a grantee, a virtual folder corresponding to the folder can be created on a device of the grantee. All objects within the folder can be copied to the virtual folder to share and mapped to the existing objects. Additionally, the shared folder may be stored at a level equal to parent folders of a file hierarchy on the device of the user. 
       FIG. 6  is a flow diagram illustrating a method  600 , in accordance with an example embodiment, for sharing a folder in a file system between an owner and a grantee. At operation  602 , an indication of a folder to share with a grantee may be received from the owner. The folder to share may be a subfolder within a parent folder. The parent folder, in this instance, is not shared with the grantee. At operation  604 , sharing permissions indicating a level of access the grantee has to the folder are stored with the folder. At operation  606 , a virtual folder corresponding to the folder is created on a device of the grantee, the virtual folder mapping to all objects within the folder to share and being stored at a level equal to parent folders of a file hierarchy on the device of the grantee. 
     File Version Conflict Resolution 
     A file version conflict may occur in the following situations: 
     If the file has been modified locally and on the server after the last synchronization and the server version differs from the local version. 
     If the file has not been synchronized and the server version differs from the local version. 
     If the file has been modified locally after the last synchronization and the user has View permission to this file. 
     In these cases, in an example embodiment, the local file is copied to the conflict file and then the local file is overwritten with the server version. 
     The conflict file is created in the same folder as the original file and has the name &lt;original file name&gt; (Conflicted copy &lt;YYYY-MM-DD&gt;—for &lt;user name&gt;).&lt;original file extension&gt; (e.g. “document(Conflicted copy 2013-04-04—for Nikita Uraltsev).docx”) 
     Example Mobile Device 
       FIG. 7  is a block diagram illustrating a mobile device  700 , according to an example embodiment. The mobile device  700  can include a processor  702 . The processor  702  can be any of a variety of different types of commercially available processors suitable for mobile devices  700  (for example, an XScale architecture microprocessor, a Microprocessor without Interlocked Pipeline Stages (MIPS) architecture processor, or another type of processor). A memory  704 , such as a random access memory (RAM), a Flash memory, or other type of memory, is typically accessible to the processor  702 . The memory  704  can be adapted to store an operating system (OS)  706 , as well as application programs  708 , such as a mobile location enabled application that can provide LBSs to a user. The processor  702  can be coupled, either directly or via appropriate intermediary hardware, to a display  710  and to one or more input/output (I/O) devices  712 , such as a keypad, a touch panel sensor, a microphone, and the like. Similarly, in some embodiments, the processor  702  can be coupled to a transceiver  714  that interfaces with an antenna  716 . The transceiver  714  can be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna  716 , depending on the nature of the mobile device  700 . Further, in some configurations, a GPS receiver  718  can also make use of the antenna  716  to receive GPS signals. 
     Modules, Components and Logic 
     Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules can constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is tangible unit capable of performing certain operations and can be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more processors can be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein. 
     In various embodiments, a hardware-implemented module can be implemented mechanically or electronically. For example, a hardware-implemented module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module can also comprise programmable logic or circuitry as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) can be driven by cost and time considerations. 
     Accordingly, the term “hardware-implemented module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules comprise a general-purpose processor configured using software, the general-purpose processor can be configured as respective different hardware-implemented modules at different times. Software can accordingly configure a processor, for example, to constitute a particular hardware-implemented module at one instance of time and to constitute a different hardware-implemented module at a different instance of time. 
     Hardware-implemented modules can provide information to, and receive information from, other hardware-implemented modules. Accordingly, the described hardware-implemented modules can be regarded as being communicatively coupled. Where multiple such hardware-implemented modules exist contemporaneously, communications can be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware-implemented modules. In embodiments in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules can be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules have access. For example, one hardware-implemented module can perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module can then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules can also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information). 
     The various operations of example methods described herein can be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein can, in some example embodiments, comprise processor-implemented modules. 
     Similarly, the methods described herein can be at least partially processor-implemented. For example, at least some of the operations of a method can be performed by one of processors or processor-implemented modules. The performance of certain of the operations can be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors can be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors can be distributed across a number of locations. 
     The one or more processors can also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations can be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).) 
     Electronic Apparatus and System 
     Example embodiments can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments can be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. 
     A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. 
     In example embodiments, operations can be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments can be implemented as, special purpose logic circuitry, e.g., a FPGA or an ASIC. 
     The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware can be a design choice. Below are set out hardware (e.g., machine) and software architectures that can be deployed, in various example embodiments. 
     Example Machine Architecture and Machine-Readable Medium 
       FIG. 15  is a block diagram of machine in the example form of a computer system  1500  within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed. In alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. 
     The example computer system  1500  includes a processor  1502  (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory  1504  and a static memory  1506 , which communicate with each other via a bus  1508 . The computer system  1500  can further include a video display unit  1510  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system  1500  also includes an alpha-numeric input device  1512  (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation device  1514  (e.g., a mouse), a disk drive unit  1516 , a signal generation device  1518  (e.g., a speaker), and a network interface device  1520 . 
     Machine-Readable Medium 
     The disk drive unit  1516  includes a machine-readable medium  1522  on which is stored one or more sets of instructions and data structures (e.g., software)  1524  embodying or utilized by any one or more of the methodologies or functions described herein. The instructions  1524  can also reside, completely or at least partially, within the main memory  1504  and/or within the processor  1502  during execution thereof by the computer system  1500 , with the main memory  1504  and the processor  1502  also constituting machine-readable media  1522 . 
     While the machine-readable medium  1522  is shown in an example embodiment to be a single medium, the term “machine-readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures  1524 . The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions  1524  for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions  1524 . The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media  1522  include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. 
     Transmission Medium 
     The instructions  152 . 4  can further be transmitted or received over a communications network  1526  using a transmission medium. The instructions  1524  can be transmitted using the network interface device  1520  and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions  1524  for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software. 
     Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter can be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments can be utilized and derived therefrom, such that structural and logical substitutions and changes can be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled. 
     Such embodiments of the inventive subject matter can be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose can be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.