DE202013012504U1 - Share and synchronize electronically stored files - Google Patents

Abstract

A system for sharing and synchronizing files electronically stored in a cloud system, comprising a computing device, including a processor and memory coupled to that processor, which in turn stores computer-executable instructions as executed by the processor, such as the system follows: it receives a message from the cloud that a file has been created and electronically stored in a cloud file system; it determines whether the electronically stored file needs to be copied to the system and as a result of that determination; copies the generated file to the system; otherwise, it stores an electronically stored file in a local file system that contains a link to the file that is stored electronically in the cloud file system.

Description

TECHNICAL AREA

This disclosure generally relates to the sharing and synchronization of electronically stored files between and among cloud entities, server computers, desktop computers, personal computers, portable computers, mobile computers, web-enabled computers, and other computers, such as personal computers. Tablets, PDAs and smartphones.

BACKGROUND

The networked and mobile computing environment that defines much of today's society has brought countless convenience and productivity benefits. Regardless of the benefits, managing electronically stored files concurrently across multiple computers, systems, and devices is becoming increasingly difficult. Thus, keeping track of and accessing a recent version or revision of an electronically stored file that may be stored on one or more office PCs, laptops, home computers, mobile computers, and removable drives is often difficult even for the most accomplished user. This difficulty becomes even greater due to the fact that such an electronically stored file can be accessed globally and that it can be used or changed by a variety of users, often simultaneously.

SUMMARY

Briefly, the aspects of this present disclosure are directed to the architectures, methods, systems, and structures that facilitate the sharing and synchronization of electronically stored files on and between cloud entities and a variety of computers, systems, devices, and / or users.

 In accordance with one aspect of this present disclosure, electronically stored files are initially generated in cloud entities and then replicated and synchronized with one or more client computer systems. Similarly, electronically stored files that are generated in client computer systems are then replicated and synchronized with cloud entities and other client computer systems.

 In accordance with one aspect of the present disclosure, during the synchronization process, a client determination is made as to whether an electronic cloud file should be downloaded / copied to the client. If the file is a dictated file format, it will not be downloaded / copied to the client. Instead, the file is created locally at the client and contains a link to the file stored electronically in the cloud. The advantage is that the local electronically stored file can be set as a file type that can indicate its cloud origin. Another advantage is the fact that the local file can be used to prompt a browser to access the electronic file stored in the cloud, which in turn may require further cloud computing services to access the file.

For the benefit and in accordance with another aspect of the present disclosure, it is that such sharing and synchronization can be managed by the user, with which these groups and / or sharing and synchronization systems can form.

In another aspect of the present disclosure, client computer systems include a local WATCHER and a cloud WATCHER that simultaneously monitor and detect changes in the observed local file systems and the cloud file systems.

Detected changes are used to generate work items that are ordered and selectively sent to a number of WORKERS for concurrent processing.

In accordance with one aspect of the present disclosure, electronically stored files in a shared folder are automatically shared and synchronized with other authorized users of that shared folder.

According to another aspect of the present disclosure, electronically stored files in a shared folder are automatically stored in a cloud storage system.

According to another aspect of the present disclosure, electronically stored files in a shared folder automatically "follow" a user online and offline across multiple systems, devices, and the network. Any changes made to electronically stored files in the shared folder are automatically updated and synchronized with the cloud and other computers and devices.

This summary is intended to briefly identify some aspects of the present disclosure, which are further explained below under DESCRIPTION. This SUMMARY is neither intended to contain major or important functions of this To identify revelation, nor does it serve to limit the extent of any claims.

The term "aspects" must be understood as "at least one aspect". The above-described aspects and other aspects of the present disclosure described herein are illustrated by example (e) and are not limited in the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWING

A more complete understanding of the present disclosure can be obtained by reference to the accompanying drawings, wherein:

1 FIG. 3 is a schematic illustration of an example arrangement for sharing and synchronizing electronically stored files in accordance with an aspect of the present disclosure; FIG.

2 FIG. 4 is a schematic illustration of another example arrangement for sharing and synchronizing electronically stored files according to another aspect of the present disclosure; FIG.

3 Figure 3 is a schematic representation of another example architecture for sharing and synchronizing electronically stored files in accordance with another aspect of the present disclosure;

3a - 3c 12 are schematic illustrations illustrating drag-and-drop operations and the synchronization status of electronically stored files in accordance with one aspect of the present disclosure;

4a FIG. 4 is a schematic illustration of an example function of a sync CLIENT according to one aspect of the present disclosure; FIG.

4b 12 is a schematic diagram showing an example sequence of events when a document is from the cloud and subsequently propagated to a SynchCLIENT in accordance with one aspect of the present disclosure;

4c Figure 12 is a schematic diagram showing an example sequence of events when a document originates from a third-party application and then shared / synchronized with a SynchCLIENT as a link to the cloud or a Clout site;

4d FIG. 3 is a schematic representation of example mapping according to an aspect of the present disclosure between Sync-CLIENT and the cloud; FIG.

4e FIG. 3 is a schematic representation of an example synchronization between Sync CLIENT and the cloud according to an aspect of the present disclosure; FIG.

4f FIG. 12 is a schematic diagram illustrating additional example synchronization between the SyncCLIENT and the cloud in accordance with an aspect of the present disclosure; FIG.

4g Figure 3 is a schematic representation of an example synchronization of a single file associated with multiple folders in the cloud with a Sync CLIENT;

5 FIG. 3 is a schematic illustration of an example architecture of a sync CLIENT according to one aspect of the present disclosure; FIG.

5a 12 is a schematic block diagram illustrating an example summary operation of the EVENT AGGREGATOR according to one aspect of the present disclosure;

5b FIG. 10 is a schematic block diagram illustrating an example operation of the EVENT AGGREGATOR according to one aspect of the present disclosure; FIG.

5c FIG. 10 is a flowchart illustrating an example operation overview of the EVENT AGGREGATOR according to one aspect of the present disclosure; FIG.

6 Figure 12 is a schematic depicting the Cloud WATCHER and the local WATCHER (Type-2) making changes to the cloud file system and the local file system through the use of graphs, in accordance with one aspect of the present disclosure;

6a 12 is a schematic block diagram illustrating a Cloud WATCHER determining a current cloud status through a change log received from the cloud by the SyncCLIENT in accordance with an aspect of the present disclosure;

7 FIG. 3 is a schematic block diagram illustrating the processing of work objects from the FETCHER and subsequent operations by WORKERS according to one aspect of the present disclosure; FIG.

8th Figure 12 is a schematic block diagram illustrating the serialization of regular work objects within FETCHER;

9 FIG. 3 is a schematic diagram illustrating a representative computer system for implementing example methods and systems for sharing and synchronizing electronically stored files in accordance with one aspect of the present disclosure. FIG.

The illustrative embodiments are further illustrated by the FIGs and the detailed description. However, the inventions may be embodied in various forms and are not limited to particular embodiments shown in the FIGs and the detailed description

DESCRIPTION

In the following, only the principles of the disclosure are illustrated. Therefore, it should be understood that those skilled in the art can make various arrangements that, while not explicitly listed or presented herein, embrace the principles of disclosure and are within their spirit and scope.

Furthermore, all of the examples and conditions set forth herein are, in principle, intended for educational purposes only, to assist the reader in understanding the principles of the disclosure and the concepts contributed by the inventors to the advancement of the arts; and these must be interpreted without limiting these specific examples and conditions.

Furthermore, all statements herein regarding principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to be equally structurally and functionally equivalent. Furthermore, it is contemplated that such pendants will include both currently known pendants and pendants that will be developed in the future, i. H. all elements that are developed that perform the same function regardless of the structure.

Thus, it will be understood by those skilled in the art, for example, that all block diagrams in this disclosure represent conceptual views of the illustrative environment that encompass the principles of the disclosure. Likewise, it should be understood that any flowcharts, flowcharts, status transition diagrams, pseudo-codes, and the like, represent various processes that are substantially represented in computer-readable media and are thus executed by a computer or processor, regardless of whether that computer or processor is explicitly presented.

The functions of the various elements, including all functional blocks, referred to as "processors" illustrated in the FIGs, may be performed via the use of the dedicated hardware as well as hardware capable of executing software, along with the appropriate software. When provided by a processor, the functions may be performed by a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared. Furthermore, the express use of the words "processor" or "controller" should not be construed as solely hardware executable software and may implicitly include, without limitation, Digital Signal Processing Hardware (DSP), Network Processors, Application Specific Integrated Circuits (ASIC), field programmable gate arrays (FPGA), read only memory (ROM) for storing software, random access memory (RAM) and nonvolatile memory. This can also include other hardware - conventional and / or user-specific.

Software modules, or simple modules that are to represent software, can be represented here as any combination of flowchart elements or other elements that indicate the performance of process steps and / or textual descriptions. These modules may be executed by hardware that is expressed or implied.

Unless otherwise expressly indicated, the drawings are not to scale.

We now provide some unrestricted illustrative examples that illustrate several operational aspects of various arrangements and alternative embodiments of the present disclosure.

In general, and as used here, an electronically stored file is a kind of abstraction. It provides a convenient way of bundling a record into identifiable units, which in turn are managed, stored, retrieved, and operated by computer systems. With reference to 1 , Here is a schematic representation of an example arrangement 100 for sharing and synchronizing electronically stored files according to one aspect of the present disclosure;

1 shows a PC 110 and a "cloud" 120 with which the pc 110 over one or more known network technologies 125 interacts.

As it is understood by experts, the cloud 120 a model of networked resources, such as Memory, computing and applications. For example, cloud computing usually refers to the delivery of computing as a service, providing shared resources, applications, software, data, and information to computers and other devices as a service or over a network such as the Internet. Similarly, cloud storage usually refers to electronic storage resources (e.g., electronic file systems) that are from the cloud 120 be provided via a network.

As an advantage, cloud computing and / or cloud storage provides individual users with only the resources needed for a particular task, reducing the cost of idle or unused resources. As a further benefit, users can be granted access to the latest software and infrastructure offering (s) for compatibility and productivity.

Ultimately, cloud computing and / or cloud storage usually provide users with access to cloud resources when the Internet accesses the cloud 120 from anywhere where Internet access mechanisms are available.

The network technologies 125 , in the 1 can provide the advantage, cloud 120 Internet access, either directly or through an Internet service provider.

Representative network technologies for cloud access include dial-up, leased line, ISDN, optical, broadband, broadband over power line, home fiber DSL / ADSL / SDSL, WiFi, WiMax, cable, satellite, mobile phone and T-provider and more Known Internet working protocols, such. For example, TCP / IP can be used with these technologies, as well as with higher-level protocols such as TCP / IP. HTTP to desirable communications with cloud 120 or other network resources.

1 also shows a number of electronic folders 112 . 114 . 116 that are in a storage system of the PC 110 are located. As it is understood by experts, electronic folders, such as those in 1 a kind of virtual container in which groups of electronically stored files can be stored and organized.

As is well understood, includes a contemporary computer operating system, such as the system, on a PC 110 For example, Windows, OS / X, LINUX, etc., usually have the support of electronic file systems, which can contain many thousands of folders. Electronic files can be conveniently organized by storing related files in a shared folder. A folder that is in a different folder is called a subfolder.

As undoubtedly understood by experts, the term "folder" represents an analogy to a file folder used in offices; This folder is used in almost all current operating system interfaces.

Folders are also a form of abstraction that provides a convenient way of bundling a set of electronic stored files into identifiable units that in turn are managed, stored, retrieved, and operated by computer systems. Folders are often represented by computer systems as icons that resemble actual folders.

With these applied principles, we can now describe certain operational aspects of sharing and synchronizing electronically stored files in accordance with one aspect of the present disclosure. Exactly, and as in 1 shown, the PC performs 110 Client syncs and sharing programs or service sets 115 which we generally refer to as "SyncCLIENT" for our purposes.

In general, a client program runs on a particular computer and accesses one or more services provided by an associated server program. The server program is often (but not always) on a different computer system; In this case, the client program accesses these services over a network.

In the present disclosure, the SyncCLIENT is running 115 , as in 1 shown on the PC 110 and interacts with the associated server services provided by Cloud 120 about the network technologies 125 to be provided. According to one aspect of the present disclosure, one or more are on the computer 110 located folders are replicated automatically and with the cloud 120 synchronized. As in 1 shown, becomes the folder 112 with the cloud storage services 130 replicates and synchronizes the folder 112-a Store electronically in a cloud file system.

Any at the folder 112 additions / deletions / changes made on the PC 110 on which the SyncCLIENT 115 running, be in the folder 112-a in a cloud store 130 played. It is beneficial that these operations automatically backup any files and folders in the folder 112 on the PC 110 on the cloud storage 120 to lead. Similarly, any additions / deletions / changes will be made to folders 112-a or its content in the cloud 120 in the folder 112 or its contents in the PC 110 reflected.

By further examples and as mentioned above, the exemplary cloud 120 offer the benefit of being in addition to cloud storage services 130 also provides computer services. For example, a variety of applications such as word processing, spreadsheets, presentation graphics, calendars, personal management, etc. 135 from the cloud 120 provided and retrieved via a World Wide Web interface, e.g. B. from the computer device 150 or the PC 110 , for example via a web browser. Another advantage is the computer device 150 to be a "scaled-down" or "thin client" (or tablet or smartphone, etc.) to access cloud computing resources. As is known, these thin clients usually rely on other computers (eg cloud computing) to fulfill their computer role.

If the computer device 150 with the in 1 equipped arrangements, it provides the ability to cloud computing resources 135 to use z. For example, to edit any editable documents stored in cloud storage 130 and folders 112-a are stored. These edits can be made from any geographic location to which the computing device is attached 150 on cloud 120 and its resources through network technologies 127 Has access. Hence, no one user the computer device 150 use to cloud computing resources 135 to create, edit, or otherwise use to modify / create folders or files that are in folders 112-a are stored. According to one aspect of the present disclosure, changes are made to the folder 112-a or changes to any files or folders stored in it automatically with folder 112 on the PC 110 synchronized.

Knowledgeable will appreciate that contemporary computer systems, such as the PC 110 or other computing devices 150 , as in 1 to provide operating systems such as WINDOWS, OS / X, LINUX or similar systems or their derivatives that provide one or more user interfaces to conveniently execute the file system procedures. More specifically, these user interfaces may allow a user to work on files using the familiar drag-and-drop, clipboard, and command methods.

When file system methods are based on these drag-and-drop or other familiar metaphors, users can conveniently select and copy files and directories (folders, etc.) and move them to other locations in the file system or delete them. It is advantageous that these familiar user interfaces can be used together with the aspects of this present disclosure, so as to provide e.g. For example, a file in the folder 112 on the PC 110 and then move it to the cloud folder 112-a to synchronize.

At this point, those of skill in the art will appreciate that the present disclosure is not limited to file methods via user interfaces. Operating system components, services, user applications, etc. can also perform file operations. Accordingly, changes to the folder 112 or its content also synchronizes with the cloud folder through one of these mechanisms (e.g., applications) 112-a trigger.

As related to this example, that in 1 In one aspect of the present disclosure, synchronization and sharing in accordance with the present disclosure allows for automatic bidirectional generation, backup, synchronization, and sharing of files and folders between PCs 110 . 150 and a cloud 120 ,

With reference to 2 , here is another example arrangement 200 illustrating the electronic sharing and synchronization according to one aspect of the present disclosure. 2 shows a number of computer systems, namely the computer 210 . 250 and 260 , in the 2 be referred to as "home", "laptop" and "work". Each of these computers 210 . 250 and 260 use the well-known network access technologies 225 . 226 and 227 as before for access to cloud 220 and in particular cloud storage services 230 File system described.

In 2 is shown that all computers 210 . 250 and 260 each the SyncCLIENT 215 . 256 and 267 trigger. According to one aspect of the present disclosure, one or more are on the computer 210 located folders are automatically replicated and activated by the SyncCLIENT 215 with the cloud storage system 230 File system synchronized. In this in 2 example shown is the folder 212 who is up 10 the home computer 210 located with the cloud storage services 230 File system replicates and synchronizes, that the folder 212-a and stores its electronic content electronically.

As previously related to the in 2 mentioned example, become the laptop computer 250 and the working computer 260 as executing instances of the SyncCLIENT 256 and 267 called. As a consequence, and in accordance with another aspect of the present disclosure, each of the executing instances of the SyncCLIENT 256 and 267 the folder 212a locally, on the computers 250 and 260 each as a folder 212b and 212c replicate and synchronize. The result is that the folder 212 who is on the home computer 210 located with the folder 212a replicated and synchronized electronically through the cloud storage system 230 File system was saved, as well as the folders 212b and 212c , each one on the laptop computer 250 and the working computer 260 are located.

Consistent with this, sharing and synchronizing electronically stored files in accordance with another aspect of the present disclosure allows the user to electronically store data (e.g., files in the folder 212c on the work computer) 260 ) to create / modify these created / synchronized electronically stored automatically on other computers (eg on the home computer and the laptop computer 210 . 250 ). Thus, without any additional effort on the part of the user, these electronically stored data effectively "follow" a user from one computer to another.

As in 2 As shown, each computer listed here includes a number of folders that are not replicated / synchronized or with the cloud 220 or other computers. In particular, the home computer 210 is called a folder with the folders 214 and 216 not shared and / or synchronized. Similarly, the laptop computer 250 as a folder with the folders 251 and 252 not shared and / or synchronized. Finally, the work computer becomes 260 represented as a folder containing the folder 261 that is neither shared nor synchronized.

Advantageously, and in accordance with one aspect of the present disclosure, these folders may be accessed by the SyncCLIENT with the cloud 220 and / or other computers and / or users can be shared / synchronized by the user.

As mentioned earlier, the cloud can 220 Cloud Computing Resources 235 in addition to cloud storage resources 230 provide. As a result, a user may also electronically store files via cloud computing resources 235 to create or modify, for example, from a Web browser that resides on a computing device, tablet, or other portable computing device (such as a smartphone) 270 is running, being accessed. With this procedure, the user has the advantage of having electronically stored files in the folder 212a create / change within the cloud storage service 230 File system; these created / changed electronically stored files will be with the folders 212 . 212b . 212c replicated / synchronized on the home computer 210 , Laptop computer 250 and work computers 260 are located. That way, electronically stored files can be stored in the cloud 220 created and used in client computing devices, such as Eg home computer 210 , Laptop computer 250 , Work computer 260 or another computer device 270 replicated / synchronized using browser applications and technologies to their advantage.

We would like to add that we used the term "create" to describe the generation of electronically stored files through the effectiveness of cloud computing services. Understanders understand that our specific vocabulary is not intended to be limiting. So an electronically stored file z. B. also be generated, or come from the cloud, by the effect of the cloud computer services. Similarly, an electronically stored file may be converted by the cloud computer services or recognized as being operable by those cloud computer services. As such, these electronically stored files may be considered to be derived or created for the purpose herein, which we will illustrate and explain in more detail below.

In addition, while sharing and synchronizing electronically stored files between multiple computers, the z. As used by an individual have described, the disclosure is not so limited. It is an advantage, and according to another aspect of the present disclosure, to synchronize and share electronically stored files between a number of computers and users.

With reference to 3 , here is another example arrangement 300 illustrating the electronic sharing and synchronization according to one aspect of the present disclosure. These 3 shows a number of computer systems, namely the PCs 310 . 350 and 360 that are used by different individual users and in 3 as a "user 1 "," User 2 "and" User 3 ". Each of these illustrated computers 310 . 350 and 360 use the well-known network access technologies 325 . 326 and 327 as before for access to cloud 320 and in particular cloud storage services 330 File system described.

In 3 is further shown that all computers 310 . 350 and 360 each SyncCLIENT software 315 . 356 and 367 trigger.

According to one aspect of the present disclosure, one or more folders located on the respective computers, e.g. Eg computer 310 , replicated automatically and by activating the SyncCLIENT 315 with the cloud storage system 330 File system synchronized. In this in 3 example shown is the folder 312 that is on the user 1 computer 310 located with the cloud storage services 330 File system replicates and synchronizes the folder 312-a and stores its electronic content electronically.

As further in 3 recognizable, the computer users are 2 350 and user 3 360 each as executing instances of the SyncCLIENT software 356 and 367 shown. Accordingly, and in accordance with another aspect of the present disclosure, each of the executing instances of the SyncCLIENT software may 356 and 367 the folder 312a locally, on the computers user 2 and user 3 350 and 360 each as a folder 312b and 312c replicate and synchronize. As a result, the folder becomes 312 that is on the user 1 computer 310 located with the folder 312a replicated and synchronized in the cloud storage services 330 File system is stored, as well as with the folders 312b and 312c that are on the computer user 2 350 and the computer 360 User 3 is located.

Consistent with this, sharing and synchronizing electronically stored files according to another aspect of the present disclosure allows multiple users to electronically store data (e.g., computer users 1) stored on a computer 310 ) and to automatically replicate / synchronize these created / changed electronically stored files on another user's computer (eg, computer user 2 and computer user 3) 350 . 360 ).

In addition, these or additional authorized users may access all cloud computer services through a web browser, such as: For example, to create / modify any electronically stored files that are stored on the cloud storage services 320 File system stored folder 312a are stored. As a result, any changes to electronically stored files in the folder 312a automatically with folders on the user computer systems 310 . 350 and 360 replicated and / or synchronized.

So far, we have identified certain aspects of sharing and synchronizing electronically stored files in accordance with aspects of the present disclosure that pertain to groups of users. Advantageously, and in accordance with another aspect of the present disclosure, users may belong to multiple groups that share and synchronize electronic files.

With further reference to 3 it is mentioned that the user 1, user 2 and user 3 (with the additional participation of user 4) electronically stored files containing folders 312 related, like folders 312a . 312b and 312c , and on the cloud 320 as well as on the computers 350 and 360 find, share and synchronize. In addition, there will be a group for sharing and synchronization including user 2 and user 3 in 3 shown.

In particular, while the user 2 and the user 3 as common users and synchronizers of the folder 352 presented on the computer 350 which is associated with user 2. This folder 352 is with the cloud 320 as a folder 352a and computer 360 as a folder 352b that is associated with user 3, shared and synchronized. Accordingly, user 2 and user 3 are identified as members of two different groups that share and synchronize. As noted above, the inclusion of additional users and / or computers in the shared use and synchronization groups, such as those illustrated herein, may advantageously be managed directly by the user.

Show with a working example 3a to 3c a drag-and-drop operation and subsequent synchronization of electronically stored files in accordance with an aspect of the present disclosure. As one skilled in the art will appreciate, a drag-and-drop operation is an act whereby a virtual object (such as an electronically stored file) is "grabbed" by graphical user interface mechanisms (eg, mouse or touch screen) and moved to another location dragged onto a virtual object (like a folder). It goes without saying that such an operation can be conveniently used to perform various different actions or to create various types of relationships between two abstract objects.

3a Socket a pair of overlapping windows 390 . 392 as often used in contemporary graphical user interfaces. In the window 392 becomes the symbolic representation of the electronically stored file 393 with the name "LIFE CYCLE OF THE ELEPHANT" illustrated. The window is similar 390 the symbolic representation of the local SyncDRIVE folder 391 , According to one aspect of the present disclosure, electronically stored files residing in the local SyncDRIVE folder 391 are automatically replicated and synchronized with the cloud (not specifically mapped) and optionally also with other SyncDRIVE clients (not specifically shown).

In the context of this example, a basic drag-and-drop sequence is performed as follows: By moving a pointer / cursor to the electronically stored file 393 , by "grabbing" the file 393 , pressing a mouse button or other selection mechanism, "dragging" the file 393 in the SyncDRIVE folder 391 and "dropping" the file 393 by releasing the button or the other selection mechanism.

After performing a drag-and-drop operation, an examination of the contents of the SyncDRIVE folder shows 391 , as in 3b shown how this copy of the electronically stored file is synchronized with the cloud, as well as the changed icon 394 which, in this example, indicates how the electronically stored file is being synchronized. When the synchronization process is complete and as in 3c shown with the electronically stored file 395 Updated linked icon to indicate that the electronically stored file is being synchronized.

As will be further understood, the representation of the synchronization status, as shown, may be realized by a number of symbolic or other mechanisms available in contemporary graphical user interfaces or computer systems. The examples include animated and / or audible mechanisms. Furthermore, while that in 3a - 3c As illustrated, the synchronization status associated with a sample SyncCLIENT and the cloud is greatly appreciated by those skilled in the art that this disclosure is not so limited and that further enhancements may include initial, intermediate, and subsequent downstream synchronizations, e.g. With additional syncCLIENT (s) that are part of a group, such as those described above.

When these particular functional aspects of the present disclosures are understood, we now turn to 4a , which is a simplified functional block diagram of an example SyncCLIENT 410 According to one aspect of the present disclosure.

As shown there, the SyncCLIENT includes 410 at least two functional elements, namely a cloud WATCHER 440 and a local WATCHER 430 that are the result of running the SyncCLIENT software on a computer device. In short, the local WATCHER 430 monitors and detects any changes to a watched local file system 420 while the cloud WATCHER 440 all relevant changes within the cloud file system 460 monitors and identifies itself in the cloud 450 located. If changes in the observed local file system 420 or in the cloud file system 460 be recognized, this leads to a synchronization between the two systems. Advantageous and in accordance with one aspect of the present disclosure, the cloud WATCHER 440 and the local WATCHER 430 in a preferred environment, simultaneously or in parallel, depending on the hardware environment in which they operate.

At this point, it is useful to discuss a particular example synchronization according to one aspect of the present disclosure, namely, the synchronization that occurs between the cloud and the syncCLIENT when a document originates from the cloud. More specifically, a document is created from the cloud using cloud computing resources; it is electronically stored in it by the use of cloud storage systems and then finally synchronized with one or more SyncCLIENT (s).

Regarding 4b 11, there is shown a schematic diagram illustrating the example origin or example creation of a document within the cloud by a user. As shown there, the document is created on a mobile device. As will be readily apparent and as previously noted, any of a variety of known mobile devices for interacting with cloud computing services may be capable of creating a document that may then be stored in the cloud via cloud storage devices. Familiar devices include mobile phones, tablets, or other portable computing devices. This disclosure is not limited to mobile devices, and this origin / creation of a document within the cloud can also be achieved with desktop or other computing devices. In particular, any device that supports browser functionality may be sufficient to interact with the sample cloud computer services.

Moreover, while the term document has been used to describe the particular electronic device that originates from and is stored in the cloud, the present disclosure is not limited thereto. Thus, word processing, documents, tables and graphics documents according to this disclosure, inter alia advantageously be created via cloud computer services from the cloud.

Accordingly, a document created in the cloud is then electronically stored there via cloud storage systems. In one example embodiment, a document stored electronically via cloud storage services has associated with a resource ID that uniquely identifies the electronically stored file in the cloud storage.

When the document is stored electronically in the cloud, it is then synchronized / replicated with the SyncCLIENT. It should be noted that the electronically stored file from the cloud computer services is not physically (electronically) replicated / copied to SyncCLIENT (s). Instead, and in accordance with another aspect of the present disclosure, electronically stored document files created via cloud computing services in the cloud and thereafter stored thereon are subsequently associated with one or more SyncCLIENT (s) as LINK (s) with the electronically stored document file synchronized with the cloud.

In this way, the electronically stored document originating from the cloud is advantageously not physically moved to the SyncCLIENT (s). A LINK to the document (file) is propagated to the SyncCLIENT (s) where it is stored in the local file system of the SyncCLIENT (s) as an electronically stored file containing a LINK to the file in the cloud. Another advantage is that the electronically stored file that contains the LINK to the file in the cloud is a local type that points to the location of that file on the cloud. More specifically, this locally stored file may be of the type ".gdoc" or another predetermined file type.

This electronically stored file is created in the SyncCLIENT file system (in the observed file system) and appears to the user. As an ordinary document, or text, or other equivalent file. Instead of containing the electronic content of the file stored electronically in the cloud, this local electronic file contains a LINK to the file in the cloud.

In a preferred embodiment and as in 4b As shown, such a LINK may identify the resource (the document), a method of finding the resource, and a particular access mechanism. As in the example in 4b As shown, this LINK may include components pointing to a Uniform Resource Locator (URL), protocol (s), such as: For example, HTTPS, Services (DOCS), Resource ID and TYPE. As understood by experts, this LINK can also contain additional components. If such a LINK is provided as shown, starting a web browser for the user of a SyncCLIENT may provide access to the file stored electronically in the cloud - whether mobile or stationary, and advantageously not consuming unnecessary bandwidth.

While we are in the processes 4a and 4b With reference to electronically stored files created in the cloud, it should be noted again that the teachings of the present disclosure are not limited thereto. More specifically, the present disclosure may equally refer to those electronically stored files created on a SyncCLIENT and then synchronized / replicated to the cloud as described above.

More specifically, a user may create an electronically stored file on a SyncCLIENT computer and have that electronically stored file synchronized / replicated with the cloud. If the file has been electronically stored in the cloud, the electronically stored file may be converted and / or changed (if necessary) into a format that may be easily operated by one or more cloud computing resource (s) and / or cloud applications , Then, this converted electronically stored file can be synchronized with one or more SyncCLIENT (s) as LINK to the electronically stored file in the cloud. Of course, those skilled in the art will appreciate that such conversion and / or modification is not necessary with certain electronic file formats (eg, text files, etc.). Accordingly, files of this format, when electronically stored in the cloud, are synchronized with SyncCLIENTs via the LINK mechanisms described above, and then accessed by the SyncCLIENTs as if they had been created in the cloud.

It should be understood that a document or other object need not be generated via cloud computing services in accordance with one aspect of this disclosure. In particular and with reference to 4c becomes a schematic sequence of Events, whereby a document is created by a third-party application, stored via cloud services in the cloud and then synchronized / replicated with a SyncCLIENT as LINK to the object in the CLOUD. Similarly, the SyncCLIENT recognizes that the document object in the CLOUD does not need to be copied to the SyncCLIENT, and instead a LINK to that object is generated and stored locally as a file in the SyncCLIENT local file system. As before, the document object may be accessed by the SyncCLIENT (or other computer devices with which the document has been synchronized) via, for example, a web browser. Furthermore, the LINK may refer to additional I alternative cloud sites so that the document or other resources may also be accessed through that cloud site.

At this point, it should be noted that folders and files in the cloud and folders and files in a local file system may show slightly different characteristics. In relation to 4d An example of a cloud file system and an example of a SyncCLIENT file system is presented with a number of folders and files that are now used to explain some of these features.

In particular, the example of a cloud file system in 4d shows a "bottom-up" structure instead of the "top-down" structure of the client file system, as those skilled in the art will readily recognize. More specifically, this "bottom-up" structure of the cloud file system results in multiple folders belonging to a single file.

As in 4d As shown, it can be seen that a single file A belongs to (or is in) the folder BAZ, which in turn belongs to the folders FOO and BAR. Similarly, files that are stored electronically in the cloud may have multiple parent folders, which in turn may have multiple parent folders. In this regard, folders are analogous to labels applied to files.

 In addition, names of folders and / or files used in the cloud are usually not unique. Similarly, names are more likely to be considered title attributes for files and folders. Therefore, and as noted elsewhere in this disclosure, files and folders in the cloud have unique identifiers, resource IDs, that uniquely identify the file or folder to which they are associated.

 Therefore, a local name of a file and / or folder may be different from its name in the cloud, as it may conflict with other files / folders that have the same name in the local file system. These conflicts can occur with both subordinate and parent file structures. Accordingly, and in accordance with an example embodiment and aspect of the present disclosure, a mapping is made between a folder resource ID and its name (in the cloud) and its local name as stored electronically on the syncCLIENT.

A sample mapping between cloud folders / files and local folders / files is shown in 4d illustrated. In an example embodiment, this type of mapping may be performed by a file mapping object that includes one or more local input objects and a cloud input object. As in 4d shown, the local folder FOO is mapped to the cloud folder FOO, the local folder BAR is mapped to the cloud folder BAR, two local folders BAZ are mapped to the individual cloud folder BAZ and both FILE A files are on the individual Cloud file FILE A mapped.

4e Figure 14 shows an additional example of differences between files / folders stored in the cloud storage system and how these differences affect sharing / synchronization in accordance with aspects of the present disclosure. Relating to 4e the cloud file system displays a folder called FOO with two subfolders named BAR. Thus, and in accordance with one aspect of the present disclosure, duplicate folders BAR are uniquely named with the cloud resource creation date when replicated / synchronized on the local file system. As in this example in 4e A folder in the local file system is called BAR, while the other is called BAR [XX / XX / XX], where XX / XX / XX is the date on which the cloud resource of this folder was created.

4f Figure 14 shows an additional example of differences between files / folders stored in the cloud storage system and how these differences affect sharing / synchronization in accordance with aspects of the present disclosure. Relating to 4f In the cloud file system, a folder is again called the FOO and has two subfolders named BAR. Thus, and in accordance with one aspect of the present disclosure, duplicate folders BAR in this example are uniquely named by an incremental counter when replicated / synchronized on the local file system. As in this example in 4f A folder in the local file system is called BAR [n] while the other folder is called BAR [n + 1]. Knowledgeable will estimate that a combination of this incremental counter method associated with the creation date of the cloud object described in the above paragraph will be considered by this disclosure.

Finally and with reference to 4g Fig. 12 shows a schematic representation of the synchronization of a single particular file A stored electronically on the cloud file system and associated with (contained in) three separate folders, namely FOO, BAR and BAZ. Therefore, when this file A is synchronized / replicated with a SyncCLIENT and electronically stored in a local file system on that client, three individual folders, namely FOO, BAR and BAZ, are created in the SyncCLIENT file system, wherein each one is a separate copy of the replicated file A. contains. This is advantageous for cases where one of the three files is changed locally because then the synchronization with the cloud takes place with the corresponding file A, which is located in the cloud file system.

We turn now 5 to which is a schematic block diagram 500 a SyncCLIENT 510 representing the operations described above. 1 - 4 can illustrate. As in 5 An illustrative SyncCLIENT includes the Cloud WATCHER 540 , the local WATCHER (eg Type-2 WATCHER 530 or Type-1 WATCHER 535 ), the EVENT AGGREGATOR 561 , the FETCHER 580 , WORKER (s) 590 , SNAPSHOT 560 and BLACKLIST 570 ,

As previously mentioned, Cloud WATCHER monitors and detects 540 all relevant changes to the cloud file system 520 while the local WATCHER ( 530 or 535 ) any changes to the observed local file system 515 monitors and detects. With reference to the Cloud WATCHER 540 is true that if any changes to the cloud file system 520 FS change notification (s) of this detected change (s) to FETCHER 580 be sent. With reference to the local WATCHER ( 530 or 535 ), if any changes to the local file system are detected, a message is sent to the EVENT AGGREGATOR 561 Posted.

According to one aspect of the present disclosure, the EVENT AGGREGATOR receives 561 Change notifications either from the local WATCHER (type 1) 535 or from local WATCHER (type 2) 530 , In a preferred embodiment, the local WATCHER (Type-I) 535 raw event file modification messages for the EVENT AGGREGATOR 561 while the local WATCHER (Type 2) provides FSI change notifications to the EVENT AGGREGATOR 56I.

While we are operating the EVENT AGGREGATOR 561 will be described in more detail later, we mention at this point that the EVENT AGGREGATOR 561 generally receive change messages from the local WATCHER and "keep" those messages for a period of time. If multiple changes are made to related objects during this retention period, the EVENT AGGREGATOR combines 561 These changes benefit or modify these changes further into higher-level, more coherent events that are then issued by the EVENT AGGREGATOR 561 to the FETCHER 580 be sent.

FS change objects created by the Cloud WATCHER 540 or from the EVENT AGGREGATOR 561 to the FETCHER 580 be sent by the FETCHER 580 receive, which in turn checks if any of the changes received on the BLACKLIST 570 are listed. The BLACKLIST 570 is a structure that lists those changes that were previously made to WORKERS 590 sent, but for some reason were not completed. Accordingly, the BLACKLIST serves 570 as a list of changes that can not be made as long as those changes are on the BLACKLIST 570 are located.

Conversely, changes made by the FETCHER 580 are not received on the BLACKLIST 570 from the FETCHER 550 as work objects for further processing to WORKER (s) 590 Posted. If a WORKER is unable to complete a work item, it becomes an ERROR 597 declared and the data of ERROR becomes BLACKLIST 570 added. Conversely, when a WORKER completes a work item, all subsequent CHANGES in the SNAPSHOT 560 displayed, which, as we mentioned earlier, the current synchronization status between that of the SyncCLIENT 510 watch local file system 515 and the cloud file system 520 maintains.

As is generally understood by those skilled in the art, the work objects are generally those operations performed by the WORKERS to implement the FS changes. In particular, a particular work item will identify an object it is listening to (eg, a file name), a direction (eg, download / upload), and an operation such as create, rename, delete, move, and modify.

As in 5 shown is the SNAPSHOT 560 Locked when changes / updates on SNAPSHOT 560 from the WORKER (s) 590 be made. This locking ensures that the SNAPSHOT 560 during the update and ensures consistency.

As will be described and described in more detail, the FETCHER serializes 550 in general, the flow of work objects before the subsequent parallel processing by the WORKERS 590 , In this regard, and as we will describe in more detail later, FETCHER acts as a manager / interlock ensuring that two workers do not work on conflicting and / or overlapping changes.

As it is understood by experts, there are a number of different operating systems, on which example - SyncCLIENT 510 - Software can run. Well-known examples of these operating systems include Microsoft WINDOWS, OS / X and LINUX. As a result of the capabilities of such operating systems, WORKER (s) 590 as multiple threads are implemented. As a result, multiple WORKERS can simultaneously operate on multi-processor or multi-core computer systems or simultaneously on single-processor computer systems. As a result, multiple WORKERS can work simultaneously on a work object, which improves performance in shared usage and synchronization processes.

Different operating systems such as those listed above provide different levels of details regarding changes that can occur within those file systems residing in those systems. To offer z. For example, UNIX derivations such as OS / X and LINUX folder level change notifications, while Microsoft WINDOWS provides a more detailed file level change notification. More specifically, OS / X provides information about folder changes while Microsoft WINDOWS provides information about changes to individual files. Consequently, at least two different local WATCHER (s) in 5 represented, namely the local WATCHER (type 2) 530 and the local WATCHER (Type-1) 531 , As in 5 further illustrated, the local WATCHER (type 2) provides folder level change messages 531 while the local WATCHER (type 1) 535 File-level change notifications 536 offers.

Specifically, Microsoft WINDOWS provides an application programming interface (API) ReadDirectoryChangesW I5 that, for example, sends a message to CHANGE_FILE_NAME - this is any file name change in the watched folder (directory) or its subdirectory; CHANGE_DIR_NAME - this is any directory name change in the watched directory or subdirectory; CHANGE_ATTRIBUTES - this is every attribute change in the watched directory; CHANGE_ SIZE - any change in file size in the watched directory or subdirectory where the file was written; CHANGE_LAST_ACCESS - this is any change to the last access time to the file (s) in the watched directory or subdirectory; CHANGE_ CREATION - this is any change to the creation time of the files in the watched directory or subdirectory; and CHANGE_ SECURITY - this is any change to the security identifier in the watched directory or subdirectory; to the SyncCLIENT software that accesses the APL.

Since OS / X does not offer this change message at the file level, the local WATCHER (type 2) 530 a local graph 532 used to check the status of the observed local file system 515 to monitor. Similarly and in accordance with one aspect of the present disclosure, the cloud WATCHER uses 540 a cloud graph 541 to track the status of the observed cloud file system 520 ,

Finally, we point out at this point that while, 5 both the local WATCHER (type 2) 530 as well as the local WATCHER (type 1) 535 as component parts of the SyncCLIENT 510 Advantageously, a particular instance of a SyncCLIENT does not require both.

Regarding 5a , a schematic block diagram illustrating an event sequence showing the saving of an electronically stored file "N" and the operation of the local WATCHER is illustrated 535 and the EVENT AGGREGATOR 561 is linked. As one skilled in the art will appreciate, such a sequence may accompany the operation of any amount of popular application programs or program suites.

• 1) Erstellen einer Temp-Datei „N + 1“;
• 2) Löschen der Datei „N“;
• 3) Verschieben einer Temp-Datei „N + 1“ nach „N“;

In particular, the general event sequence associated with these popular application programs or program suites when saving an electronically stored file "N" is as follows:

• 1) create a temp file "N + 1";
• 2) delete the file "N";
• 3) move a temp file "N + 1" to "N";

In keeping with this, the observed local file system shows 515 during the SyncCLIENT operation, the above event sequence that was received from the local WATCHER 535 is recognized. If this sequence is from the local WATCHER 535 would be forwarded to the FETCHER (not specifically shown) would take a number of unnecessary steps that could potentially impact system performance. To maintain performance and avoid unnecessary / redundant steps, and In accordance with another aspect of the present disclosure, an example syncCLIENT includes an EVENT AGGREGATOR 561 ,

As previously mentioned, the EVENT AGGREGATOR receives 561 in general, change messages from the local WATCHER and "keep" these messages for a period of time. If multiple changes are made to related objects during this retention period, the EVENT AGGREGATOR combines 561 These changes benefit or modify these changes further into higher-level, more coherent events that are then issued by the EVENT AGGREGATOR 561 be sent to the FETCHER.

With further reference to 5a becomes the EVENT AGGREGATOR 561 as the receiver of the above event sequence, namely the 1) creation of the Temp file N + 1; 2) deleting the file N; and 3) moving the Temp file N + 1 to N. As in 5a illustrates, holds the EVENT AGGREGATOR 561 this sequence and aggregates / combines them into a single work, namely: "Change (N -> N + 1)"; which is then forwarded to FLETCHER for further processing. 5b is a schematic diagram that provides an overview of the processing in EVENT AGGREGATOR 561 according to one aspect of the present disclosure. Like in this one 5b shown, are changed events that are observed in the local file system 515 from the local WATCHER 535 be recognized, to the EVENT AGGREGATOR 561 sent where they are placed in the change event queue.

Before they are placed in this change event queue, a received change event is checked to see if it can be combined with a change event that is already in the change event queue. If so, the received change event is combined with the change event in the change event queue and the combined change event is placed back in the queue. If the received change event can not be combined with the change event in the change event queue, the received change event is placed uncombined in the queue.

 The change event queue is periodically checked and any change events that are in the change event queue for a predetermined period of time are sent to the FETCHER for further processing (not specifically shown).

5c is a flowchart illustrating a general operation overview of the EVENT AGGREGATOR 561 according to one aspect of the present disclosure. In terms of In 5c it is mentioned that at the block 562 the EVENT AGGREGATOR 561 gets a change event from a local WATCHER. After receiving the change event at block 563 the EVENT AGGREGATOR checks the received change event to see if it can be combined with another received change event already placed in the change event queue.

If the received change event can be combined with the change event in the change event queue, the received change event with the change event is queued at the block 564 combined and the combined change event is at the block 565 placed in the queue.

If the received change event does not match the change event in the queue at the block 564 can be combined, the received change event is uncombined at the block 565 placed in the change event queue.

The change event queue is periodically at the block 566 checked to see if any change events in the queue were there for a certain period of time exceeding the predetermined time period. If so, this change event is removed from the queue and at the block 567 sent to the FETCHER for processing.

As mentioned and in accordance with another aspect of the present disclosure, the EVENT AGGREGATOR 561 based on known / learned patterns that are recognizable, combine received events with events already in the queue. In particular, the EVENT AGGREGATOR can recognize certain event combinations from known patterns of received change sequences, observed file types, recognized executable programs, executing processes, etc., and can determine the particular changes from these data and use that information to create combinations.

We turn now 6 to which is a schematic block diagram of the operation of a cloud WATCHER 640 and a local WATCHER (Type 2) 630 at a representative syncCLIENT 610 in accordance with one aspect of the present disclosure. As in 6 , the cloud WATCHER generates 640 a cloud graph 642 , which is the current status of the observed cloud file system 680 reproduces. After the generation of the cloud graph 642 generates the cloud WATCHER 640 regularly a current cloud status representation 644 and then notice any differences between the two. Does he find a difference between the cloud graph 642 and the current cloud status representation 644 , the cloud WATCHER generates 640 a FS change (file system change message) and sends it to the FETCHER (not specifically shown). As before with respect to the discussion of 5 The FS change messages are used by the FETCHER to generate work items that are sent to the WORKERS (not specifically shown).

In a preferred embodiment, the current cloud status representation 644 represented by an ordered list of changes made to objects within the cloud file system as reported to the SyncCLIENT. The cloud graph 642 may preferably be represented as a dictionary structure comprising a resource ID key wherein the dictionary entries may look like - in addition to the resource ID - all the file name (s), checksum (s), and timestamps.

Similarly, the local WATCHER (type 2) monitors 630 the observed local file system 615 via for example the FS event API, which sends folder level change messages. After receiving folder level change messages, the local WATCHER (type 2) generates 630 a current local status representation 634 indicating the current status of the observed local file system 615 points. The local WATCHER (type 2) 630 regularly compares a current cloud status representation 634 with a previously generated local graph 632 and then notice any differences between the two. Will make a difference between the current cloud status representation 634 and the local graph 632 noticed, the local WATCHER generates 630 a FS change and sends it to the EVENT AGGREGATOR (not specifically shown). As before regarding 5a and 5b described, the EVENT AGGREGATOR preserves changes for a certain period of time; and when detecting multiple changes from related objects or certain known patterns, the EVENT AGGREGATOR may modify these received FS change events into higher-level coherent events, which are then sent to the FETCHER for further processing.

6a is a schematic block diagram showing the receipt and updating of the current cloud status 644 represents. Like in this one 6a shown, the current cloud status 644 from a change log 646 be determined that the SyncCLIENT 610 receives from the cloud. In an example embodiment, such a change log comprises 646 As shown in FIG. 26a, a sorted list of changes made to the cloud file system 680 that are relevant to the corresponding SyncCLIENT 610 and / or a specific account.

Advantageous, and in accordance with one aspect of the present disclosure, is the sorted list of changes made to the cloud file system 680 have been made in the change log 646 already on receipt at SyncCLIENT 610 aggregated. Consequently, the sorted list of changes required by the cloud file system via the change log requires 646 no further aggregation as they need the changes observed by the local WATCHER as described above.

In a particular example embodiment, the change log includes 646 for a given account, a series of inputs, including an indication of the current status of an object; whether an item has been moved to the recycle bin and whether an item has been deleted from the recycle bin. Please note that this sample list of entries in the change log must be considered representative rather than complete. Consequently, additional entries indicative of the status of an object may be provided via the change log. As is understood by those skilled in the art, these entries can be used in the Cloud WATCHER change log to generate FS change events that are passed to the FETCHER.

With reference to 7 , here is a schematic representation of a schematic block diagram illustrating the generation of work objects and their subsequent processing by the representative SynchCLIENT 710 according to one aspect of the present disclosure. As shown and previously described, one or more FS change events are provided by the Cloud WATCHER 740 or from the EVENT AGGREGATOR 735 as work objects to the FETCHER 720 then sent to a sorted work queue 726 to be placed.

Especially when receiving the work objects 725 arranged the FETCHER 720 the received work objects 725 so that they are processed in a predetermined order. Of Further become the work objects 725 [1] ... 725 [n] into a work queue 726 entered, which is sorted from oldest to newest entry. In this regard, the FETCHER serializes 720 through the effect of the work queue 726 the work objects 725 [1] ... 725 [n] before sending it to the workers 750 [1] ... 750 [n] distributed for simultaneous processing.

At this point we reiterate that while there will be WORKERS processing work items 750 [1] ... 750 [n] have been described as being done simultaneously in a processing arrangement having multiple processors or multiple cores (multiprocessor or multicore), in contemporary computer systems the actual processing of multiple work objects by multiple WORKERS 750 [1] ... 750 [n] parallel, where each worker thread can be executed by an individual processor or core.

Accordingly, significant throughput of shared benefit and synchronization is achieved by this arrangement with multiple WORKERS operating concurrently or in parallel. Similar performance benefits are also seen as a result of Cloud WATCHER 740 and the local WATCHER 730 which work simultaneously or in parallel, depending on the particular computer system hardware and system software used by the SyncCLIENT 710 is used.

Regarding 8th , becomes a schematic block diagram 800 the serialization of the work objects 825 [1] ... 825 [n] through FETCHER 820 shown. We presented here, the incoming work objects 825 [1] ... 825 [n] in a work queue 826 arranged from oldest to newest entry sorted.

Operationally the FETCHER checks 820 all work items in the work queue 826 and determines if the work object is WORKERS 850 [1] ... 850 [n] can be processed (or not). In this in 8th In the illustrated embodiment, the FETCHER checks 820 sequentially the work objects 825 [1] ... 825 [n] in the work queue 826 Starting with the oldest and continuing with the newest, to determine which dependencies - if applicable - are identified by the particular work object being tested. If a checked work object 825 [1] ... 825 [n] in the work queue 826 of any entries in the dependency card 890 is determined to be unworkable at this time.

As in 8th shown, includes the dependency card 890 a list of structures that may be affected by operations performed by one of the multitude of WORKERS 850 [1] ... 850 [n] be executed at any time. Entries in the dependency card 890 that are important and 8th include: inodes 891 , Resource ID (s) 892 , and filenames, etc. 893 , Additional dependencies that are not specific in 8th include filenames of parent, child, and those at the same level.

One skilled in the art knows immediately that an inode is a data structure used by contemporaneous operating systems to store information about a file, directory, or other file system object. Inodes store information about files and directories (folders), such as their owner, mode, and type. Files are linked to a specific inode, which is identified by an integer number (inode number).

Similarly, a resource ID is an identifier that includes cloud objects, such as cloud objects. For example, files are uniquely identified. Accordingly, such resource ID would uniquely identify a particular file stored in the cloud file system.

Finally, filenames are general metadata about a file. Often, file names are strings that are used to identify (preferably uniquely) the file that is stored electronically in a file system. Often, filenames contain additional components, such as: For example, a path associated with the file, a name associated with the file, a type associated with the file, and a version associated with the file.

For the benefit and in accordance with another aspect of the present disclosure, the FETCHER maintains 820 the dependency card 890 that identifies dependencies that are currently affected by work objects where the WORKERS 850 [1] ... 850 [n] work. Accordingly, the FETCHER checks 820 the work objects 825 [1] ... 825 [n] in the work queue 826 , and then compares the dependencies that are affected by the inspected work object with any dependencies in the dependency map 890 , If these dependencies that are affected by the checked work item are in the dependency map 890 the respective work object is skipped and the FETCHER 820 checks the next work item in the work queue 826 ,

We would like to mention at this point that it is preferred the order of work objects 825 [1] ... 825 [n] even if a particular work item is skipped. Accordingly, the work queue 826 in the FETCHER 820 always be in the order oldest after newest entry.

When a particular work item is declared workable, that is, its affected dependencies are not in the dependency card 890 This work item is sent to a WORKER for processing 850 [1] ... 850 [n] forwarded.

Each time a work item is forwarded to a WORKER for processing, the affected dependencies become in the dependency map 890 demonstrated. Conversely, the dependency card 890 Each time a WORKER finishes a work item, it updates to indicate that it is no longer working on that set of dependencies.

When a WORKER completes a particular work item, the FETCHER checks 820 the work queue again 820 , starting with the oldest work object 825 [1] in the work queue 820 and with scan to the newest work object 825 [n] in the work queue 826 ,

As experts will estimate, work items are in the work queue 826 which were previously skipped (eg due to dependency conflicts), rescanned and processed, if this statement was made by FETCHER 820 is done. Another advantage is that, since the FETCHER 820 Ensures that no two work objects sent to the WORKERS are subject to conflicts of interdependence, no interlocks are required and therefore a high level of simultaneity and / / parallelism is achieved in WORKERS 'work.

9 shows an illustration of a computer system 900 According to one aspect of the present disclosure, that is suitable for implementing methods and systems. The computer system can, for. For example, a computer containing any number of operating systems. The methods described above for the present disclosure may be on the computer system 900 be implemented as stored program control statements.

The computer system 900 includes the processor 910 , Storage 920 , Storage device 930 , and input / output structure 940 , One or more input / output devices can have a screen 945 include. One or more buses 950 usually connect the components 910 920 . 930 , and 940 together. The processor 910 can contain a single or multiple core.

Processor 910 executes instructions in which the embodiments of the present disclosure may include steps described in one or more figures. These instructions can be stored in memory 920 or in the storage device 930 get saved. Data and / or information can be received and output via one or more input / output devices.

Storage 920 can store data and can be a computer readable medium, such as: B. volatile or non-volatile memory. The storage device 930 can the system 900 save, including z. B. the methods described above. In several aspects, the storage device may be 930 a flash memory, a disk drive, an optical drive, or a tape device that uses magnetic, optical, or other recording technologies.

Input / output structures 940 can input / output operations for the system 900 To run. Input / output devices that use these structures can, for. B. keypads, screens 945 , Mouse pointers and microphones. As illustrated and as is understood by those skilled in the art, the computer system 900 according to the present disclosure in a desktop computer package 960 , a laptop computer 970 , a portable computer, such as As a tablet, PDA or smartphone 980a , or one or more server computers that advantageously have a "cloud" computer 990 include.

At this point, as we have presented this revelation with some specific examples, experts will soon realize that our teachings are not so limited. Accordingly, this disclosure may be limited only by the scope of the claims attached hereto.

Claims (47)

A system for sharing and synchronizing files electronically stored in a cloud system, comprising a computing device, including a processor and memory coupled to that processor, which in turn stores computer-executable instructions as executed by the processor, such as the system follows: it receives a message from the cloud that a file has been created and electronically stored in a cloud file system; it determines whether the electronically stored file needs to be copied to the system and as a result of that determination; copies the generated file to the system; otherwise, it stores an electronically stored file in a local file system that contains a link to the file that is stored electronically in the cloud file system. The system of claim 1, wherein the generated file has a certain type and the determination is made according to the file type of the generated file. The system of claim 1, wherein the file electronically stored in the local file system has a type indicative of a file created in the cloud. The system of claim 1, wherein the link via a browser allows access to the file stored electronically in the cloud file system. The system of claim 1, wherein the link comprises a Uniform Resource Locator (URL). The system of claim 1, wherein the link comprises a resource ID of the electronically stored file.  The system of claim 1, wherein said generated file is from the cloud computer system. The system of claim 7, wherein said generated file is generated from the cloud computer services and has a type coming from the group of: documents, spreadsheets, presentations, drawings, forms, and cloud sites. The system of claim 8, wherein said cloud computer services include services selected from the group consisting of word processors, spreadsheets, graphics, calendars, and cloud site applications. The system of claim 1, wherein said generated file was created by a third-party application. The system of claim 1, wherein said generated file has a type indicative of its creation by a third-party application. The system of claim 1, wherein said link allows access to a cloud site.  A computer-implemented system for synchronizing electronically stored files between a client file system and a cloud file system, comprising: a cloud watcher that receives a change log that indicates the status of the cloud file system and that detects changes to the cloud file system and that generates work objects in response to the detected changes in the cloud file system; a local watcher that simultaneously monitors and identifies changes to the client file system and generates work objects in response to the detected client file system changes; a fetcher that serializes the assignment of selected work objects to Workers; and a large number of workers who simultaneously process their assigned work objects; wherein the work objects are file operations that result in synchronization between the client file system and the cloud file system. The computer-implemented system of claim 13, comprising an event aggregator that aggregates a number of the recognized client file system changes such that the aggregated changes are used to generate work objects. The computer-implemented system of claim 13, comprising a snapshot indicating the current state of synchronization between the client file system and the cloud file system. The computer-implemented system of claim 13 including a blacklist of work objects that are not to be assigned to workers. The computer-implemented system of claim 13 including a local graph indicative of a state of the local file system. The computer-implemented system of claim 13, including a cloud graph indicative of a state of the cloud file system. The computer-implemented system of claim 18, wherein the fighter includes a dependency map referenced by the fighter prior to the assignment of selected work items to workers.  The computer-implemented system of claim 18, wherein the dependency map includes indications of particular inodes that are affected by the current actions of the workers. The computer-implemented system of claim 18, wherein the dependency map includes indications of particular resource IDs that are affected by the current actions of the workers.  The computer-implemented system of claim 18, wherein the dependency map includes file names of files that are affected by the current actions of the workers.  The computer-implemented system of claim 18, wherein the fetcher includes a work queue of work items sorted from oldest to newest.  A computer storage device with computer-executable instructions that, when executed by a computer, causes the computer to perform the following operations: receiving a change log indicative of the status of the cloud file system, detecting the changes to the cloud file system, and generating file system operations in response to the detected changes in the cloud file system; simultaneously monitoring the client file system, detecting the changes to one or more files electronically stored in the client file system, aggregating a number of the changes in the client file system, and using the aggregated changes to generate file system operations in response to the detected changes in the client file system; the serial sorting of file system operations from oldest to newest; and concurrently performing the file system operations so that the detected changes to a file in one of the file systems can be replicated to a file of the other file system. The computer storage medium of claim 24, which causes the computer to perform the following operations: comparing a current state of the cloud file system to a graph so that any changes to files in the cloud file system are detected. The computer storage medium of claim 24, which causes the computer to perform the following operations: Comparing the detected changes to a snapshot structure indicating the current state of synchronization between the client file system and the cloud file system. A computer system comprising program instructions adapted to be executed for sharing and synchronizing electronically stored files between a client file system and a cloud file system, comprising: Means for receiving a series of change events, wherein each change event indicates an independent change to the client file system; Means for keeping the received change events for a certain period of time; Means for determining whether any of the stored change events can be combined with other received change events; Means for combining the combinable change events into an aggregate change event; and Means for sending a change event for processing after it has been stored for a predetermined period of time; wherein processing the dispatched change event causes synchronization of an electronically stored file between the client file system and the cloud file system. The computer system of claim 27, further comprising: Means for keeping the aggregated change event for a further period of time; and means for determining whether the retained aggregated change event can be combined with other change events. The computer system of claim 28, further comprising: Means for sending a change event for processing after it has been stored for a predetermined period of time. The computer system of claim 29, wherein the dispatched change event effects synchronization of an electronically stored file between a file system and a cloud file system.  The computer system of claim 29, further comprising: Means for determining if a received change event is part of a recognizable pattern. The computer system of claim 31, wherein said recognizable pattern determining means uses the observed file types associated with the received changes to make this determination. The computer system of claim 31, wherein said means for determining the recognizable pattern uses the recognized executable programs associated with the received changes to make this determination. The computer system of claim 31, wherein said means for determining the recognizable Pattern that uses detected executing processes associated with the received changes to make that determination. A computer storage device that includes computer-executable instructions that, when executed by a computer, cause the computer to perform the following common usage and synchronization operations: receiving a series of change events, wherein each change event indicates an independent change to the client file system; keeping the received change event for a certain period of time; determining if any of the stored change events can be combined with other received change events; and combining the combinable change events into an aggregate change event; and sending and processing the aggregate change event; wherein the processing of the dispatched change event causes a synchronization of an electronically stored file between a file system associated with the dispatched change event and a cloud file system. A computer storage medium according to claim 35, which causes the computer to perform the following operations, comprising: keeping the aggregated change event for a further period of time; and determining whether the retained aggregated change event can be combined with other change events. The computer storage medium of claim 36, which causes the computer to perform the following operations, comprising: aggregating the aggregated change event with another change event. The computer storage medium of claim 36, which causes the computer to perform the following operations, comprising: sending a change event for processing after it has been stored for a predetermined period of time; wherein the processing of the dispatched change event causes synchronization between a file system associated with the dispatched change event and a cloud file system.  A computer storage device with computer-executable instructions that, when executed by a computer, causes the computer to perform the following operations: determining whether an electronically stored file in a cloud file system is associated with a series of directories in the cloud file system; and Generating the number of replicas of the electronically stored file in the client file system - one for each directory. The computer storage medium of claim 39 comprising computer-executable instructions that, when executed by a computer, cause the computer to perform the following operation, comprising: Generating the number of local directories in the client file system - one for each directory. The computer storage medium of claim 40, wherein each of the local directories includes a replica of the electronically stored file. The computer storage medium of claim 41, wherein each replica includes a link to the file stored electronically in the cloud file system. The computer storage medium of claim 42 comprising computer-executable instructions which, when executed by a computer, cause the computer to perform the following operation, comprising: accessing via a browser using the link to the file stored electronically in the cloud file system. A computer storage device with computer-executable instructions that, when executed by a computer, causes the computer to perform the following operations: sorting the work items in a queue from oldest to newest; sequentially checking the work items in the queue from oldest to newest and determining if there are any dependencies for the corresponding checked work item; and sending the checked work object to a worker thread for processing if no dependencies have been detected for that work object, or otherwise proceeding with checking the next work object in the queue; wherein the relative order of the work items in the queue that are not sent is maintained; and wherein the dispatched work item effects the sharing and synchronization of an electronically stored file between a client file system and a cloud file system. The computer storage medium of claim 44, which causes the computer to perform the following operations, comprising: comparing a current status of the cloud file system with a graph to determine any changes to files in the cloud file system. The computer storage medium of claim 45, which causes the computer to perform the following operations, comprising: comparing dependencies that are influenced by the checked work object with entries in the dependency map. The computer storage medium of claim 44, which causes the computer to perform the following operations, comprising: setting dependencies in the dependency map for the dispatched work object and releasing the dependencies in the dependency map for the dispatched work object after the worker object completes the dispatched work object.

Images